wildhind

не. Речь о самой обычной стандартной раскладке и сочетании Alt+Shift+'-'

Рус, чуть остынь. Как задача стоит? Наверняка она всё-таки решается через шаблоны. Если нет, можно написать свой обработчик, создающий почтовые события. Но даже и его правильнее через шаблоны делать.

Подобные задачи решаются в /bitrix/php_interface/init.php: http://dev.1c-bitrix.ru/api_help/main/events/onafteruserregister.php http://dev.1c-bitrix.ru/api_help/main/reference/cuser/setusergroup.php Хотя, как я понимаю задачу, в группу заносить нужно не по регистрации сразу. Но обработчик можно поставить почти на любое событие.

dersmoll, спасибо, хороший пост. Про иконку с глазом — да, замечание по делу. Бывают моменты, когда между текущими проектами появляется окно в несколько часов свободного времени. Тогда можно вернуться к уже сданным проектам и подшлифовать их на свой вкус. Вот на такой момент буду иметь в виду ваше замечание и пройдусь по всем таким моментам. Спасибо. Однако скажу, что спрайтами злоупотреблять не стоит. Наверняка, говоря про «кучу графических объектов», вы имели в виду к примеру огромный список причин выбрать геокупол и икноки к нему. Да, их можно объединить в спрайт. Только тогда вопрос: как этим управлять из админки? Уточню вопрос: как этим очевидно управлять из админки человеку, который разбирается в торговом и демонстрационном оборудовании, но не разбирается в css? Да, можно понаписать скриптов, которые будут автоматизировать работу со спрайтами. Но купить сервер с нормальной производительностью, который не загнётся от лишнего десятка запросов, будет значительно дешевле. Насчёт неминимизированного js: это сознательное решение, выстраданное опытом. При минимизации теряются комментарии и говорящие имена переменных. Разворачивая минимизированный скрипт мы получаем ненамного более удобное для редактирования чудо, чем сам непосредственно минимизированный скрипт. Выигрываем же мы на этой минимизации всего несколько байт. Насчёт css вы спрашиваете — зачем усложнение. Теперь прочитайте css полностью, не выхватывая из контекста отдельные строки, и вам станет понятно, что это не усложнение, а упрощение. Упрощение себе работы за счёт опять же нескольких байт, которые придётся загрузить посетителю сайта. То есть, у нас на одной чаще весов несколько байт экономии, а на другой — удобство дальнейшей разработки и поддержки. В несколько раз больше объёма сэкономится, когда тестовые картинки в верхнем слайдере заменятся реальными оптимизированными. Какой вывод напрашивается? В общем, оптимизация — это хорошо, но меру знать надо. Надо уметь вовремя остановиться и уметь различать узкоспециализированные сайты, которые посещать будут раз в день, с хорошего компьютера и хорошего канала, и каждый второй посетитель будет делать заказ, и сайты общего пользования, на которые планируется высокая нагрузка, и которые посещать будут неизвестно с какой аппаратуры и неизвестно по каким каналам.

— это неправда.

Seemann, если вы не смогли осилить — не беритесь. Для вас есть альтернативы. Если бы битрикс был действительно единственным достойным решением, все остальные уже бы давно сошли на нет. Вашу трагедию вы описали одной фразой: С таким подходом у вас не получится освоить ровно ничего. А насчёт времени: средний корпоративный сайт на битриксе можно собрать в течение рабочего дня или двух (не включая вёрстку, конечно). При этом практически нет ограничений по возможностям. Но это нужно знать как. Учиться на практике не менее года. Так что смысл есть только для профессионалов.

Рус, поздравляю! Желаю учиться, учиться и учиться. Экспериментировать и читать документацию. Читать документацию и экспериментировать. И стать настоящим Профессионалом с большой буквы. У тебя все для этого данные есть.

ок, задание. В нижней части страницы блок «Наши новости наноновоновости». Сразу под ним разместить такой же блок из другой ленты, только у него не будет картинок и дат. Сразу после размещения и применения готового на данный момент css, выглядеть новый блок новостей должен корректно и в соответствии с дизайном.

значит попиксельное соответствие макету — это ошибка. Как просто догнать современную действительность: ставим простой доктайп, забываем про самые бредовые ограничения xhtml вроде запрета на атрибут target, обязательность атрибута alt или обязательность закрытия всех тэгов — и этого на первое время достаточно. Дальше можно вникать глубже, изучать. И нужно не забывать, что старые браузеры не знали, что такое xhtml и интерпретировали его как почти html, а новые браузеры уже и знать не хотят, что такое xhtml, и интерпретируют его как html5, в котором допустим и такой синтаксис тоже. А надо ли? Он ведь не выдержит критики. Одна из распространённых ошибок начинающих верстальщиков — панический страх перед таблицами. Видимо считают, что злые форумные завсегдатаи жестоко унизят, как только увидят тэг <table>. Это не так. А если бы и так — что с того? Возможно, стоит разок-другой в учебных целях сверстать таблицу дивами (абзацами, ссылками — какая разница, по сути то же самое), но на практике так делать не нужно. по поводу ширины столбца — соглашусь, вопрос в большей степени к дизайнеру. Но по поводу перекрытия картинки заголовком — исключительно к верстальщику.

Это всё равно делается средствами css с минималистичной разметкой. Максимум можно добавить один лишний элемент, если действительно требуется полная поддержка IE7.

почему? что мешает?

это и есть основная ошибка. Вторая основная ошибка — это непоследовательность. Если простота и удобочитаемость, то вместо такой конструкции: <div class="menuT"> <ul> <li> <a class="L" href="#"> <span class="R"> <span class="C"> контакты </span> </span> </a> </li> <li> <a class="L" href="#"> <span class="R"> <span class="C"> статистика </span> </span> </a> </li> <li> <a class="L" href="#"> <span class="R"> <span class="C"> правила сайта </span> </span> </a> </li> <li> <a class="L" href="#"> <span class="R"> <span class="C"> регистрация </span> </span> </a> </li> </ul> </div> надо писать такую: <nav class="mainmenu"> <a href="#">регистрация</a> <a href="#">правила сайта</a> <a href="#">статистика</a> <a href="#">контакты</a> </nav> При этом использовать метод раздвижных дверей там, где ширина пунктов фиксированная, не совсем правильно. Одна картинка вряд ли будет более тяжёлой, чем три. Да если и использовать ваш подход, то почему не спрайт? В форме поиска почему текст сдвинут от центра вверх? У нас бы такая работа даже первичное тестирование не прошла бы. Очень много где ссылки и кнопки не реагируют на ховеры — это ошибка. В списке новостей вообще допущена грубейшая ошибка: контент вынесен в css. Картинка новости — это контент. Это то, что редактор будет вносить через админку, и это то, что должно находиться службой Яндекс.Картинки по тематическому запросу. То есть, это должен быть тэг <img>, желательно с проставленным атрибутом alt. И представьте себе такую ситуацию: вам нужно на этой странице вывести ещё один блок новостей, и надо, чтобы он сразу выглядел так же. Это хорошая проверка качества вёрстки.

ФФ обновился, и в нём перестала работать вот эта красота: http://tympanus.net/codrops/2011/09/05/slicebox-3d-image-slider/ Было много разговоров с заказчиком по этой теме В силу здравомыслия заказчика разговоры прошли конструктивно, а вот ФФ слегка расстроил.

и точно! надо ж было так спалиться! Ну да, ошибок там было навалом по ходу работы. В порядке эксперимента этот проект делался на новой временно незнакомой системе. Ведь даже когда что-то знаешь хорошо, всё равно охота найти что-нибудь лучше.

ссылку на портфолио можно и здесь. Я например напишу если увижу в портфолио то, что меня заинтересует. А так писать не буду, уж извините.

да, правильно. А чтобы было действительно правильно, не забывайте им указывать классы. Частая ошибка заключается в том, что используют например <header> для шапки сайта, и не дают ему класса, а в css оформляют просто тэг <header>. Когда же например появляется своя шапка у новостного блока, сами понимаете, что происходит: применяются стили шапки сайта и всё выглядит криво. role="presentation" — это фактически легализация использования таблиц для раскладки элементов.

ну как… типы цен. Сменил тип оплаты — обработчик сработал и занёс пользователя в группу, для которой актуален другой тип цен. То есть, технически возможно, но с точки зрения здравого смысла гложут какие-то сомнения.

Есть разные способы: можно сделать copy/paste. можно на странице со старой вёрсткой сменить доктайп. а если надо, чтобы по-пацански, то тэгу table нужно добавить атрибут role="presentation"

Нет, такое не делается. Это же противоречит соображениям здравого смысла. Что можно сделать: завести разные типы цен и по каждому из типов позволять оплачивать только одним способом. Но тогда и спрашивать о способе оплаты надо сразу. Или же делать наценку на стоимость заказа после выбора способа оплаты.

Нет, значительно проще. Битрикс — чуть ли не единственная документированная CMS. api позволяет решать любую задачу, не затрагивая код ядра. Красивая стройная архитектура. Логика от представления чётко отделена. Можно масштабировать, комбинировать и вообще творить что угодно, почти полная свобода действий. Есть возможность управление любым нестандартным функционалом вынести в админку, создавать элементы управления в публичной части и т.п. Всё это требует всего лишь чтения документации, но никак не перелопачивания тонн быдлокода и ломания мозгов, как в джумле. Но если чукча не читатель, а писатель, то лучше даже не смотреть в сторону битрикса. Сложно будет. А тому, кому результат работы чукчи-не-читателя-а-писателя достанется на поддержку, будет ещё сложнее. К сожалению, быдлокодить битрикс позволяет безгранично, никак этому не препятствует.

да, всё правильно

это делается через обработчик платёжной системы

не думаю. Там их как минимум 95%. Я имею в виду активных комментописателей. Адекватный народ редко-редко там себя проявляет.

ок, ладно. Псевдонауку, основанную на мифах, всерьёз воспринимать вряд ли стоит. Во-первых, слово «становится» пишется без мягкого знака. Во-вторых, шлака действительно много, но на него ориентироваться не стоит. Это не поможет. Вот если siri развивать будут дальше в том же направлении — это да, слепые смогут пользоваться благами цивилизации с не меньшим комфортом, чем зрячие. Мобильные устройства вот этот сайт с говёной вёрсткой отображают нормально. И разработчики софта для мобильных устройств правильно делают, что обучают свои браузеры показывать то, что ожидает пользователь, а не то, что прописано академиками в пыльных томах. Открою страшную тайну: это репутация только среди форумных троллей. В мире ИТ в код сайта редко кто будет заглядывать. Если будут оценивать этот сайт, то оценивать будут идею, юзбилити, качество контента. Есть ряд случаев, когда качество кода действительно важно. Это не тот случай.

Нормальный сайт. Код, конечно, хреновенький. Но кто, кроме нас, смотрит в код? Есть куда лучше. Жаль, со временем сейчас туго, но может завтра-послезавтра выберусь. Такой сайт охота разобрать более детально, чувствуется, что будет не зря. Огромный жирный плюс: сразу понятно, о чём этот сайт и зачем он. У таких сайтов и появляется аудитория, такие сайты и читают. Дизайн не мешает восприятию информации — уже замечательно, отлично и превосходно. Уже только по этому параметру сайт с ходу лучше примерно 80% сайтов рунета. Однако, дизайн может и помогать и привлекать. Вам есть куда расти. Будете писать, развивать этот сайт — будет ему счастье и долгая жизнь.