Максим Россомахин ([info]rossomachin) wrote,

CSS-фреймворки и прочее

Давно не садился писать на прочувствованные технические темы, уж простите — жизнь приносила сюрпризы один за другим. А сейчас я всё-таки сяду и напишу, в интервале между событиями.

Итак, излюбленная тема — CSS. Излюбленная подтема — принципы именования CSS-объектов (классы, идентификаторы для элементов XHTML). Новомодная тема — CSS-фреймворки. Пройдусь по всем.

Начинать лучше всего с начала. Ещё лучше с того, что этому началу предшествует.



Начало



Для того, чтобы грамотно подобрать наименования, необходимо ещё перед началом вёрстки видеть как можно более полную картину будущего сайта. Т.е. по меньшей мере иметь на руках дизайн-макеты основных страниц. Вооружаетесь программой для просмотра изображений, карандашом, бумагой — и начинаете отмечать для себя типовые элементы дизайна, повторяющиеся элементы, общие для всех (или многих) макетов свойства и т.п.

Если же выходит так, что дизайнер присылает вам новые макеты уже в процессе работы, то нередко наблюдается снижение эффективности наименования и/или излишних стилях. И дело не в нехватке профессионализма, а в том, что вы не видели общую картину в начале работы. Характерный признак: верстая новые макеты, вы видите, что контекст ранее выбранных наименований не очень удачно вписывается в вёрстку новых страниц.

Стиль оформления стилей



MyStyle или my-style, а может my_style? Я стараюсь писать составные наименования так: my-style. Читабельнее.

Отбивать стили табуляцией или пробелами? Табуляцией. Пробелов нужно гораздо больше.

Писать стили в столбик или в строчку? В столбик. Хотя бы на период вёрстки. Читабельнее. Особенно важно, если работаете в команде с кем-то.

Работа в команде



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

Унификация стилей



Не секрет, что блочная валидная семантическая вёрстка успела обрасти несколькими общеупотребительными конструкциями (header, footer как минимум). Однако вопрос об наименовании других распространённых элементов дизайна до сих пор открыт. Да, обсуждают. Да, пишут свои варианты. Но сколько верстальщиков — столько и вкусов.

Тема интересная, а решение вопроса — насущно. Вот почему у меня загорелись глаза, когда я впервые прочитал о микроформатах. Они позволяют стандартизировать наименования некоторых типовых конструкций.

CSS-фреймворки



Не JavaScript-ом единым ;-).

Blueprint — буржуйский.
И наш, создаваемый руками Agat'а,— http://css-framework.ru/.

Лёд тронулся. Уверен, что это не последние попытки обобщить богатый полевой опыт. Унификация докатится и до этих аспектов. Пока одни думают, валидировать ли им код, другие шагают в будущее.

P.S. Особая тема — работа над высоконагруженными проектами, где каждый байт считают. Об этом надо Харисова с Макишвили спрашивать. Наверняка полно хитрых нюансов.

Tags: css, css-framevork, именование объектов, микроформаты

  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

  • 29 comments

[info]harisov

September 10 2007, 12:56:25 UTC 4 years ago

Наш CSS Code Style: http://vitaly.harisov.name/css-code-style.html

[info]rossomachin

September 10 2007, 13:35:18 UTC 4 years ago

Посмотрел.

Я вместо

/* Header (begin) */
/* Header (end) */

как-то неспешно со временем перешёл на

/* Header */
/* // Header*/

[info]harisov

September 10 2007, 13:38:35 UTC 4 years ago

Я давно не пишу (begin) и (end) руками, за меня всё делает Idea.
Я пишу cc<tab>Header

[info]rossomachin

September 10 2007, 17:28:26 UTC 4 years ago

Да я к тому, что так оно и короче и мне не менее понятней.

[info]rossomachin

September 11 2007, 09:38:17 UTC 4 years ago

Виталь, а почему именно такая последовательность свойств? Дело привычки или что-то большее?

[info]harisov

September 11 2007, 09:41:31 UTC 4 years ago

Шрифты на первом месте, потому что от них всё пляшет дальше (em'ы), остальное сгруппировано вместе по назначению. Ну и дело привычки тоже.

На самом деле, это не сильно важно, как группировать, важно, чтобы все поддерживались единого code style.

[info]rossomachin

September 11 2007, 10:04:50 UTC 4 years ago

На самом деле, это не сильно важно, как группировать, важно, чтобы все поддерживались единого code style.

Безусловно. Это в любой командной работе важно. Ну может кроме хоккея :-)

А каково применение em-ов? Только лишь кегль и текстовые отступы? Или у вас практикуют em-sized дизайны?

[info]harisov

September 11 2007, 10:09:18 UTC 4 years ago

Кегль и текстовые отступы. Этого достаточно, чтобы размер шрифта имел значение.

[info]mtonly

September 11 2007, 20:23:57 UTC 4 years ago

[Не вполне уверен, что правильно понял назначение и смысл блока правил под заголовком «Последовательность свойств».]
А чем обусловлены разные значения box-sizing и -moz-box-sizing, Виталь? ;-)

[info]harisov

September 12 2007, 08:34:28 UTC 4 years ago

Ничем не обусловлены, это пример.

[info]harisov

September 12 2007, 09:18:08 UTC 4 years ago

[Не вполне уверен, что правильно понял назначение и смысл блока правил под заголовком «Последовательность свойств».]


В наших CSS файлах правила должны идти именно в таком порядке и именно с такой разбивкой на блоки.

[info]harisov

September 10 2007, 13:09:58 UTC 4 years ago

> Отбивать стили табуляцией или пробелами? Табуляцией. Пробелов нужно гораздо больше.

Слабый аргумент какой-то. В редакторе настраивается «заменять таб на пробелы» и «таб = 4 пробела» и всё. Зато пробелы всегда будут прбелами, а не как таб переменного размера, что удобно, например, при просмотре diff'а в мейлере.

[info]rossomachin

September 10 2007, 13:30:45 UTC 4 years ago

Меня не напрягают табы в этом случае. А пробелы это ещё и лишние байты, как по мне.

[info]harisov

September 10 2007, 13:37:24 UTC 4 years ago

У нас проблемы лишних байт нет: http://cards.yandex.ru/css/_cards.css

Мы разделяем код на "для разработки" и "для продакшена". В первом случае надо оптимизировать удобство и скорость разработки, а во втором скорость загрузки.

[info]mourner

September 10 2007, 16:32:57 UTC 4 years ago

И что, оба поддерживаете? Это же ужасно! А как насчёт автоматической минификации на билде?

[info]harisov

September 11 2007, 08:54:49 UTC 4 years ago

Мы похожи на идиотов? Конечно, мы работаем только с первым, а второй делается скриптом.

[info]mourner

September 11 2007, 09:04:29 UTC 4 years ago

Ну ладно, а то ты как-то неточно выразился. :)
Фронт-энд девелоперы не должны разделять код на "для разработки" и "для продакшна", для них есть только один - первый. О втором позаботятся серверсайдеры.

[info]harisov

September 11 2007, 09:06:12 UTC 4 years ago

Кстати, ты всё ещё не хочешь к нам работать?

[info]mourner

September 11 2007, 09:43:11 UTC 4 years ago

А что мне у вас делать?
У вас нет позиции Front-End Architect.

[info]rossomachin

September 11 2007, 10:05:37 UTC 4 years ago

Для хорошего человека откроют.

[info]mourner

4 years ago

[info]mourner

4 years ago

[info]harisov

September 11 2007, 10:12:25 UTC 4 years ago

Я не совсем понимаю, чем занимается Front-End Architect вообще и что ему делать в Яндексе, в частности.

[info]mourner

4 years ago

[info]thebits

September 10 2007, 19:24:09 UTC 4 years ago

Почему 4?
Я в последнее время тоже перешел на пробелы. Но на 3.

[info]harisov

September 11 2007, 08:55:57 UTC 4 years ago

Таков внутренний стандарт. Можно и 3, можно и 2. Сколько угодно, лишь бы у всех одинаково.

[info]r3code

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 {}
цепочки могут быть в принципе неограниченной длинны - до неприличного.

[info]stekolschikov

November 16 2007, 00:07:24 UTC 4 years ago

Спасибо за пинок. В ближайшие полторы недели выложу свой фреймворк, который всегда помогал мне не думать о «прелестях» вёрстки.

Но сначала опишу его как следует.

Он прост, но, может кому понадобится.

Кстати, я сколько искал, не нашёл фреймворка, который подошёл бы мне.

Да и скриптик потом написать, чтобы потом сделаное на фреймворке «компилилось» для тех, кто каждый байт считает.
Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…