Сложная верстка сайта

Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Речь в этой небольшой статье пойдет не о специфических техниках для конкретных случаев, также не будет раскрыта тема правильной оптимизации кода и графики под высоконагруженные проекты.

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

Самое удивительное, что большая часть ошибок совершенно типовые и легко исправляемые. Попробую собрать общие рекомендации, следуя которым можно получить не только деньги, но и благодарность заказчика, программистов и будущих посетителей сайта. Вещи очевидные, но статьи, собирающей их воедино я не нашел. В комментариях раскрываются минусы некоторых описываемых методов, для удобства в посте указаны ссылки на ветки комментариев, где можно почитать об этом подробнее.

HTML Логика кода — универсальные классы Регулярно встречающаяся проблема — отсутствующая или искореженная во время довёрстки логика кода.

Я говорю не о грубых ошибках, вроде пересекающихся и незакрытых тегов, а о совершенно отмороженном подходе большого количества начинающих верстальщиков к дальнейшей судьбе их работы. Это современно, это показывает уровень ваших навыков и это действительно часто оправдано, но в данном случае это лишь усложнит чтение кода и увеличит дерево DOM.

Как говорил старик Резо, не преумножай сущности сверх надобности. Типовая ситуация — блок новостей: Имена классов могут быть любыми, но крайне желательно, чтобы они не выбивались из общего стиля.

Зачем писать news-box , homenewsletter? Обратите внимание на универсальный класс item. Каждый волен обзывать его по разному, скажем box , это не принципиально, мне item кажется абсолютно нейтральным и понятным по смыслу всем, кому предстоит работать с кодом в дальнейшем — это просто блок из списка других таких же, как он. Рекомендуется ознакомиться с комментариями, чтобы понять минусы такого подхода. Также можно заметить перед общим блоком комментарий, дублирующий название класса.

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

В данном случае внутри контейнера у нас лежит картинка с float: Оборачивайте область формы в тег action нужен для нормальной валидации , не гнушайтесь использовать лейблы для чекбоксов и радиокнопок, проставляйте табиндексы и нумеруйте или давайте понятные имена элементам формы. Это залог аккуратности и плюса в карму от программистов, которым предстоит работать с вашей вёрсткой.

Немного о подключении скриптов: Также рекомендуется выносить статичные вызовы функций, не меняющиеся от страницы к странице в отдельный файл. Логика кода - общие рекомендации Минимизируйте дерево DOM не в ущерб удобству и здравому смыслу. Хорошим тоном считается сброс значения поля по клику.

Используйте placeholder или js. Меню в подавляющем большинстве случаев верстается ненумерованными списками ul. Подменю в подавляющем большинстве случаев верстается без div внутри li. Поп-апы и другие невидимые изначально блоки, не привязанные к конкретному контейнеру удобно размещать перед закрывающим body - это не мешает чтению кода с начала. Таблицы, как ни странно, удобно верстать таблицами, иногда помогая блоками.

Не забывайте о tr: Чередующиеся строки с разными стилями верстайте через CSS-селекторы или с помощью классов even и odd Имена основных папок корня проекта и названий страниц должны быть стандартизированы.

Обычно это css для файлов стилей, images или img для изображений и подпапка tmp для временных изображений, которые не будут использоваться на живом сайте , js для js, fonts для шрифтов. Имена страниц я для удобства беру из названий файлов макетов, предоставленных заказчиком. Древовидная однострочная структура CSS на мой взгляд по всем пунктам дает фору такой форме записи: Некоторые пользуются своей логикой записи, кто-то упорядочивает свойства по алфавиту, часть верстальщиков вообще пишет от балды.

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

Не выносите reset в отдельный файл, подключайте его в начале общего файла стилей. Надо экономить на запросах к серверу. Это же касается изображений. Нет необходимости создавать отдельный файл, например, со всеми иконками сайта. Его будет неудобно редактировать, если у одной из иконок вдруг увеличится размер. По хакам для IE - у меня нет однозначного мнения. В основном я размещаю их в конце общего файла стилей.

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

Из литературы могу порекомендовать отличную книгу Эрика Мейера " CSS - Подробное руководство ", брошюру от авторов проекта webo. Замечания справедливые, что-то поправил, что-то оставил. Никакого максимализма в статье нет, навязывания своей точки зрения целью я не ставил. Дело в том, что глядя на нечеловеческое количество проектов с версткой, хуже в разы, хочется не то что про префиксы людям рассказать, а просто отправить почитать учебник.

А там, глядишь, и до остального недалеко. Программирование 2,9k авторов , 6,5k публикаций. Тестирование IT-систем авторов , 1,1k публикаций. JavaScript 1,9k авторов , 4k публикаций. Разработка веб-сайтов 4,1k авторов , 9,6k публикаций. Совершенный код авторов , публикации. CSS авторов , 1,2k публикаций. HTML автора , публикаций. Django авторов , публикаций. Python авторов , 1,8k публикаций. Машинное обучение авторов , публикаций. Первая российская материнская плата массового сегмента 16,7k Добавить в закладки Сергей Новиков Synoptic карма.

Сутки Неделя Месяц Уязвимость ВКонтакте: Допустим, у новости есть фотографии, они выводятся лентой в отдельном блоке. А потом предлагают внедрить возле каждой новости ленту ее фотографий, точно в таком же виде, как и лента. Верстка и стили подходят, но тогда получится.

По-моему, только на самом последнем уровне вложения блоков можно простейшие имена классов использовать в span, когда куски текста надо выделять, или красивые кнопки. Структура немного усложнится, но не критически. Вряд ли код от этого станет менее понятен, особенно если закомментировать это место. Также галерея предполагает собой обычно просто картинки, из вполне можно выводить списком, без item. Все подряд называть итемы тоже не дело, такая вложенность может выйти боком в самых неожиданных местах.

А для списка новостей лучше уж использовать список, и в css будет чище. После верстки и внедрения нескольких крупных проектов выскажу свое скромное мнение — универсальные классы, вместе с вложенностью — в топку. Особенно таким образом, как это сделано в предыдущем комментарии. Пропал оборачивающий блок — без проблем. Элемент переехал в аналогичный блок — на здоровье. Не нужно перепахивать весь CSS в поисках зависимостей — все под рукой. Понятно, что для мелких проектов это не столь актуально, но по большому счету их вообще можно верстать любым привычным способом и даже не думать об этом.

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

В противном случае хотя бы верстку независимыми блоками стоит применять. Ну тут в комментариях довольно убедительно доказывается, что даже визитки надо верстать с scss и БЭМ. Мне очевидно, что это не требуется, но доказать правоту я не могу: БЭМ — это всего навсего подход, методология.

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

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

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

Хотя, если честно, я пока не наблюдал тормозов от CSS без анимаций даже не слабых машинах. Не советую прислушиваться к большей части примеров и советов в этой статье. Имхо, писалась она неопытным пером. Со многими вещами поспорил бы! Особенно запись css параметров в строку, совсем недавно об этом было в комментариях. Ага, в процессе часто приходится править правила, а когда они записаны в одну строку, это просто ад.

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

Даже если у вас px по горизонтали, в более менее сложном CSS коде наверняка найдётся множество селекторов с уймой правил. Особенно если не халтурить и использовать браузерные префиксы, text-overflow: Зато скроллить приходится значительно меньше, так как на экран помещается намного больше правил.

Если их с десяток, то таки да, лучше развернуть запись правила построчно. А зачем вам нужно видеть одновременно 3 десятка селекторов? Мне вот нужно видеть 3 десятка правил, а на селекторы наплевать, ибо грамотная организация кода тут решает всё. Комбинировать точно не нужно, это всё сильно усложнит.

Не проблема, напиши свою. Или опиши в комментариях очевидные ошибки, вместе её поправим. То, что написано основано на 3-х летнем опыте верстки таких проектов на фрилансе. Людям, которые работают с моей версткой она нравится, поэтому решил поделиться. Поправить эту статью — будет означать переписать её почти заново. Или в любом случае это уже будет другая статья. Я так понимаю, это люди с фриланса ;. Это обычные заказчики окружающих нас с вами студий, ищущих фрилансера на аутсорсовые работы.

Как я понял по сути дела комментариев нет. Имелось виду что такие студии заранее не ищут качественного исполнения, от этого и ничего не говорят. Был фрилансером, знаю что это такое не по наслышке. Это понятно, не очевидны претензии к описанному в статье.

Примеры сложной верстки?

Описаны элементарные вещи, которые позволяют значительно сократить геморрой для посетителей и программистов, но этими вещами большая часть любителей-фрилансеров или не фрилансеров не пользуется. Интересно в двух словах, почему это тут нужно переписывать всю статью?

Кстати поищите по поиску хабра, была отличная статья о стиле кодинга. Не считая того, что делать выборку по 28 комментариям не правильно, статья не однострочной форме написания CSS. Ладно, давайте по другому. Это уже 30 подобная статья на хабре от новичка. Ничего нового в ней нет, кроме показа своего юношеского максимализма. С довольно не правильными подходами к кодингу. Мне больше вам нечего сказать, и тем более не о чем спорить. Это вредный совет, очень вредный.

Это не мелочь, которую можно проигнорировать. Не стал убирать написанное, но предупреждение добавил. Стоит добавлять префиксы ко всем классам. К примеру если есть. В случае сложной вёрстки сложнее запутаться, и есть существенная гарантия что ваш элемент не подцепит чужой стиль, из другого модуля или из какой-либо внешней библиотеки.

Собственно большая часть js-библиотек, имеющих собственый CSS, так и поступает. К примеру — CKeditor. Долгое время я работал с однострочными стилями.

С тех пор я их просто ненавижу. Нет ничего хуже, ИМХО. Это настолько неудобно… Перейдя на SCSS я пришёл к куда более простым и понятным схемам и больше не издеваюсь над своими глазами повторяя одни и те же селекторы, не мучаю колесо мыши и не заставляю свой мозг парсить строку стилей в гор.

Да и в целом перейдя на SCSS, процесс вёрстки стал доставлять мне удовольствие. На SCSS очень легко организовать порядок, приятный для глаз и лёгкий для мозга код. Упростить само написание кода путём использования mixin-ов и переменных. Переменные вообще чудесная штука, и если не использовать box-sizing IE7 , то они очень выручают.

По хакам для IE — у меня нет однозначного мнения. Я раз и навсегда отказался от всех видов хаков, ввиду лёгкой возможности использования более простой схемы. Я добавляю два класса, 1 с именем браузера, а второй с версией на самый пожарный случай или для ie. Затем в CSS коде пишу body. Это позволяет не разбрасывать код по разным файлам, шаблонам и т.

В случае сложной верстки я тоже пользуюсь префиксами, без них получается ад, в случае необходимости внесения правок. Тут речь о небольших проектах. Мне не сложно, а люди часто довольны. По хакам спасибо, интересно. Это страшное зло, которому нет прощения. Особенно чувствительные программисты могут сделать на вас куклу вуду: Любая необходимость найти какое-либо правило или внести поправку в селектор превращается в ад, в котором и поиск зачастую не помогает.

Нет смысла разделять CSS код простых и сложных проектов. К тому же каким бы простым проект не был. Не вижу сложностей в ориентировании в однострочной форме записи, если заранее установить порядок написания свойств. Перенос по словам включать, очевидно, не надо — теряется смысл. Чем вам поможет порядок строк? Когда я вижу такое , я моментально вижу картинку — где какие селекторы, куда вложены, какие там правила. Когда я вижу однострочный код — я вижу только селекторы с уймой дубляжа.

Сами правила остаются за гранью понимания. А когда я даже не знаю где искать правило — можно просто вешаться. У меня сложилось впечатление, что вам не приходилось использовать подобный CSS в проектах с плавающим дизайном, или вообще работать с ним а не только писать с нуля. Написание каждого правила в отдельной строке по крайней мере, если селекторы не группируются идентами имеет серъезный недостаток — структура CSS файла не видна вообще.

Что бы что-то найти, нужно все время скроллить или пользоваться поиском. Если селекторы группировать с помощью идентов, ситуация конечно упрощается, хотя не рашается полностью, так как вы не можете видеть сразу все селекторы, относящиеся к одному блоку и приходится скроллить туда сюда все время, при работе с каким-то сложным блоком. Когда селекторы написаны в строчку и сгрупированны по принадлежности к определенным блокам, вы сразу можете понять, что вот эти N селекторов принадлежат к этому блоку.

При чем вы видете все эти правила сразу. Таким образом вы можете видеть структуру CSS файла. Если классы называть правильно, вам так же сразу примерно понятно какой селектор что делает.

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

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

Более того, чаще всего меня вообще не интересует список селекторов, я итак его почти на зубок знаю. И точно знаю где какое правило должно находиться. SCSS в этом очень дисциплинирует. Это были страшные муки ада. Не могу вспомнить в WEB ничего такого, что вызывало бы большее отвращение, чем попытка что-то там изменить или исправить. Даже новые правила писать было страшно неудобно. После того как я перешёл на SCSS и стал комбинировать вложенные селекторы и просто отступы вёрстка стала доставлять удовольствие.

Честно говоря, я вообще не понимаю зачем вам нужно видеть селекторов на странице? Мне 5 хватает с головой. А вот правила мне нужны очень. И если ради них мне нужно гор. Когда работашь с одним сложным блоком, то часто нужно вносить изменения в несколько селекторов, которые к нему относятся. Если писать каждое правило в одну строку, то очень часто все селекторы блока не помещаются в один экран и приходится скроллить туда-сюда все время.

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

Да и если проект более менее крупный, то всё помнить тоже не реально. Горизонтальным скроллом не надо пользоваться если включить word wrap в IDE. К тому же, если сортировать правила внутри селектора, то в конец списка правил нужно смотреть достаточно редко. Тут важный вопрос — сортировали ли вы правила внутри одного селектора таким образом как написано в статье? Если нет, то в общем-то ничего удивительного. Тогда, понятное дело, приходится перечитывать всю строку полностью, что бы врубиться что там к чему.

Word wrap в IDE конечно может и мешать в определенных случаях. Вот скриншот скомпилированного SCSS кода. С этим решительно невозможно работать. И не важно отсортированы ли там правила или нет.

В экран почти ничего не помещается, ДАЖЕ без отступов. Питонисты вообще молодцы, ограничивают себя 80 символами, что сильно упрощает понимание кода в дальнейшем. Вот скриншот типичного моего SCSS файла. Всё сразу перед глазами. И, поверьте, я ничего в нём не ищу. Я просто знаю где что, даже если файлу пол-года.

Дело в организации и общем стиле именования, размещения. На мой взгляд — небо и земля. Вот пример кода с бОльшим кол-ом правил. Всё осталось предельно понятным, на виду, и не вызывает сложностей. А теперь вернёмся к первому скриншоту… АААА!!! А вот файл в одну строку с отступами. Файл не мой, вёрстка простая, поэтому правила в основном короткие, селекторы не правильные, поэтому очень короткие, но даже это не спасает.

Когда я смотрю SCSS файл мне почти всегда плевать на селекторы, но важны правила. Обратите внимание на красную линию. Хуже будет только, если применить к этому скриншоту фильтр blur: То что вам нужно видеть селекторы и воспринимать картинку с высоты птичьего полёта, на мой взгляд, говорит о том, что у вас неправильная структура кода. Правда работать так не пробовал.

Что касается этого примера , не видел никогда набора правил такой длинны, что бы скроллбар был такой коротенький. Это видимо проблема именно данной верстки. У меня все правила каждого селектора обчно помещаются в экран, иногда немножко длиннее бывают. Интереса ради, покажите что там дальше. Если не писать такие монстро-правила, никакой проблемы не вижу, что какие-то там бэкграунды уходят за пределы экрана, можно и поскроллить немного когда это реально нужно. А лучше купить монитор нормальный с шириной экрана в пикселей или больше.

Даже с уже легче будет. В остальном читается все в этом файле вроде нормально. Можно не видеть селекторы и не воспринемать картину с высоты птичьего полета, тогда просто продуктивность падает.

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

А вы попробуйте потом смерджить такой код, например. Зачем усложнять себе жизнь? Уже прочитал в другом комментарии. Ок, настаивать не буду. Неужели не сталкивались с техникой абсолютно независимых блоков? Посмотрите доклады Витали Харисова на этот счет. Отступы и правда хорошо и удобно, но если нужна читабельность для человека, то запись в одну строку — это мрак.

Как-то странно вы добавили… Поясняю проблему. Допустим, у нас есть лента новостей, к каждой новости отображаются комментарии. Тогда структура получается примерно такая: Такую вложенность плодить в коде не надо, это путает.

Поэтому описаны оба варианта. Какую вложенность плодить не надо? Не размещать комментарии внутри поста? Не надо вкладывать итемы в итемы. Мысль понятна — делаем префиксы для всего подряд. На выходе получается таблица стилей, в которую надо вникать, если захочется что-то доверстать, придется разобраться в них и придерживаться имен классов, удобных предыдущему верстальщику и т. Это далеко не всегда, не на всех проектах есть система комментариев, отзывов.

Большое количество проектов лоу-сектора при довольно качественном дизайне имеет примитивную структуру. Зачем там использовать префиксы? Почему не использовать их тогда, когда они требуются? Но я не вижу этого в статье. На выходе получается таблица стилей, в которую надо вникать, если захочется что-то доверстать Да поймите же.

Вы, видимо, верстальщик, и вам не нужно вникать во что-то снова. Но программисту постоянно надо что-то доверстать, переверстать, убрать, вырезать, добавить, спасти мир. Если это не фрилансер с двудневным проектом на друпале, то дизайн как по мелочам, так и по крупным моментам может меняться регулярно. Что значит не всегда? Сегодня нету, завтра есть. В отличии от всего остального в web-производстве, вёрстку железобетонной сделать можно, и это не сложно. Всегда следует предполагать усложнение задачи.

А в таких мелочах как префиксы тем более. Даже в вашем посте может быть класс item, внутри какого-нибудь встраиваемого кода стороннего сервиса. Подобные классы — ЗЛО, и это проверено временем. Потому что там утверждается прямо противоположное, не нужно на мелких проектах городить огород, если это действительно не требуется. Думаю, спорить дальше нет смысла, я все прекрасно понял. Видимо, глядя на нечеловеческое количество проектов с версткой, хуже в разы, хочется не то что про префиксы людям рассказать, а просто отправить почитать учебник.

И кстати, я думаю, в таком случае, вам по почте пришлют печеньки …. Этот селектор сломается если понадобится обрамить внутренности ещё блоками, что бывает не редко. Возможно, кому-то это покажется странным, но иногда селектор вида. Не спорю, бояться не стоит. Но и злоупотреблять тоже. Ведь его легко сломать, внезапным усложнением вёрстки: В то же время вложенные универсальные классы могут дать и глобальный эффект: Честно говоря, я потерял ход вашей мысли. Что-то вы его очень быстро потеряли.

Я сравнивал между собой исключительно безпрефиксные решения. Если бы я увидел ". Хотя, конечно, это не сложная задача. Не могу сейчас сходу ответить, к сожалению. Я с XSLT не работал плотно. Но, если можно вывести имя изменяющееся input-a или передать любую переменную, то в чем проблема? Проблема в генерации случайного id в противном случае мы не можем гарантировать вероятность того, что такого айди на странице нет.

А генерировать его в controller-е страшный моветон. Как uniqid в PHP. Имя поле само по себе уникально, а счетчик спасет в случае с radiobutton, где имя поля может быть одинаковым. В общем, на мой взгляд, мы высасываем проблему из пальца. Если у вас эта форма будет продублирована.

К примеру две, по разному оформленные формы обратной связи, привязанные к одной сущности на странице, вызываемые или отображаемые в разных местах. Дубляж формы авторизации в контенте и блоке и т. Таких ситуаций может быть море. Мне часто попадались хитровымудрёные схемы. Это источник трууудноуловимых глюков. Сейчас я использую Jade, и такой проблемы нет, но инструменты бывают разные. А ещё бывает, что в команде работает дегенерат, который что-либо не учёл и ваши id совпали.

Да, понял о чем вы. С точки зрения верстки вариант с необорачиванием в label всяко лучше. А по поводу уникальности id, но это ведь не единственный случай, где необходим id у элемента? И до этого как-то справлялись. А по поводу глюков, то совпадение id — одно из первых что может прийти в голову в случае неверной работы. Но, опять таки, ситуации бывают разные, так что… что тут спорить. Я понял основную идею и в общем-то с ней согласен.

А функцию generate-id уже отменили? Один там выше не знает как CSS правила парсятся и думает что это магия какая-то, удивляясь почему один вариант быстрее другого, другой предлагает стили в одну строчку писать… Записывать стили в алфавитном порядке… Что мешает писать с отступами, но каждое правило на отдельной строке? Либо он понапишет такую ахинею, что работать с ней можно будет только с закрытыми глазами.

Но выше я писал, что не буду утверждать наверняка, что такой возможности нет: Как раз на такой случай. Вы на хабре, не путайтесь. Ни 1 верстальщик не будет утруждать себя сжатием png-файлов, игрой с размерами jpeg, вдумчивым удобным именованием классов, нормальным CSS кодом. Результат такого труда, ИМХО, ничего не стоит. Не в обиду верстальщикам….

Не в обиду верстальщикам Как минимум я себя этим утруждаю, возможно в другой статье кратко изложу основные моменты по оптимизации с минимальным ущербом качеству. Также я согласен с вышеотписавшимся человеком, о том, что верстальщик должен иметь навыки программиста. Нужно понимать, что будет дальше происходить с версткой, для этого нужно как минимум самому уметь интегрировать её на различные CMS и иметь представление о js и хотя бы одном из js-фреймворков.

Замечу, что я не настаивал ни на однострочном способе, ни тем более не предлагал сортировать свойства по алфавиту, хотя очевидно, что сортировка нужна, хоть в строчку, хоть столбиком. С результатами работы превращателей картинки в html за деньги заказчиков в я сталкиваюсь почти каждый день и собственно к ним адресовано написанное.

Можно пример вашей вёрстки сложного дизайна с уймой разнородных уголков, неправильной теней и пр. А это разве не Уильям Оккам говорил? По-моему, сейчас по-другому верстать уже просто неприлично двойное IMHO. Я добавил примечание в конце статьи, которое прояснит мою позицию.

Я не против БЭМ. Универсальные классы — в свое время я самостоятельно пришел именно к такой схеме, но сейчас от неё же отхожу. Всё же при всей теоретической изящности, она порождает проблемы со вложенностью. Универсальные классы годятся только для очень простых страничек. Сейчас вернулся к префиксам, своего рода лайт-версия BOM-а. Тьфу, думаю об одном, а пишу другое — лайт версия БЭМ-а. Я не произвожу вёрстку в промышленных масштабах. Проблемы с вложенностью при универсальных классах и вправду есть.

Потому вариант БЭМ-лайт это то, что надо. Называйте css-классы со смыслом, js-методы и объекты — тоже, и будет вам счастье.

Про однострочные css уже вроде бы рассказали…. Если расширить радиус с одностраничных визиток до просто визиток и среднего размера корпоративных сайтов, получится ровно то, что написано в первом же абзаце статьи. Либо вы не поняли моего комментария, либо я — вашего.

Мой несёт следующий смысл: Почитайте про вёрстку независимыми блоками, БЭМ и т. Я читал, и несколько раз применял на практике, хотя и не в тех объемах как хотелось бы. Я не верстаю крупные проекты, нет на это времени. Мне показалось, основная суть претензий — именно в разграничении сферы использования разных подходов.

Я не могу убедительно доказать, что верстать независимыми блоками небольшие сайты не надо, также нет собственно границы между небольшим, средним и крупным проектом — она условна.

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

В свою очередь такие простейшие приемы, как я описал, гарантируют понимание и возможность доделки сайта разработчиками с минимальной квалификацией. Если человек имеет представление о верстке независимыми блоками, он тем более имеет представление об описанном в статье, она не для него.

Если же человек строит структуру сайта на абсолютно спозиционированных блоках, и ему по факту прочтения статьи вдруг стало стыдно, значит я попал в цель и следующим его шагом будет уже изучение более сложных методик. Не лучше ли наоборот — учить сразу правильно? Абсолютно не согласен, что такой подход где-либо может что-то облегчить. Если вы назовёте класс не item, а news-item — сложнее код от этого не станет, зато любому разработчику сразу будет ясно, что именно описывает селектор.

Особенно, учитывая, что html может быть следующим: По той же причине, почему все до сих пор не верстают как надо. Понятно, два момента статьи вызывают сопротивление программистов и опытных верстальщиков, мол как так? О таком повороте событий я не думал, когда ее писал, но в комментариях уже приличное обсуждение, и есть смысл оставить её как есть, снабдив пометками о необходимости почитать комменты. Но в ней еще есть довольно много мелких полезных замечаний, которые, поверьте, многие игнорируют во время работы.

Почему — не знаю. Может, стоит тогда толькох и оставить? И причём тут scss и микроразметка, когда речь идёт просто о style-guide? Не надо ничего осваивать, всего лишь оформлять код так, чтобы его было удобно поддерживать не только вам, а, в том числе, разработчику, пришедшиму со стороны.

Оставить стоит для того, чтобы было понятно и обсуждение, и собсно мои заблуждения. А уж использовать id в качестве селекторов для CSS — это, как мне казалось, давно моветон.

И вы не можете использовать один id больше одного раза на странице. Про хаки для ИЕ — их однозначно стоит выносить в отдельный файл, подключаемый через Conditional Comments. Поймите, в чём дело — вы рассказали нам ваш опыт.

Да я не спорю, я учел все замечания и прокомментировал статью. Я коллекционирую ссылки на гайдлайны, пожалуй запощу тут то что собрал: Про всё сразу github. Не надо оптимизировать заранее. Нет ничего хуже каши из стилей в одном громадном файле. Лучше разделять стили и скрипты по разным файлам в соответствии со смыслом, а оптимизацию запросов делать отдельным скриптом, который и сольет и минимизирует и может быть соптимизирвет все стили и скрипты в два файла и заодно отследит изменения и сгенерит новую ссылку, если что-то измениться.

Пример сложной вёрстки

В крайнем случае сделать всю оптимизацию оффлайн, но не надо это делать заранее. То же самое по иконкам — спрайт или включение base64 в css лучше делать в скриптах. По названию классов и DOM — спорно. Во первых надо бы уже в сторону html5 смотреть и новости оформлять тегами article а заголовки статей соответствующими h1-h5, а может быть даже и header с footer-ом. И верстать по тегам от id или класса главного блока.

Чаще всего как раз разные банальные оптимизации серверов да ЦМС-ок дают процентный прирост скорости без нуля и запятой в начале значения. Может даже все десять фонов, а? С мегабайт за два часа работы можем отыграть, не? Ну, судя по комменту, вы в оптимизации нифига не рубите. Только вот я перечитал свой коммент — он вообще не об оптипизации чего либо. Он о приоритете задач.

Так что можете считать, что я ваш коммент не понял. НЛО прилетело и опубликовало эту надпись здесь. Как-то вы упустили нечто важное. Тегами разметки лучше пользоваться по прямому назначению. Если вы имеете дело со списком, пользуйтесь ul, например. Список новостей как раз сюда подходит. Помимо этого, на мой вкус, не стоит пренебрегать тем фактом, что сам порядок следования элементов часто является достаточной информацией для определения того, как их отображать.

Поэтому нагромождение уточняющих классов зачастую является избыточным, как и вашем примере. Ваш пример в таком случае превращается из этого: В противном случае код становится нечитаем и существенно затрудняется отладка CSS, так как номер строки фактически является уникальным идентификатором элемента кода.

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

Перемены вообще предполагают некоторый труд — не вижу в этом ничего страшного. И ещё небольшое замечание. Да и знаков меньше будет в итоге. Да разделение всё же структуры разметки и правил отображения. Ну и энтропия чуть помедленнее будет расти. Мой пост не о достаточном, а о минимально необходимом. Указанные вами селекторы подействуют на гораздо более широкий круг элементов, чем это необходимо. А проблема случайно зацепившихся правил, наверное, в топе всех проблем связанных с CSS.

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

При имплементации дизайна на сложных cms такое возможно. Или в будущем какой-нибудь программист, которому передали проект, решит поменять местами теги по запросу клиента. Во всех этих случаях прямая наследованность будет нарушена и дизайн сломается. Через месяц присылают верстку — обнять и плакать, а фрилансер ничего исправлять не будет — он деньги получил и исчез. ПОЧЕМУ, ПОЧЕМУ, ПОЧЕМУ они используют тег p?!!!

Для всего подряд, для текста новостей, для контейнеров?!!! Почему они пишут в стилях. Почему они не хотят читать справочники и включать мозг? Зайди на фриланс, поверстай для описываемой категории людей. Пора бы юзать семантику и html5, и тогда месиво из классов превращается в это: Юзера zelibobla выше зря заминусовали — я его отплюсовал. Только и у него семантики не хватает. Если есть заголовок новости — так и делайте его заголовком. Это и есть семантика. Минусятор, хоть отпиши, интересно же знать твоё мнение.

Первый в этом топике. Не стоит без особой необходимости переносить теги в CSS. К примеру, стиль для news h3 может вам аукнуться в самой новости, в случае, если администратор будет использовать этот тег в тексте. В случае усложнения вёрстки, внутри news может оказаться несколько типов заголовков. И записали это в стили. Почти наверняка вам потребуются отдельные теги для реализации этой задачи. Вы их поместите в ul? Говорящие названия классов помогут вам и при написании, и при поддержке в будущем.

Не экономьте на спичках. При использовании сжатия, все ваши усердия по экономии 3. Для этой цели придумали классы. И не стоит экономить буквы в CSS, особенно если используется gzip. Чем больше я верстаю, хотя я и не верстальщик, тем больше я понимаю, что не стоит экономить на префиксах, внятных именах классов, уповать на имена тегов и т. Я не верстальщик, я пишу такой код, с которым мне потом работать. И если он будет макс.

А время — деньги. Судя по этой и одной новой теме, верстальщикам вообще побарабану, что с их кодом потом кому то работать. Повторюсь, я не верстальщик. Но сверстать мне уже пришлось многое. В том числе и достаточно сложные дизайны. Были даже попапы в несколько уровней вложенности, дизайн которых изменяется на стадии реализации проекта несколько раз. Я раз наступал на грабли и почти везде нашёл способы как подстелить себе солому. Это всё сэкономит вам уйму времени и нервов.

Что то много получилось… Надеюсь не зря: Вам говорят не об экономии букв. Красивый код часто краток. Но краткость — не самоцель. Вам говорят о семантике. Потребность в этой избыточности отсутствует. Упорной заменой классами тегов, отказом от использования порядка их следования тегов везде где это надо и не надо, вы отказываетесь от самой спецификации. Так можно доверстаться до одних div-ов.

Впрочем, вопрос конфликта системных и пользовательских тегов, на мой взгляд, решаться должен не через закорючки в CSS, а через фильтрацию пользовательского ввода. По-моему, очевидно, что речь идёт о заголовке элемента списка новостей.

Учитывайте так же что лишние уточнения негативно складываются на производительности, и div. Я поясню, а вы меня поправьте, если я ошибаюсь. Вам на вход поступила вёрстка, к которой вы не можете притрагиваться. CSS-файл непикасаем, HTML файл, напротив, прикасаем — такие условия. Ниже по порядку подключения вы можете подключить свой CSS, который в случае совпадения правил переопределит все правила определённые ранее.

И таким образом вы кастомизируете данные изначальные стили. И вот на входе вам упал div. Для его переопределения достаточно воспользоваться точно таким же селектором: Возможно, вы имели ввиду дополнение изложенных в первом файле правил своими новыми правилами так, чтобы ранее определённые, если они не конфликтуют, остались в силе.

Но и в этом случае вам достаточно именно такого селектора div. Наверное, я вас неверно понял, да? Попросту говоря — это тавтология.

Статья как-будто написана в ответ на комментарий, спасибо за перевод. Читал где-то раньше, но не мог найти. По приведённым ссылкам о скорости селекторов получается, что вариант. На моей машине в тесте разница между самым-самым минимумом и максиумом 0. То есть это та самая экономия на спичках, которая вменяется в мою позицию как слабая сторона. Нет смысла об этом вообще рассуждать, так как это несущественно. Вот другое дело — соображения о семантике из последней данной вами ссылки и там ещё на Яндексовых ребят ссылка есть в конце статьи: Но, видно, моё занудство вынесет не каждый, так что вот сам добавлю их к вашей статье, так как они подкрепляют вашу позицию, что в общем, не делает её заметно сильнее.

На мой взгляд, инструмент должен быть соразмерен с задачей, как мне кажется. То, о чём пишет автор статьи о семантике — это автомобиль-амфибия. Как я понял, он предлагает с самого начала писать правила CSS, руководствуясь максимальной абстракцией, независимо от того, какой проект вы пишете.

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

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

Вероятность наступления таких событий прямо пропорциональна смыслу придумывать уникальные классы и распихивать их в каждый элемент. Оригинальных, так как в противном случае вы будете иметь конфликт классов. Вот такая вот красота вас ждёт, как в JQueryUI: Насчет скорости селектора, все браузеры разбирают селектор справа налево. Чтобы переопределить такой длинный селектор, придется воспользоваться селектором не меньшей длины.

Из-за этого падает читаемость и такие стили трудней поддерживать. Экономия в количестве символов в разметке это слишком слабая оптимизация. Повторяющиеся классы хорошо поддаются сжатию, экономия получается копеечной. Такого рода оптимизациями можно заняться если у вас Google PageSpeed покажет и заняться больше нечем.

Я начал свою позицю по этой статье с примера: При этом, давайте условимся, что объекты с классом item и подклассом date с большой вероятностью могут встретиться в других блоках вёрстки. В комментариях к новости, например. Важны такие параметры, как скорость разработки, простота поддержки, читаемость кода и отсутствие багов. Я надеюсь, что не длиной. Однако, отреагировал я именно на ваше замечание о длине: Значит мы не про длину.

Я не совсем понял смысла вот этих слов: И какое это имеет отношение к дискуссии? Коль скоро всё это имеет класс news, очевидно, речь идёт о контейнере списка новостей и его элементах. Какие с этим сложности? Насчёт span меня справедливо поправили в этой ветке, что точнее пользоваться тегом H3, к примеру. Тег а говорит нам о том, что речь идёт о ссылке.

Какие проблемы могут быть с пониманием этих простых вещей? В своей аргументации вы сравниваете таблицы стилей, упуская из виду то, как чудовищно разбухает при вашем подходе HTML код.

И это при том, что таблица на весь проект одна и в ней, казалось бы, можно и не скупиться на семантику, облегчающую её чтение.

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

Покажите мне пожалуйста, как вы с помощью CSS собираетесь превратить текст в ссылку? Что будет с вашим селектором ul. Насчёт угадывания — вроде слабоумных нет. Вы к чему клоните? На подобие героя одного романа, который на всякий случай каждый день выходил из дома в доспехах? Цель оправдывает средства по вашему? По крайней мере поправка на H3 делалась именно из этих соображений. Приведу вам контраргумент из JQueryUI: Можно я вас опережу? Мы же про поддержку? У формы атрибут action обязательный, а не name.

Имелось в виду, что просто не подойдет. Метки лучше разделять запятой. Интересные публикации Хабрахабр Geektimes. Как пенсионный фонд сливает персональные данные GT. Почему юристы никак не договорятся о криптовалютах GT. Как я оживлял VCSA 6. Насколько SpaceX сбила цены запусков ракет GT. Простая валидация формы без JS. Разделы Публикации Хабы Компании Пользователи Песочница.

Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.