1. ul.news > li > span превратится по всей видимости в ul.news > li > a
. Вы к чему клоните? К тому, что вот через полгода поменять «span» на «a» в таблице стилей – это гораздо более суровое зло, чем наклепать классов в HTML странице загодя, даже на случай если такой проблемы вообще не возникнет? На подобие героя одного романа, который на всякий случай каждый день выходил из дома в доспехах? Цель оправдывает средства по вашему?
2. span был заголовком, содержащим дату. По крайней мере поправка на H3 делалась именно из этих соображений. Приведу вам контраргумент из JQueryUI:
Что здесь просто блок, а что текст? ui-datepicker-header наследует от линейки заголвоков H5 или нет?
3. Вы мне про gzip толкнули, чтобы потом снова сказать «мы же не про gzip, а про поддержку»? :) Можно я вас опережу? Мы же про поддержку? gzip-то тут при чём?
Я надеюсь, что не длиной. Однако, отреагировал я именно на ваше замечание о длине:
Чтобы переопределить такой длинный селектор, придется воспользоваться селектором не меньшей длины. Из-за этого падает читаемость и такие стили трудней поддерживать.
Хорошо. Значит мы не про длину. Про поддержку.
Я не совсем понял смысла вот этих слов:
угадайте что есть что, и как сделать некоторые даты ссылкой, когда об этом попросят через полгода
Покажите мне пожалуйста, как вы с помощью CSS собираетесь превратить текст в ссылку? И какое это имеет отношение к дискуссии?
Насчёт угадывания – вроде слабоумных нет. ul – список, li – элемент списка. Коль скоро всё это имеет класс news, очевидно, речь идёт о контейнере списка новостей и его элементах. Какие с этим сложности?
Насчёт span меня справедливо поправили в этой ветке, что точнее пользоваться тегом H3, к примеру. Тег а говорит нам о том, что речь идёт о ссылке. Какие проблемы могут быть с пониманием этих простых вещей?
В своей аргументации вы сравниваете таблицы стилей, упуская из виду то, как чудовищно разбухает при вашем подходе HTML код. И это при том, что таблица на весь проект одна и в ней, казалось бы, можно и не скупиться на семантику, облегчающую её чтение. Впрочем в наших с вами примерах не видно что-то, чтобы предложенный мной вариант был существенно более громоздким.
HTML-кода же, который этой таблицей пользуется много и здесь как раз способность верстальщика написать код максимально лёгким при этом не потеряв смысл разметки – штука крайне приятная. И поддерживать такой код – сплошное удовольствие. Разве не так?
Оригинальных, т.к. в противном случае вы будете иметь конфликт классов. Разве нет?
Вот такая вот красота вас ждёт, как в JQueryUI: .ui-datepicker select.ui-datepicker-month-year {width: 100%;}
Из этого примера, приведите пожалуйста, правило, переопределяющее отображение даты новости, чтобы оно было короче чем: ul > li > h3 хоть по количеству символов, хоть по количеству итераций поиска элементов движком броузера. При этом, давайте условимся, что объекты с классом item и подклассом date с большой вероятностью могут встретиться в других блоках вёрстки. В комментариях к новости, например.
Эммм. По приведённым ссылкам о скорости селекторов получается, что вариант .unque_class_container .unique_class_list_item .unique_class_item_header будет работать примерно в 10 раз медленее, чем ul > li > h3.
Цитата:
«
Еще стоит обратить внимание на существенное (до 2,5 раз) ускорение при переходе от CSS1-селекторов к CSS2 (от div p к div>p, в тех браузерах, которые это поддерживают).
»
Статья вообще довольно бородатая, 2008 год всё-таки. На моей машине в тесте разница между самым-самым минимумом и максиумом 0.15 секунд при том, что тест старается нагрузить броузер. То есть это та самая экономия на спичках, которая вменяется в мою позицию как слабая сторона. Нет смысла об этом вообще рассуждать, т.к. это несущественно.
Я вообще ожидал, что мне кто-нибудь в пример приведёт вёртску от JQueryUI, например, или от Twitter Bootstrap. Но, видно, моё занудство вынесет не каждый, так что вот сам добавлю их к вашей статье, т.к. они подкрепляют вашу позицию, что в общем, не делает её заметно сильнее.
Оговорюсь, правда, что у Twitter Bootstap во многих местах встречаются ">", но нечасто. Примерно в 5% селекторов.
На мой взгляд, инструмент должен быть соразмерен с задачей, как мне кажется. То, о чём пишет автор статьи о семантике – это автомобиль-амфибия. Как я понял, он предлагает с самого начала писать правила CSS, руководствуясь максимальной абстракцией, независимо от того, какой проект вы пишете. Дескать, смотрите как пишут большие парни, и делайте также. Нет. Это неверно.
Если вы задумали написать фактически CSS-фреймворк, конечно, вам потребуется внушительная абстракция. Вы не можете знать наперёд, будет ли у вас список именно списком новостей, последуют ли непосредственно под заголовком сами новости или они будут взяты в дополнительный контейнер.
Но в реальной жизни, с реальными проектами ответы на все эти вопросы у вас есть. И нет необходимости утруждать себя выдумыванием оригинальных названий классов и насаждением этих названий в каждом элементе списка.
Всё это – избыточная тавтология, мусор, который может потребоваться только в том случае, если из своего сайта про гороскопы вы пожелаете сделать некий шаблон, используемый в дальнейшем для сайта по продаже формочек для кексов. Вероятность наступления таких событий прямо пропорциональна смыслу придумывать уникальные классы и распихивать их в каждый элемент.
«Учитывайте так же что лишние уточнения негативно складываются на производительности, и div.news хуже чем просто .news»
Это любопытно. Можно какой-то пруфлинк?
«Плюс ко всему, если вам понадобится в каком-то случае переопределить одно из свойств, вам придется использовать еще более специфичный селектор, как .error div.news_layout > ul > li > h3»
Этот аргумент я возможно не совсем понял. Я поясню, а вы меня поправьте, если я ошибаюсь.
Вам на вход поступила вёрстка, к которой вы не можете притрагиваться. CSS-файл непикасаем, HTML файл, напротив, прикасаем — такие условия. Ниже по порядку подключения вы можете подключить свой CSS, который в случае совпадения правил переопределит все правила определённые ранее. И таким образом вы кастомизируете данные изначальные стили.
И вот на входе вам упал div.news_layout > ul > li > h3. Для его переопределения достаточно воспользоваться точно таким же селектором: div.news_layout > ul > li > h3.
Возможно, вы имели ввиду дополнение изложенных в первом файле правил своими новыми правилами так, чтобы ранее определённые, если они не конфликтуют, остались в силе. Но и в этом случае вам достаточно именно такого селектора div.news_layout > ul > li > h3.
Наверное, я вас неверно понял, да?
В посте, на который вы ответили, я описал, почему <h3 class="news-title"> представляется мне как раз-таки семантически некорректным. Попросту говоря – это тавтология. Все пишут «грабли», но, собственно, убедительных примеров граблей пока что-то невидно. Разве что «это отвратительный селектор» :)
Вы как-то передёрнули. Вам говорят не об экономии букв. Красивый код часто краток. Но краткость – не самоцель.
Вам говорят о семантике. Есть тег H3, который расшифровывается как «Third level header» и переводится на русский как «Заголовок третьего уровня».
Вы пишете: <H3 class="news-title">, что расшифровывается как «Third leve header of News title class». На русский это можно перевсти как «Заголовок третьего уровня класса Заголовок новости». Слово «заголовок» здесь избыточное. Потребность в этой избыточности отсутствует.
А учитывая, что сидит этот заголовок как правило в контейнере с классом news, то и слово «новости» – избыточное.
Упорной заменой классами тегов, отказом от использования порядка их следования тегов везде где это надо и не надо, вы отказываетесь от самой спецификации. Так можно доверстаться до одних div-ов.
Ваши аргументы:
1. «К примеру, стиль для #news h3 может вам аукнуться в самой новости, в случае, если администратор будет использовать этот тег в тексте»
Если есть такая вероятность, сужайте действие правила только на первый элемент. div.news_layout > ul > li > h3:first-child
Ведь и тег из вашего примера (чисто гипотетически) может попать в текст, набранный администратором. Впрочем, вопрос конфликта системных и пользовательских тегов, на мой взгляд, решаться должен не через закорючки в CSS, а через фильтрацию пользовательского ввода. Вы не согласны?
2. «h3 в CSS будет не ясен, всё что сможет понять человек сопровождающий такой код, так это то, что этот селектор, видимо, говорит о каком то заголовке.»
Вот вам пример: div.news_layout > ul > li > h3. По-моему, очевидно, что речь идёт о заголовке элемента списка новостей. Нет?
Соображения «А если всё поменяется» я прокомментировал в самом начале. Там же я написал, почему мне кажется, что всё-таки стоит отказываться от злоупотребления классами в пользу «>».
«Достаточно» – это очень точное слово вы употребили. Мой пост не о достаточном, а о минимально необходимом. Указанные вами селекторы подействуют на гораздо более широкий круг элементов, чем это необходимо. А проблема случайно зацепившихся правил, наверное, в топе всех проблем связанных с CSS.
«Достаточно» – это очень точное слово вы употребили. Мой пост не о достаточном, а о минимально необходимом. Указанные вами селекторы подействуют на гораздо более широкий круг элементов, чем это необходимо. А проблема случайно зацепившихся правил, наверное, в топе всех проблем связанных с CSS.
Как-то вы упустили нечто важное. Тегами разметки лучше пользоваться по прямому назначению. Если вы имеете дело со списком, пользуйтесь ul, например. Список новостей как раз сюда подходит.
Помимо этого, на мой вкус, не стоит пренебрегать тем фактом, что сам порядок следования элементов часто является достаточной информацией для определения того, как их отображать. Поэтому нагромождение уточняющих классов зачастую является избыточным, как и вашем примере.
А таблица стилей, соответствено, будет примерно такой:
ul.news{
some rules of news container box
}
ul.news > li{
some rules of news item
}
ul.news > li > span{
some rules of date that follow only in the first <span> tag after <li>
}
ul.news > li > a{
some rules of link that follow only in the first <a> tag after <li>
}
ul.news > li > a.hot{
some extra rules of link for the hot news
}
Я сторонник того, что каждому правилу в css нужна своя строка за редким исключением left, top или width, height. В противном случае код становится нечитаем и существенно затрудняется отладка CSS, т.к. номер строки фактически является уникальным идентификатором элемента кода. Когда какой-нибудь дебаггер пишет вам на какой строке у вас определено правило, вызывающее проблемы и требующее правок, в случае с подходом, который предлагаете вы – номер строки ещё оставляет задачу по поиску конкретной позции в строке, что замедляет дебаггинг в разы. Так что не знаю даже за что вам говорят спасибо программисты.
Там выше были возражения относительного использования порядка следования элементов как несущей информации для определения стилей. Главный аргумент возражающих: «А если всё поменяется».
Тут надо рассматривать вопрос цены. Благодаря использованию «>» в CSS удаётся существенно сократить количество букв при этом совершенно не потеряв смысл. На мой взгляд, весьма убедительный аргумент против «Всё поменяется». Перемены вообще предполагают некоторый труд – не вижу в этом ничего страшного.
И ещё небольшое замечание. Обратите внимание, что я убрал теги <strong></strong> в табицу стилей, как раз таки в соответствии с вашим предложением наделять правила некоторым, понятным людям смыслом. Да и знаков меньше будет в итоге. Да разделение всё же структуры разметки и правил отображения. Ну и энтропия чуть помедленнее будет расти.
Эвона как. А не поделитесь ссылочкой на какой-нибудь материал, насколько вообще на самом деле прожорливы подобные вызовы, как устроен этот кеш (что будет, если какое-либо свойство элемента поменялось, минуя Jquery) и всё такое?
Правильное слово тут «Антипаттерн» вместо «Велосипед», если я не ошибаюсь. Велосипедов в статье, собственно, ровно один – это обращение к замусоренным атрибутам – и тот крохотный.
Из антипаттернов часто ещё можно встретить бесконечное дёргание одного и того же хендлера или как его назвать.
var _handler = $( '#one_long_selector' );
_handler.someAction();
...
_handler.getSomeAttribute();
...
_handler.writeSomeValue( value );
Во-первых, это экономит ресурсы системы по поиску нужного элемента в DOM. Ищется он теперь один раз вместо трёх. Во-вторых, мне такой код проще читать и менять, если что случилось.
Вы исходите из того, что сотрудникам интересно то, что произносит ваше «отверстие внизу головы». Это не всегда так. Дело в предпосылках. Люди хотят знать зарплату соседа из любопытсва, а вы им про доходность бизнеса и денежные потоки.
Расскажите лучше про тот страшный день, когда вы всех вообще уволили. Пахнет драмой.
Я просто вывода, лежащего на поверхности, не увидел: «Не занимайся тем, чем не хочешь» – поэтому и отписался. Без такого умозаключения через пару лет мы можем увидеть от этого же автора новую статью о том, как он классно наломал дров в отрасли, которая ему неинтересна.
«Я открыл студию около года назад, и единственное, что я действительно хотел делать — это программировать.»
Правильным шагом после осознания того, что вы действительно хотите делать, было бы закрыть студию или продать, если она к тому моменту уже представляла из себя интерес на рынке. В крайнем случае срочно нанять или пригласить в учредители+функционеры управленца. То есть срочно снять с себя то, в чём вы разбираетесь и не хотите разбираться.
Всё остальное при таком положении вещей кажется вторичным.
Вы взяли нетипичных мексиканцев и сравнили их с типичными американцами. Такая не совсем честная форма манипулирования читателем, из которой он, надо полагать, должен был сделать вывод целых нациях. Подобную риторику сейчас можно увидеть на НТВ.
Вот бы этот опрос рекрутёрам показать. А то все начинают со слов «В перспективе переход на управление командой» или там «Управление IT отделом», не поинтересовавшись даже интересно ли это вообще.
ul.news > li > spanпревратится по всей видимости вul.news > li > a. Вы к чему клоните? К тому, что вот через полгода поменять «span» на «a» в таблице стилей – это гораздо более суровое зло, чем наклепать классов в HTML странице загодя, даже на случай если такой проблемы вообще не возникнет? На подобие героя одного романа, который на всякий случай каждый день выходил из дома в доспехах? Цель оправдывает средства по вашему?2. span был заголовком, содержащим дату. По крайней мере поправка на H3 делалась именно из этих соображений. Приведу вам контраргумент из JQueryUI:
Что здесь просто блок, а что текст? ui-datepicker-header наследует от линейки заголвоков H5 или нет?
3. Вы мне про gzip толкнули, чтобы потом снова сказать «мы же не про gzip, а про поддержку»? :) Можно я вас опережу? Мы же про поддержку? gzip-то тут при чём?
Хорошо. Значит мы не про длину. Про поддержку.
Я не совсем понял смысла вот этих слов:
Покажите мне пожалуйста, как вы с помощью CSS собираетесь превратить текст в ссылку? И какое это имеет отношение к дискуссии?
Насчёт угадывания – вроде слабоумных нет. ul – список, li – элемент списка. Коль скоро всё это имеет класс news, очевидно, речь идёт о контейнере списка новостей и его элементах. Какие с этим сложности?
Насчёт span меня справедливо поправили в этой ветке, что точнее пользоваться тегом H3, к примеру. Тег а говорит нам о том, что речь идёт о ссылке. Какие проблемы могут быть с пониманием этих простых вещей?
В своей аргументации вы сравниваете таблицы стилей, упуская из виду то, как чудовищно разбухает при вашем подходе HTML код. И это при том, что таблица на весь проект одна и в ней, казалось бы, можно и не скупиться на семантику, облегчающую её чтение. Впрочем в наших с вами примерах не видно что-то, чтобы предложенный мной вариант был существенно более громоздким.
HTML-кода же, который этой таблицей пользуется много и здесь как раз способность верстальщика написать код максимально лёгким при этом не потеряв смысл разметки – штука крайне приятная. И поддерживать такой код – сплошное удовольствие. Разве не так?
Вот такая вот красота вас ждёт, как в JQueryUI:
.ui-datepicker select.ui-datepicker-month-year {width: 100%;}Из этого примера, приведите пожалуйста, правило, переопределяющее отображение даты новости, чтобы оно было короче чем:
ul > li > h3хоть по количеству символов, хоть по количеству итераций поиска элементов движком броузера. При этом, давайте условимся, что объекты с классом item и подклассом date с большой вероятностью могут встретиться в других блоках вёрстки. В комментариях к новости, например..unque_class_container .unique_class_list_item .unique_class_item_headerбудет работать примерно в 10 раз медленее, чемul > li > h3.Цитата:
«
Еще стоит обратить внимание на существенное (до 2,5 раз) ускорение при переходе от CSS1-селекторов к CSS2 (от div p к div>p, в тех браузерах, которые это поддерживают).
»
Статья вообще довольно бородатая, 2008 год всё-таки. На моей машине в тесте разница между самым-самым минимумом и максиумом 0.15 секунд при том, что тест старается нагрузить броузер. То есть это та самая экономия на спичках, которая вменяется в мою позицию как слабая сторона. Нет смысла об этом вообще рассуждать, т.к. это несущественно.
Вот другое дело – соображения о семантике из последней данной вами ссылки и там ещё на Яндексовых ребят ссылка есть в конце статьи: bem.github.com/bem-method/pages/beginning/beginning.ru.html
Я вообще ожидал, что мне кто-нибудь в пример приведёт вёртску от JQueryUI, например, или от Twitter Bootstrap. Но, видно, моё занудство вынесет не каждый, так что вот сам добавлю их к вашей статье, т.к. они подкрепляют вашу позицию, что в общем, не делает её заметно сильнее.
Оговорюсь, правда, что у Twitter Bootstap во многих местах встречаются ">", но нечасто. Примерно в 5% селекторов.
На мой взгляд, инструмент должен быть соразмерен с задачей, как мне кажется. То, о чём пишет автор статьи о семантике – это автомобиль-амфибия. Как я понял, он предлагает с самого начала писать правила CSS, руководствуясь максимальной абстракцией, независимо от того, какой проект вы пишете. Дескать, смотрите как пишут большие парни, и делайте также. Нет. Это неверно.
Если вы задумали написать фактически CSS-фреймворк, конечно, вам потребуется внушительная абстракция. Вы не можете знать наперёд, будет ли у вас список именно списком новостей, последуют ли непосредственно под заголовком сами новости или они будут взяты в дополнительный контейнер.
Но в реальной жизни, с реальными проектами ответы на все эти вопросы у вас есть. И нет необходимости утруждать себя выдумыванием оригинальных названий классов и насаждением этих названий в каждом элементе списка.
Всё это – избыточная тавтология, мусор, который может потребоваться только в том случае, если из своего сайта про гороскопы вы пожелаете сделать некий шаблон, используемый в дальнейшем для сайта по продаже формочек для кексов. Вероятность наступления таких событий прямо пропорциональна смыслу придумывать уникальные классы и распихивать их в каждый элемент.
«Учитывайте так же что лишние уточнения негативно складываются на производительности, и div.news хуже чем просто .news»
Это любопытно. Можно какой-то пруфлинк?
«Плюс ко всему, если вам понадобится в каком-то случае переопределить одно из свойств, вам придется использовать еще более специфичный селектор, как
.error div.news_layout > ul > li > h3»Этот аргумент я возможно не совсем понял. Я поясню, а вы меня поправьте, если я ошибаюсь.
Вам на вход поступила вёрстка, к которой вы не можете притрагиваться. CSS-файл непикасаем, HTML файл, напротив, прикасаем — такие условия. Ниже по порядку подключения вы можете подключить свой CSS, который в случае совпадения правил переопределит все правила определённые ранее. И таким образом вы кастомизируете данные изначальные стили.
И вот на входе вам упал
div.news_layout > ul > li > h3. Для его переопределения достаточно воспользоваться точно таким же селектором:div.news_layout > ul > li > h3.Возможно, вы имели ввиду дополнение изложенных в первом файле правил своими новыми правилами так, чтобы ранее определённые, если они не конфликтуют, остались в силе. Но и в этом случае вам достаточно именно такого селектора
div.news_layout > ul > li > h3.Наверное, я вас неверно понял, да?
В посте, на который вы ответили, я описал, почему
<h3 class="news-title">представляется мне как раз-таки семантически некорректным. Попросту говоря – это тавтология. Все пишут «грабли», но, собственно, убедительных примеров граблей пока что-то невидно. Разве что «это отвратительный селектор» :)Вам говорят о семантике. Есть тег H3, который расшифровывается как «Third level header» и переводится на русский как «Заголовок третьего уровня».
Вы пишете:
<H3 class="news-title">, что расшифровывается как «Third leve header of News title class». На русский это можно перевсти как «Заголовок третьего уровня класса Заголовок новости». Слово «заголовок» здесь избыточное. Потребность в этой избыточности отсутствует.А учитывая, что сидит этот заголовок как правило в контейнере с классом news, то и слово «новости» – избыточное.
Упорной заменой классами тегов, отказом от использования порядка их следования тегов везде где это надо и не надо, вы отказываетесь от самой спецификации. Так можно доверстаться до одних div-ов.
Ваши аргументы:
1. «К примеру, стиль для #news h3 может вам аукнуться в самой новости, в случае, если администратор будет использовать этот тег в тексте»
Если есть такая вероятность, сужайте действие правила только на первый элемент.
div.news_layout > ul > li > h3:first-childВедь и тег из вашего примера (чисто гипотетически) может попать в текст, набранный администратором. Впрочем, вопрос конфликта системных и пользовательских тегов, на мой взгляд, решаться должен не через закорючки в CSS, а через фильтрацию пользовательского ввода. Вы не согласны?
2. «h3 в CSS будет не ясен, всё что сможет понять человек сопровождающий такой код, так это то, что этот селектор, видимо, говорит о каком то заголовке.»
Вот вам пример:
div.news_layout > ul > li > h3. По-моему, очевидно, что речь идёт о заголовке элемента списка новостей. Нет?Помимо этого, на мой вкус, не стоит пренебрегать тем фактом, что сам порядок следования элементов часто является достаточной информацией для определения того, как их отображать. Поэтому нагромождение уточняющих классов зачастую является избыточным, как и вашем примере.
Ваш пример в таком случае превращается из этого:
В это:
А таблица стилей, соответствено, будет примерно такой:
Я сторонник того, что каждому правилу в css нужна своя строка за редким исключением left, top или width, height. В противном случае код становится нечитаем и существенно затрудняется отладка CSS, т.к. номер строки фактически является уникальным идентификатором элемента кода. Когда какой-нибудь дебаггер пишет вам на какой строке у вас определено правило, вызывающее проблемы и требующее правок, в случае с подходом, который предлагаете вы – номер строки ещё оставляет задачу по поиску конкретной позции в строке, что замедляет дебаггинг в разы. Так что не знаю даже за что вам говорят спасибо программисты.
Там выше были возражения относительного использования порядка следования элементов как несущей информации для определения стилей. Главный аргумент возражающих: «А если всё поменяется».
Тут надо рассматривать вопрос цены. Благодаря использованию «>» в CSS удаётся существенно сократить количество букв при этом совершенно не потеряв смысл. На мой взгляд, весьма убедительный аргумент против «Всё поменяется». Перемены вообще предполагают некоторый труд – не вижу в этом ничего страшного.
И ещё небольшое замечание. Обратите внимание, что я убрал теги
<strong></strong>в табицу стилей, как раз таки в соответствии с вашим предложением наделять правила некоторым, понятным людям смыслом. Да и знаков меньше будет в итоге. Да разделение всё же структуры разметки и правил отображения. Ну и энтропия чуть помедленнее будет расти.Из антипаттернов часто ещё можно встретить бесконечное дёргание одного и того же хендлера или как его назвать.
Правильное, на мой взгляд:
Во-первых, это экономит ресурсы системы по поиску нужного элемента в DOM. Ищется он теперь один раз вместо трёх. Во-вторых, мне такой код проще читать и менять, если что случилось.
Расскажите лучше про тот страшный день, когда вы всех вообще уволили. Пахнет драмой.
Правильным шагом после осознания того, что вы действительно хотите делать, было бы закрыть студию или продать, если она к тому моменту уже представляла из себя интерес на рынке. В крайнем случае срочно нанять или пригласить в учредители+функционеры управленца. То есть срочно снять с себя то, в чём вы разбираетесь и не хотите разбираться.
Всё остальное при таком положении вещей кажется вторичным.