Максим Россомахин ([info]rossomachin) wrote,
@ 2007-09-10 09:10:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Current location:Северодвинск
Current mood:хорошее
Current music:Queen - Don't Stop Me Now
Entry tags:css, css-framevork, именование объектов, микроформаты

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. Особая тема — работа над высоконагруженными проектами, где каждый байт считают. Об этом надо Харисова с Макишвили спрашивать. Наверняка полно хитрых нюансов.


(Post a new comment)


[info]harisov
2007-09-10 12:56 pm UTC (link)
Наш CSS Code Style: http://vitaly.harisov.name/css-code-style.html

(Reply to this)(Thread)

[info]rossomachin
2007-09-10 01:35 pm UTC (link)
Посмотрел.

Я вместо

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

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

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

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-10 01:38 pm UTC (link)
Я давно не пишу (begin) и (end) руками, за меня всё делает Idea.
Я пишу cc<tab>Header

(Reply to this)(Parent)(Thread)

[info]rossomachin
2007-09-10 05:28 pm UTC (link)
Да я к тому, что так оно и короче и мне не менее понятней.

(Reply to this)(Parent)

[info]rossomachin
2007-09-11 09:38 am UTC (link)
Виталь, а почему именно такая последовательность свойств? Дело привычки или что-то большее?

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-11 09:41 am UTC (link)
Шрифты на первом месте, потому что от них всё пляшет дальше (em'ы), остальное сгруппировано вместе по назначению. Ну и дело привычки тоже.

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

(Reply to this)(Parent)(Thread)

[info]rossomachin
2007-09-11 10:04 am UTC (link)
На самом деле, это не сильно важно, как группировать, важно, чтобы все поддерживались единого code style.

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

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

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-11 10:09 am UTC (link)
Кегль и текстовые отступы. Этого достаточно, чтобы размер шрифта имел значение.

(Reply to this)(Parent)

[info]mtonly
2007-09-11 08:23 pm UTC (link)
[Не вполне уверен, что правильно понял назначение и смысл блока правил под заголовком «Последовательность свойств».]
А чем обусловлены разные значения box-sizing и -moz-box-sizing, Виталь? ;-)

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-12 08:34 am UTC (link)
Ничем не обусловлены, это пример.

(Reply to this)(Parent)

[info]harisov
2007-09-12 09:18 am UTC (link)
[Не вполне уверен, что правильно понял назначение и смысл блока правил под заголовком «Последовательность свойств».]


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

(Reply to this)(Parent)

[info]harisov
2007-09-10 01:09 pm UTC (link)
> Отбивать стили табуляцией или пробелами? Табуляцией. Пробелов нужно гораздо больше.

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

(Reply to this)(Thread)

[info]rossomachin
2007-09-10 01:30 pm UTC (link)
Меня не напрягают табы в этом случае. А пробелы это ещё и лишние байты, как по мне.

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-10 01:37 pm UTC (link)
У нас проблемы лишних байт нет: http://cards.yandex.ru/css/_cards.css

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

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-10 04:32 pm UTC (link)
И что, оба поддерживаете? Это же ужасно! А как насчёт автоматической минификации на билде?

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-11 08:54 am UTC (link)
Мы похожи на идиотов? Конечно, мы работаем только с первым, а второй делается скриптом.

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-11 09:04 am UTC (link)
Ну ладно, а то ты как-то неточно выразился. :)
Фронт-энд девелоперы не должны разделять код на "для разработки" и "для продакшна", для них есть только один - первый. О втором позаботятся серверсайдеры.

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-11 09:06 am UTC (link)
Кстати, ты всё ещё не хочешь к нам работать?

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-11 09:43 am UTC (link)
А что мне у вас делать?
У вас нет позиции Front-End Architect.

(Reply to this)(Parent)(Thread)

[info]rossomachin
2007-09-11 10:05 am UTC (link)
Для хорошего человека откроют.

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-11 10:08 am UTC (link)
Открывайте :)

(Reply to this)(Parent)(Thread)

[info]rossomachin
2007-09-11 10:49 am UTC (link)
Я не в их славной конторе. :-) Хотя вот только что написал в ЖЖ новый пост — в какой.

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-11 10:51 am UTC (link)
Прошу прощения, промахнулся :)

(Reply to this)(Parent)

[info]harisov
2007-09-11 10:12 am UTC (link)
Я не совсем понимаю, чем занимается Front-End Architect вообще и что ему делать в Яндексе, в частности.

(Reply to this)(Parent)(Thread)

[info]mourner
2007-09-11 10:47 am UTC (link)
http://v1.garrettdimon.com/archives/the-time-is-now-for-front-end-architects

(Reply to this)(Parent)

[info]thebits
2007-09-10 07:24 pm UTC (link)
Почему 4?
Я в последнее время тоже перешел на пробелы. Но на 3.

(Reply to this)(Parent)(Thread)

[info]harisov
2007-09-11 08:55 am UTC (link)
Таков внутренний стандарт. Можно и 3, можно и 2. Сколько угодно, лишь бы у всех одинаково.

(Reply to this)(Parent)

[info]r3code
2007-11-05 02:30 pm UTC (link)
Да интересный этот вопрос.
я перешел на
/* header */
/* //header */ действительно - итакже знаешь их ХТМЛя чтo / - закрывает тег.

когда то был баг в IE он отказывался применять правила если имя класса содержало "_", я перешел на "-", возможно этот глюк был в какой-то конкретной сборке, но нервов он мне много попортил.

Я лично, не стал бы называть это framework - это просто попытка как-то упорядочить наработанные материалы и подчинить их правилам. Это скорее образец оформления, каждый сможет создать себе такой и, наверно, приходит к этому после длительного времени.

Меня еще интерисует как вы разбираетесь с указанием стиля конкретного элемента, т.е. можно конечно придумывать для разных элементов уникальные имена классов, а можно указать полный порядок вложенности типа
div.class1 div span.class1 a {}
div.class1 div span.class2 a {}
 цепочки могут быть в принципе неограниченной длинны - до неприличного.

(Reply to this)

[info]stekolschikov
2007-11-16 12:07 am UTC (link)
Спасибо за пинок. В ближайшие полторы недели выложу свой фреймворк, который всегда помогал мне не думать о «прелестях» вёрстки.

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

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

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

Да и скриптик потом написать, чтобы потом сделаное на фреймворке «компилилось» для тех, кто каждый байт считает.

(Reply to this)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…