Итак, излюбленная тема — CSS. Излюбленная подтема — принципы именования CSS-объектов (классы, идентификаторы для элементов XHTML). Новомодная тема — CSS-фреймворки. Пройдусь по всем.
Начинать лучше всего с начала. Ещё лучше с того, что этому началу предшествует.
Начало
Для того, чтобы грамотно подобрать наименования, необходимо ещё перед началом вёрстки видеть как можно более полную картину будущего сайта. Т.е. по меньшей мере иметь на руках дизайн-макеты основных страниц. Вооружаетесь программой для просмотра изображений, карандашом, бумагой — и начинаете отмечать для себя типовые элементы дизайна, повторяющиеся элементы, общие для всех (или многих) макетов свойства и т.п.
Если же выходит так, что дизайнер присылает вам новые макеты уже в процессе работы, то нередко наблюдается снижение эффективности наименования и/или излишних стилях. И дело не в нехватке профессионализма, а в том, что вы не видели общую картину в начале работы. Характерный признак: верстая новые макеты, вы видите, что контекст ранее выбранных наименований не очень удачно вписывается в вёрстку новых страниц.
Стиль оформления стилей
MyStyle или my-style, а может my_style? Я стараюсь писать составные наименования так: my-style. Читабельнее.
Отбивать стили табуляцией или пробелами? Табуляцией. Пробелов нужно гораздо больше.
Писать стили в столбик или в строчку? В столбик. Хотя бы на период вёрстки. Читабельнее. Особенно важно, если работаете в команде с кем-то.
Работа в команде
Нужно обязательно договориться со всеми о едином стиле наименования и оформления кода, и придерживаться этих правил. Дело касается не только CSS, но и имён служебных папок, фоновых изображений и т.п. Нелишне перестраховаться от бардака.
Унификация стилей
Не секрет, что
Тема интересная, а решение вопроса — насущно. Вот почему у меня загорелись глаза, когда я впервые прочитал о микроформатах. Они позволяют стандартизировать наименования некоторых типовых конструкций.
CSS-фреймворки
Не JavaScript-ом единым ;-).
Blueprint — буржуйский.
И наш, создаваемый руками Agat'а,— http://css-framework.ru/.
Лёд тронулся. Уверен, что это не последние попытки обобщить богатый полевой опыт. Унификация докатится и до этих аспектов. Пока одни думают, валидировать ли им код, другие шагают в будущее.
P.S. Особая тема — работа над высоконагруженными проектами, где каждый байт считают. Об этом надо Харисова с Макишвили спрашивать. Наверняка полно хитрых нюансов.
September 10 2007, 12:56:25 UTC 4 years ago
September 10 2007, 13:35:18 UTC 4 years ago
Я вместо
/* Header (begin) */
/* Header (end) */
как-то неспешно со временем перешёл на
/* Header */
/* // Header*/
September 10 2007, 13:38:35 UTC 4 years ago
Я пишу cc<tab>Header
September 10 2007, 17:28:26 UTC 4 years ago
September 11 2007, 09:38:17 UTC 4 years ago
September 11 2007, 09:41:31 UTC 4 years ago
На самом деле, это не сильно важно, как группировать, важно, чтобы все поддерживались единого code style.
September 11 2007, 10:04:50 UTC 4 years ago
Безусловно. Это в любой командной работе важно. Ну может кроме хоккея :-)
А каково применение em-ов? Только лишь кегль и текстовые отступы? Или у вас практикуют em-sized дизайны?
September 11 2007, 10:09:18 UTC 4 years ago
September 11 2007, 20:23:57 UTC 4 years ago
А чем обусловлены разные значения box-sizing и -moz-box-sizing, Виталь? ;-)
September 12 2007, 08:34:28 UTC 4 years ago
September 12 2007, 09:18:08 UTC 4 years ago
В наших CSS файлах правила должны идти именно в таком порядке и именно с такой разбивкой на блоки.
September 10 2007, 13:09:58 UTC 4 years ago
Слабый аргумент какой-то. В редакторе настраивается «заменять таб на пробелы» и «таб = 4 пробела» и всё. Зато пробелы всегда будут прбелами, а не как таб переменного размера, что удобно, например, при просмотре diff'а в мейлере.
September 10 2007, 13:30:45 UTC 4 years ago
September 10 2007, 13:37:24 UTC 4 years ago
Мы разделяем код на "для разработки" и "для продакшена". В первом случае надо оптимизировать удобство и скорость разработки, а во втором скорость загрузки.
September 10 2007, 16:32:57 UTC 4 years ago
September 11 2007, 08:54:49 UTC 4 years ago
September 11 2007, 09:04:29 UTC 4 years ago
Фронт-энд девелоперы не должны разделять код на "для разработки" и "для продакшна", для них есть только один - первый. О втором позаботятся серверсайдеры.
September 11 2007, 09:06:12 UTC 4 years ago
September 11 2007, 09:43:11 UTC 4 years ago
У вас нет позиции Front-End Architect.
September 11 2007, 10:05:37 UTC 4 years ago
4 years ago
4 years ago
4 years ago
September 11 2007, 10:12:25 UTC 4 years ago
4 years ago
September 10 2007, 19:24:09 UTC 4 years ago
Я в последнее время тоже перешел на пробелы. Но на 3.
September 11 2007, 08:55:57 UTC 4 years ago
November 5 2007, 14:30:15 UTC 4 years ago
я перешел на
/* header */
/* //header */ действительно - итакже знаешь их ХТМЛя чтo / - закрывает тег.
когда то был баг в IE он отказывался применять правила если имя класса содержало "_", я перешел на "-", возможно этот глюк был в какой-то конкретной сборке, но нервов он мне много попортил.
Я лично, не стал бы называть это framework - это просто попытка как-то упорядочить наработанные материалы и подчинить их правилам. Это скорее образец оформления, каждый сможет создать себе такой и, наверно, приходит к этому после длительного времени.
Меня еще интерисует как вы разбираетесь с указанием стиля конкретного элемента, т.е. можно конечно придумывать для разных элементов уникальные имена классов, а можно указать полный порядок вложенности типа
цепочки могут быть в принципе неограниченной длинны - до неприличного.div.class1 div span.class1 a {}
div.class1 div span.class2 a {}
November 16 2007, 00:07:24 UTC 4 years ago
Но сначала опишу его как следует.
Он прост, но, может кому понадобится.
Кстати, я сколько искал, не нашёл фреймворка, который подошёл бы мне.
Да и скриптик потом написать, чтобы потом сделаное на фреймворке «компилилось» для тех, кто каждый байт считает.