Вёрстка со смыслом
Этой весной в Москве состоялась конференция РИТ 2011, на которой была представлена довольно сильная клиент-сайд секция. И пока одни видео только готовятся к публикации, а другие выкачиваются из RTMP-потока, в котором их спрятали ребята из COMDI, предлагаю вам посмотреть мой доклад «Вёрстка со смыслом. Новая семантика HTML5».
Сама презентация, работающая прямо в браузере, доступна для внимательного изучения, а видео можно скачать на его странице на Vimeo. Остальные видео с конференции, имеющие отношение к клиент-сайд разработке, позже появятся на канале Web Standards Days.
Комментарии
70Спасибо, Вадим!
Очень помогло разложить известное по полочкам в голове.
Вадим, у вас на сайте нет RSS иконки. Можно использовать RSS?
Игорь, если коротко — да, адрес правильный. Но я думал, что уже все браузеры и RSS-читалки научились автоматически обнаруживать RSS-поток сайта, поэтому и не задумывался о дополнительной иконке.
Вадим, спасибо вам за эту замечательную презентацию.
Сейчас сам осваиваю семантическую верстку, уже где-то что-то реализовываю, но все равно остаются вопросы. Например, как с точки зрения семантики правильнее использовать тег h1?
Внутри непосредственно статьи (пусть статья завернута в article) или вне ее? То есть, сначала h1, потом следом за ним article.
До просмотра этой презентации читал несколько статей на тему семантики и везде как-то по-разному делали. То так, то эдак. Та же Википедия, к примеру, ставит заголовок до текста самой статьи, а вы в презентации поставили заголовок внутрь статьи.
С уважением, Александр.
И вопрос вдогонку - может ли идти параграф текста без подзаголовка? Допустим, огромная статья об авиастроении, идет заголовок h1 "Авиастроение", потом немного текста (что это вообще такое, зачем статья написана), потом подзаголовок h2 "Авиастроение в 50х годах" и дальше текст.
Или же вступление тоже следует озаглавливать?
Александр, что касается
<h1>и вводной части, то мне кажется самым удачным вариантом будет разместить его так:Благодарю.
Игорь, специально для вас добавил в шапку сайта RSS-иконку :)
Вадим, спасибо за очень интересный доклад.
Правда вот я не очень согласен с вам по поводу элемента <section>.
Вы говорите, что «<section> — структурный элемент самого высокого уровня», но мне кажется, что значимость этого тега меньше, чем значимость <article> и <aside>. Возможно, я и ошибаюсь, но я уже давно сайдбары, выполненные с помощью <aside> (что возможно не очень верно), разбиваю на разделы с помощью <section>. Не стоит также забывать, что outliner формирует структурный блок, когда используется этот тег. Например, в вашей презентации outliner формирует такую стркутуру:
1.Untitled BODY
1.1.Untitled SECTION
1.1.1.Вёрстка со смыслом
1.1.1.1.Новая семантика HTML5
1.2.Untitled SECTION
1.2.1.Семантика
1.3.Untitled SECTION
1.3.1.Уровни семантики
Мне кажется, что в этом случае <article> было бы достаточно.
> Допустим, огромная статья об авиастроении, идет заголовок h1 "Авиастроение", потом немного текста (что это вообще такое, зачем статья написана), потом подзаголовок h2 "Авиастроение в 50х годах"
Я бы сделал так:
<section> здесь используется лишь для того, чтобы быстрее находить нужные главы. Если главы не большие, то одних только заголовков хватит. Если же вводная часть совсем не большая, то можно <header> опустить, а вступительную часть обернуть в <div>.
Вадим, спасибо! Подписался!
В Firefox 4 пропала иконка подписки на RSS
Сергей, наверное вы правы насчёт заголовка внутри
<article>. Меня смутила структура документа на сайте CSS1K, надо внимательнее вчитаться в спецификацию. Что касается<section>, я чего-то не того начитался (надо бы поискать эту статью) и возомнил его глобальной обёрткой. Спецификация говорит всё ясно: тематическая группировка.div.shower как обертка в презентации улыбнул :)
Для тех кому интересно - демонстрация семантики от микрософта, очень даже наглядно.
Сегрей-2, код Shower'а не претендует на структурную безупречность. Такую вещь, как набор слайдов, сложно правильно и однозначно структурировать. Но вот Shower 2, который сейчас в разработке, в этом смысле будет гораздо лучше.
Что касается «наглядной семантики», то ребята из Microsoft меня не очень впечатлили. По крайней мере, на полное руководство это не тянет.
У вас пока тоже не тянет, но можете некоторые идеи повзаимствовать.
Насчет shower, вы правда будете использовать этот класс ещё раз? Может все-таки slider? :)
Сергей-2, я понимаю, но Shower — это название моего движка для презентаций, не вижу смысла менять название абстрактного корневого элемента, это некоторое пространство имён.
Я, если честно, никогда не понимал, как наименование идентификаторов и классов влияют на семантику (кроме микроформатов, но это несколько другое). Всё-таки предназначение у них другое: связать html с css и js. Тут уже важна не семантика, а удобство написания и разбирание (если работа в команде) кода. Так что совершенно не важно, как это называется — .shower, .slider или .presentation.
Иногда ведь до смешного доходит. Ден Сидерхольм в своей новой книжке одним из недостатков clearfix называл его несемантичность. Знаете, как он решил проблему? Переименовал его в .group и успокоился.
В html5 показать для чего предназначается блок, можно с помощью атрибута role.
Да, Вадим, хотел вас спросить об одной вещи. Есть небольшое меню в подвале (примерно, как у вас «wp», «html», «css»). С появлением тега
<nav>обязательно ли их ещё дополнительно оборачивать в неупорядоченный список. Спеки и доктора однозначного ответа не дают, но во всех примерах всё равно оборачивают. Раньше, если меню не было списком, то верстальщик считался неучем и становился изгоем. Как теперь?Сергей, Вадим, вы оба меня не поняли. Я конечно понимаю что когда Вадим писал имя класса он думал о том что он как бы будет 'демонстратором', отсюда и shower, однако чаще всего это слово употребляют для обозначения дУша. Это меня и улыбнуло.
Сегрей-2, и всё же это вы меня недопоняли. Когда я писал «Shower», я прекрасно знал, что это «душ», но игра слов показалась мне настолько удачной, что я решил использовать этот каламбур как название, что отразилось на логотипе проекта.
Ок, может и так. Пишите ещё, хорошие темы затрагиваете :).
некоторые моменты стали более ясными.. :) спасибо, как всегда тебя интересно смотреть.
вот кстати во избежание путаницы,
К примеру у меня есть
headerвсей страницы иheaderпоста... вот тут получаются те же яйца что иdivс айдишниками.. поэтому у меня выходит где-то такой кодВадим, в вот к примеру есть такое меню:
http://clip2net.com/clip/m41816/1310561039-clipaq5591-3kb.png
В таком случае оно так же оборачивается в ???
2 Михаил Якименко,
в твоем случае скорее так:
По поводу:
Осмелюсь полагать что этот код не совсем корректен.
Если отталкиваться от статьи:
Dive Into HTML5: What Does It All Mean? (Оно же по-русски)
то имеет место быть следующий код
Т.е. в HTML5 каждый раздел может содержать собственный тег h1 - h6. nav - создает новый раздел, иными словами, новый узел в схеме документа.
В своё время заморачиавлся с написанием мануала по ЦМСке в чистом HTML. Конечно от сотни вложенных дивов уже мутило, так что семантика это, в принципе ок, даже с точки зрения стилевого оформления. Но вот у меня, для начала, такой вопрос.
Например, для чего нужен hgroup?
При структуре
Выходит некая путаница, или я что-то недопонял?
Ну и в догонку.
Может тогда вообще имеет смысл перейти полностью на абстрактный xml, с предопределённым набором элементов(классические ul, div etc)?
Ну и последнее: не вносит ли семантика ограничения на гибкость стилевого оформления?
Я имею в виду, что писать в классе "оранжевый", что элемент должен быть синим не ком иль фо, а семантика по сути, может к такому привести.
2 boba_KeyOST, насколько я понял, в hgroup элементы H1-H6 являются родственными в рамках этой группы.
То есть получается что все элементы Hn в рамках одного узла являются родственными.
boba_KeyOST и klierik, в общем предназначение у
<nav>только одно, объединение несколько заголовков в один с точки зрения структуры.Зачем это нужно? В html5 вся страница как бы делится на структурные блоки с помощью тегов
<article>,<section>,<nav>,<aside>. Заголовки служат названиями этих блоков, либо сами формируют блок, если этих тегов нет.Предположим у нас есть вот такой заголовок:
JavaScript: Книга с носорогом
Если его разделить вот так
то выделится два структурных блока, что нам не нужно, так как название это одно, но мы хотим показать, что Javascript — это основное название, а «Книга с носорогом», тесно связано с заголовком (поэтому подходит только заголовок). Тогда мы и объединяем два заголовка один, и с точки зрения оутлайнера — это один заголовок.
Кстати, из-за такого его малого и неявного назначения W3C (не WHATWG) этот тег выкинули месяца 2 или 3 назад, но потом вернули обратно.
Сергей, а вот если брать за основу реальную ситуацию:
целесообразно ли использовать в таком случае H1?
Что бы было наглядно о чём речь вот скриншоты:
закрытое меню
открытое меню
Сергей, ага, понял. То есть в моей ситуации hgroup формально не нужен, да и неправилен.
klierik, я может и не прав, но мне кажется h1 здесь не совсем правилен, так как, и тут со мной согласятся многие СЕОнисты, h1 должен быть как можно более один и раскрывать основное содержимое страницы. Да и мне кажется, что заголовок для выпадающего меню не логичен.
Ой, у меня там опечаточка досадная в предыдущем комментарии. Конечно же речь про
<hgroup>была.klierik, я вот не знаю стал бы использовать в подобном случае элемент
<nav>. Всё-таки он больше предназначен для выделения навигации. Хотя вроде бы это тоже допустимо.Зато вот вместо элемента
<ul>, я бы использовал<menu>, который пока ведёт себя точно также. С точки зрения html5 это как раз верно.На счёт заголовка. Если используется <nav>, то заголовок очень желателен. Правда я бы не стал использовать <h1>, наверное из-за привычки. Я привык использовать заголовки по степени значимости, поэтому здесь бы я использовал <h3>.
@klierik Ну а какая разница то собственно? )) Суть то не изменна, все равно получим суп из тэгов и классов..
Хорошо что хоть кто-то в конце доклада сказал что структурные теги практической пользы сейчас не имеют.
Теперь у нас есть БЭМ, и ориентированность на результат. И как же хорошо что прошли те времена массового психоза.
Exessqd, БЭМ решает совсем другие задачи и никакого отношения к веб-стандартам не имеет. По мне, так называть все классы
.b-elementи страшно от этого переться, абсолютно забивая на спецификацию и будущую совместимость — это как раз психоз.Нет, вы правда думаете, что элемент
b-grid__cell b-grid__cell_1-1(бэ-грид-адин-адин-адин) скажет верстальщику где находится блок, и что в нём содержится? Вы правда думаете, что слово разделитель в английском пишется так.b-devider?b-grid__cell b-grid__cell_1-1, что за изврат, в реальности не встречал такие конструкции, год уже бэм практикую и не делал такого.
это все какая-то попытка роботизации, возвращающей в эпоху ie6
Pepelsbey,
По мне, так называть все классы .b-element и страшно от этого переться, абсолютно забивая на спецификацию и будущую совместимость — это как раз психоз.
Будущее, никто не может знать каким оно будет...
Но в настоящем, есть два типа устройств которым могут понадобится dl,dt,ol,ul,li это поисковые роботы и альтернативные устройства.
1. Поисковикам - все равно.
2. Альтернативные устройства(речевые браузеры) не прочитывают списки с отключенными буллитами list-style:none; (пруф).
Я думаю это было сделано только благодоря тому что верстальщики использовали списки вне контента и я точно уверен что речевые браузеры в ближайшем будущем не перестанут игнорировать списки.
То есть, на текущий момент, абсолютно все равно что ты использовал для меню - ul>li или div>span, разница лишь в умах патриотов "семантической разметки" :)
Нет, вы правда думаете, что элемент b-grid__cell b-grid__cell_1-1 (бэ-грид-адин-адин-адин) скажет верстальщику где находится блок, и что в нём содержится?
В последней версии bem-method'a
вроде бы ничего не говорится о том что имя блока или имя элемента должно описывать что в нем содержится и где он находится.
Блоки:
Именно зачем нужен этот блок, но ни в коем случае не что в нем содержится и тем более где он находится.
Элементы:
Для элемента главное чтобы он находился в пределах этого блока, т.е. имя элемента b-grid__cell должно говорить что он относится к сетке b-grid.
Вы правда думаете, что слово разделитель в английском пишется так .b-devider?
Поправлено.
b-grid__cell b-grid__cell_1-1, что за изврат, в реальности не встречал такие конструкции, год уже бэм практикую и не делал такого.
Усердней надо практиковать =)
b-grid(блок)__cell(элемент)
b-grid(блок)__cell(элемент)_1-1(модификатор)
Помимо БЭМа, который пришёл и уйдёт, как только Яндекс в очередной раз поменяет стратегию, есть спека, её авторы и общие рекомендации по разделению содержимого и представления, которым десятки лет.
Давайте, используйте технологию, которая вся из себя хак. Префиксы появились потому, что пришлось поддерживать страшный код, который наверстала студия Лебедева, огромные классы появились потому, что IE6 не поддерживает множественные классы, а общий принцип независимости и библиотечности строится на том, что Яндекс — это портал с простым, лаконичным и повторяющимся дизайном.
Если ваш удел — слепо копировать, вперёд!
Этокакэто?! Вроде под 6-ку верстал, всё норм работало.
Кто-то должен расставить точки над i... позвольте, попробовать мне.
Это неправда. Устройствам вообще плевать на разметку. Разметка — то, что делает содержимое доступным или навеки вечные похороненным на задворках серверов. Разметка нужна только вам. Человеку.
Каждый раз, когда вы продолжаете так верстать умирает проект лучшего в мире поискового котёнка-робота. Вы уже определили для себя границы того, насколько можно отойти от «классических» норм разметки, которые не рассматривают проблемы «практического смысла»? В школах учат писать сначала по прописям, а потом уже постепенно позволяют сформировать свой почерк. Как вы думаете для чего это нужно если «практического смысла» прописи потом уже не имеют?
Помните историю с Вавилоном? Там все говорили и писали на разных языках. Есть желание забить общие правила, а преследовать личную сиюминутную цель? Подумайте еще раз о том будущем сети, о котором вы пишете «никто не может знать каким оно будет...».
Exessqd, Pepelsbey, мы все знаем, что «спека» — это не святой грааль. И десятки лет красят далеко не все спеки.
Pepelsbey скорее всего имел ввиду, что БЭМ имеет несколько родовых травм в реализации CSS-технологии, нанесенных суровыми внешними условиями, и, надеюсь, очень скоро их благополучно переживёт.
Сильно. Но не стоит забывать, что префиксы b- и огромные классы это дела одной технологии, относящиеся к реализации, появившейся в определенный период развития Яндекса.
Гораздо правильнее думать о БЭМ, как о методологии, а не о реализации в только в CSS. Обратите внимание хотя бы название репозитория, на который тут все ссылаются: BEM Method. На данный момент БЭМ в Яндексе уже задействован в JS, XSL и даже процессах сборки проектов.
Слепо копировать — плохо. Согласен. Фабрика по сжиганию велосипедов уже открыта на соседней улице, берегитесь ;)
Для IE6 селекторы
.one.twoи.twoдля элементаclass="one two"равносильны, что неправильно.pepelsbey, херасе. Вроде и не замечал до этого. Хорошо, что пациент скорее мёртв и уже попахивает.
Таки нет: не только поэтому, а для стремления к абсолютной независимости. При пересечении блоков, например, может захотеться применить определённый модификатор только к одному из блоков, но если бы он был сделан через множественный класс — этого не получилось бы.Аналогично и с элементами: иметь в имени класса имя блока необходимо. Это также не ограничение IE на селектор «>» т.к. если ты вместо длинных классов будешь писать, скажем,
То ты не сможешь потом между блоком и элементом вставить какой-то другой блок/элемент, или же и вовсе использовать элемент без блока (что, правда, противоречит официальной методологии, но не мог не упомянуть)И да — я верстал не только крупные проекты на БЭМ, но и несколько более мелких, и всегда, всегда когда я по каким-то причинам отходил от БЭМ и абсолютной независимости, всегда возникали какие-то проблемы когда было необходимо как-то расширить или дополнить код. Ну как проблемы: надо было просто часть переписать, часть скопипастить и что-то заменить, но всего этого можно было бы избежать не отходи я от БЭМ.Так что, если методология БЭМ, касающаяся сборки и прочего рокет-сайнса актуальна в первую очередь для больших проектов (в этом я согласен), то HTML/CSS часть БЭМ очень ускоряет написание кода. И если Zen-… ускоряет только сам процесс написания символов, то БЭМ ускоряет часть, связанную с архитектурой вёрстки, при правильном применении код будет ещё и легко читаемым, легко поддерживаемым и легко расширяемым. И это оправданно для проектов любого размера, от сайтов про котиков, до Яндекса.А уж какая там будет семантическая подкладка или её отсутствие — совершенно не важно. Не устану повторять, что семантика отдельно, БЭМ отдельно, никто не мешает из смешивать (и БЭМ так устроен, что ни-че-го в нём это делать не мешает).
Не вполне верно противопоставлять БЭМ метод семантической вёрстке. скорее это попытка дать людям разных сфер веб разработки один язык, в терминах которого они могли бы работать.
Кроме того более эффективно разделить обязанности.
Например инженерами Яндекса не раз повторялось, что один человек может оперировать блоками на уровне bemJSON или bemXML шаблонов не задумываясь об их внутренней реализации, а другой или другие осуществлять эту самую реализацию в той технологии которой владеют. Например верстать по всем правилам семантики и w3c спецификации.
pepelsbey,
Отделяем содержание документа от его представления
Я совсем не против этого принципа, здесь вопрос только в постановке задачи, например, если тебе нужно чтобы у тебя была жесткая структура и много представлений ты используешь одни методы; а если твоя цель максимальное быстродействие, легкость разработки и поддержки тогда лучше использовать другие, например, приемы модульной верстки(BEM, OOCSS, SMACSS).
Слава,
Я недостаточно подробно выразился, исправлюсь.
Но в настоящем, есть несколько групп людей которым могут понадобится dl,dt,ol,ul,li - это люди которые используют поисковые сервисы и люди которые не могут видеть, слышать, свободно обрабатывать или воспринимать те или иные виды информации.
Для этих людей на сегодняшний день существуют несколько типов устройств и программ, например, поисковые роботы и альтернативные устройства просмотра(речевые браузеры, принтеры Брайля, дисплеи Брайля).
Использование списков - это стандарт.
Следование стандарту может гарантировать что твой сайт будет совместим с текущими и будущими версиями браузеров т.е следовать стандарту нужно всегда, даже если это не несет явной выгоды(как использование списков).
Отойти от стандарта можно только если на это есть веская причина.
Не очень веская причина
На данный момент списки несут убытки, в виде:
1. Списковые блоки без частного ресета нельзя включать в области контента
2. Лишний код для частного/глобального ресета
3. С ресетом матчатся браузерные стили по-умолчанию
Мы не можем знать какие устройства/программы появятся и какая именно разметка им потребуется, но если возникнет необходимость(если это будет выгодно) то заточка сайта под лучшего в мире котёнка-робота будет реализована.
Прагматичный подход
У Яндекса очень прагматичный подход, он не оптимизировал разметку для незрячих до тех пор пока в этом не появилась необходимость, пока тех.поддержку не завалили письмами: "У вас не работает!".
Пока не заболит ты к доктору то не пойдешь.
Стандарты есть профилактика заболевания, следуя им мы с большей вероятностью избежим будущих проблем.
Вывод
Профилактика безусловно полезна, но в реальных условиях нужно придерживаться прагматичного подхода.
То есть ориентируемся на стандарты, но разрабатываем так как нам будет полезнее.
Сразу вспомнился Доклад Кудинова на РИТ-2010
Мы не можем знать какие программы появятся, но мы прекрасно знаем, с каким уже существующим кодом и на основании каких принципов и стандартов придётся работать этому котёнку.
Меня удивляет, что вы ратуете за прагматичный подход, но в упор не замечаете, что БЭМ полон архитектурной красоты и гибкости, которая в 90% случаев избыточна. Откуда 90%? Это те самые простые верстальщики, делающие простые сайты, редизайн которых убьёт не то, что весь клиент-сайд код, иногда даже сервер-сайд летит в корзину. Вы не используете независимость блоков, вы не вкладываете их друг в друга — но таскаете за собой хвосты избыточного кода, которые никогда не пригодятся. А потом жалуетесь, что reset.css — принципиально кешируемый, в отличие от документов — видите ли, лишний.
Вы ориентируетесь на стандарты, но плюёте на главный их принцип, разделяющий содержимое и представление — а именно в этом весь БЭМ, когда данные для JS хранятся прямо в HTML-коде в прагматичных onclick-ах, когда вы вводите тонны бессмысленных классов для бесполезно гибкой сетки.
Беспринципность кудиновских докладов и подходов давно уже стала нарицательной, опасные примеры приводите.
Ребят, а у меня такой вопрос.
Можно ли использовать в вёрстке БЭМ, но только отчасти, т.е. не уходить в него полностью, а юзать какие-то его отдельные части в некоторых местах.
Вот, например, как-то так:
http://forum.htmlbook.ru/index.php?showtopic=30108&view=findpost&p=229248
Вадим, а HTML — это не содержимое, это как раз часть представления :) Нельзя стремиться к тому, чтобы HTML и были данными, а CSS — представлением.
CSS — не всемогущий, он не может манипулировать структурой документа, он не умеет создавать врапперы и дополнительные элементы (двух псевдоэлементов — не достаточно), стремиться засунуть всё представление в CSS, конечно, интересно, но порождает ужасный перехаченный код, который невозможно поддерживать даже когда надо добавить второго котика на страницу, которую надо верстать 90% верстальщиков.
Я не говорю, что CSS всемогущий, но херить из-за этого его вполне адекватную и стабильную работоспособность, по сути, изобретая новый язык на костях старого, это удел тех людей и компаний, которым это по каким-то причинам очень нужно (либо крайне привычно, как тебе), а не массового верстальщика, у которого таких проблем нет.
Вадим, если я тебя правильно понял, то ты имеешь ввиду то, что не стоит гадить CSS, не используя его на полную мощь, в плане всяких селекторов типа “:nth-of-type(even)” и т.д, его красоту и возможности, на которые многие компании забивают в пользу железнобетонной вёрстки?
Ром, и следовательно тогда вопрос к тебе.
Ой, а БЭМ что-то херит? Расскажи :)
У массового верстальщика могут быть проблемы, но он может об этом не знать, так же как он может писать всегда HTML и CSS, набирая каждый символ вручную, и считать это нормальным.
Каскад херит. Любимый и вполне хорошо работающий с малых и средних уровнях сложности каскад и селекторы по элементам.
Напомню своё мнение: БЭМ — хорошо, это, в каком-то смысле, jQuery для больших контор, вроде Яндекса, т.е. технология, опережающая и изменяющая вектор развития веб-стандартов. Но хороша она для специфических задач, когда независимость, неограниченная вложенность и хранение логики прямо в коде для конструкторизации действительно нужны и используются.
Когда верстальщики просто хотят быть такими же крутыми, как папа, появляются всякие грид-матрёшки, где БЭМ ради БЭМа, а половина кода — это визуальная разметка прямо в документе.
Да, вполне, если понимать дл чего ты его используешь. В варианте с дочерними селекторами типа « .nav > li > a » — для небольших проектов прокатит. Но это всё-равно будет менее гибким, чем БЭМ. Представь: в какой-то момент тебе понадобится сделать в пункте меню не ссылку, а кнопку, или несколько ссылок, или что-то ещё. Но так, чтобы визуально они выглядели так же, как и простой пункт меню, или же были максимально близки к этому. Если изначально не смотреть на имена элементов, то класс можно будет подставить к любому тегу, иначе же придётся или дублировать код в селекторе, или же дублировать всё правило и т.д.
Да, можно использовать «упрощённый» БЭМ, но надо понимать, какие последствия будут возникать из-за всех упрощений. От них есть и профит, и вред, для каждого проекта надо будет решать не будет ли что-то жать. Поэтому мне, как и сказал Вадим, проще всегда использовать полную нотацию, так я в любой момент могу что-то добавить или изменить без больших изменений ни в HTML, ни в CSS.
Да так ему и надо!Бездумное использование селекторов по элементу и каскада ничуть не лучше использования звёздочки. И не с точки зрения производительности, а с того, что если тебе надо будет быстро поправить что-то в чужом коде или исправить ошибку, то это будет ад. Я бы сравнил использование селекторов по элементам и каскада с document.write , href="javascript:" и т.д. :)И да — никто не мешает использовать каскад там, где это нужно. Когда нужно стилизовать блок в контексте другого блока, определённые сочетания блоков и их пересечения — тут-то каскад и пригодится, для этого он и нужен.
Ты так говоришь, как будто это что-то плохое! «Прямо документ» — это не HTML. Это или XML, или какая-нибудь структура БД, markdown, или что-то ещё аналогичное. Как я уже выше писал, нельзя из HTML стремиться делать «документ», нужно конечный результат обогащать семантикой, добавлять aria и прочие ништяки.
Сейчас существует такое количество шаблонизаторов, абстракций и прочих ништяков, что задача «поменять класс» не отличается от «поменять стиль в CSS». Zen Garden был актуален в своё время и до сих пор он занятен как эксперимент над CSS. Но это не то, как надо писать CSS в реальной жизни! Там в самых няшных примерах — хак на хаке и хаком погоняет.
Ром, спасибо за ответ.
1) Но, смотри, если, например мне нужно будет заюзать кнопку вместо ссылки вот в такой ситуации:
То, я же могу сделать отдельный стиль для .nav > li > button, а если для конкретной кнопки, то вообще так: .nav > li > .button_size_20px {}?
2) И, я тебя понял, что нужно думать головой, а не попой, и прежде чем делать какой-то ход в стилях, точно знать, что ты делаешь.
Дело в том, что мне нравится БЭМ, но, с другой стороны, я, например, понимаю (или думаю, что понимаю), почему крупные компании, типа Яндекса пользуются этой методикой. Им это действительно выгодно, удобно и т.д.
Просто в обычных смертных проектах, которые, например, ты сверстал и возвращаешься к ним раз в году, не хочется заюзывать БЭМ полностью (хотя я ещё его и не познал нихрена), но хочется использовать его отдельные части, так как они вызывают у меня симпатию и сам подход меня очень радует, независимость, пуленепробиваемость и т.д.
Может быть, да, согласен, менее гибко, но, если, подходить с умом, то эта "негибкость" будет стоить лишь несколько дополнительных записей в коде, типа таких .nav > li > .button_size_20px {}, при том, что в целом это будет такое же пуленепробиваемое существо)
Как ты считаешь, бред или нет?
ZG значительно опережал своё время (помнишь запасные элементы в конце шаблона?) и очень сильно повлиял на западную вёрстку и в меньшей мере на рунет. Боюсь, что здесь, как уже бывало у древних, должно пройти 40 лет, прежде чем вымрут те верстальщики, которые помнят про то, что колонки у таблицы местами не переставить, что они вообще нужны, а IE6(7-8) не понимает весь самый крутой CSS.
Ты же понимаешь, что шаблонизаторы и абстракции взялись не просто так, не потому, что они классные и удобные, а потому, что браузеры развивались так, как они развивались — не всегда хорошо и достаточно быстро.
В общем, я знаю все «за» и «против», все нюансы и доводы. БЭМ и хорошо, и плохо, не в этом дело. Дело в том, что когда принципы верстальщика основаны хоть и на крутой, но всё же местечковой и узкоспециализированной разработке Яндекса, сугубо практической и не застрахованной от глобальных изменений завтра — это плохо. Принципы, выливающиеся в собственную практическую реализацию, не могут быть приземлены до желания быстрее закончить проект, забыть о нём и пойти рубиться в кваку. Принцип разделения представления от содержимого говорит о настоящей гибкости, а не подхаченой при помощи консольных хелперов и скриптов.
А человек без принципов — это не человек, это вчерашнее фруктовое желе.
Меняется максимум нотация, да технология обрастает всякими новыми тузлами и библиотеками. Но не суть.
БЭМ с точки зрения HTML&CSS не менялся с доклада Харисова на январском субботнике в 2009, когда это ещё были АНБ. Менялась только нотация, но на принцип это не влияет, это-то как раз влияет только на разработчиков Яндекса :) А то, в какой нотации было написано что-то в стороне — не важно. Важно, чтобы принципы соблюдались.
Ты как-то странно передёргиваешь и набрасываешь на БЭМ, говоря всего лишь о людях, неверно его применяющих. Так вот каскад-то люди правильно применяют не чаще, спецификации никто не читает. Это — проблема, необразованность — проблема.
Давайте агитировать за здравый смысл, внимательное отношение к коду, а не против каких-то технологий. Когда ты пишешь твиты про БЭМ как-то так получается, что они выглядят как наброс на БЭМ, а не на людей, которые его не так понимают :) И если ты видишь путь как сделать так, чтобы БЭМ понимали правильно: пулл-реквесты у БЭМ-метода приветствуются, вперёд.
А так мы переливаем из пустого в порожнее, ну правда же.
Всё правильно, помимо того, что может быть ещё с десяток случаев, когда придётся что-то дописывать в селектор, дублировать код и т.д. Мне нравится всё контролировать и проектировать интерфейс заранее так, чтобы любые изменения можно было потом максимально легко применять, а также, чтобы уже написанный код можно было легко адаптировать к любому другому проекту. Скажем, часто может захотеться отделить стили отдельного пункта меню от всего меню целиком, тогда пункт меню станет блоком, а не элементом, например. И т.д.
Ром, и прочитай пожалуйста вот этом мой пост. Это чтобы ты не подумал, что я совсем тупица и что я "селекторный" человек:)
http://forum.htmlbook.ru/index.php?showtopic=30108&st=0&p=229248&#entry229248
Я приводил пример с .nav > li , потому что это в принципе неотделимо, т.е. не бывает меню без li внутри, но эта цепочка максимальная. И, если, например, внутри будет другой блок, то его цепочка будет начинаться уже от него или вообще уже не будет никакой цепочки, а будет просто обращение к единственному классу: .button_size_20px {}
Т.е., по сути, каждый отдельный блок уже будет независимым, как и в БЭМ-е, но просто жертва хомяковской независимости (которая всё таки отличается от БЭМовской, даже если и продумана), опять же, будет лишь несколько дополнительных правил CSS.
Вот, кстати, простой пример.
Мне заказали вёрстку, допустим 10-и страниц. В макете есть навигация, в шапке. Она состоит из ul - li - a, это связка будет вечной, ну или, зайдя через год, максимум, что я увижу, это повешанный дополнительный класс в пункте.
Вот из-за таких вот вещей и возникают вопросы: "А нахрена вообще тут БЭМ?".
Но, всё же, понимая, что бездумно верстать - это по меньшей мере глупо, я пришёл к выводу, что в таких вот ситуациях и подойдёт "мой" мини-бэм, к которому я пришёл:)
Упс, не ту ссылку дал, Ром. Ссори.
http://forum.htmlbook.ru/index.php?showtopic=30108&view=findpost&p=229306
Да, ты там правильные аргументы приводишь, всё ок.
Но! А если вдруг где-то будет элемент, так же выглядящий, но с одним единственным пунктом? Это же уже не список. А если вдруг меню так поменяют, что будет больше подходить dl>dt+dd? Или одним из пунктов будет кнопка загрузки файла (ой, я же об этом уже говорил), или неактивный пункт захочется сделать не с помощью
<a>, а тем же<strong>, и т.д., и т.п.Половина из этого происходило со мной на реальных небольших десятистраничных сайтах :)
А-а-а, тут же не маркдаун и нет предпросмотра, Вадим! Поправь это уже! )
Рома, в новой версии сайта будет лучше, а пока надеюсь на вашу сознательность ;)
Ром
Ну вообще всё же dl>dt+dd отличается от ul>li, это раз, а два - это то, что, если ты заметил, я пляшу не от ul, а от .nav, т.е. принципиально от класса, а не от элемента (своего рода, маленькая перестраховка), поэтому, если даже и поменяется, то тогда у dl будет стоять класс .nav, от которого я и пляшу. Соотсветственно в секции с навигацией я просто допишу дополнительные стили .nav>dt {}. Если же одним из пунктов будет кнопка, то она снова получает, свой Отдельный класс и уже стилизуется, чисто по по нему, отдельно. Точно так же касается и активного пункта и прочего...
Т.е, я понимаю, что ты имеешь ввиду, но всё, что ты противопоставляешь, при правильном использовании мини-бэма, по идее должно присекаться с наименьшими потерями :)
Максим, то, что вы называете «мини-БЭМом» на самом деле обычная взрослая вёрстка, даже не АНБ, и никакие двойные подчёркивания в ней не нужны.
Вадим, было бы здорово на "Ты" :)
Немного не соглашусь всё таки. Сейчас постараюсь донести свою мысль более развёрнуто.
Сама фраза "мини-БЭМ" была придумана мною совсем недавно, и только лишь ради того, чтобы хоть как-то уточнить то, чего я хочу получить. А именно взять из БЭМ-а только ту часть, которая меня в нём зацепила. Это независимость. Меня привлекла сама идея... идея АНБ, что, кстати, до появления её в Яндексе, заставляло смотреть на вёрстку совсем иными глазами. Всё таки, надо признать, Рома был прав, когда где-то сказал, что фраза "Независимый блок" пришла с появлением БЭМ-а, ну по крайней мере, как минимум получила широкую огласку и стала известной. Меня лично это заставило переосмыслить многие вещи.
В то же время, я соглашусь с тобой, что моя, как ты выразился, "Взрослая вёрстка" (хотя я считаю её детской) - не является никаким мини-БЭМ-ом и уж тем-более ни о каком АНБ в ней и речи идти не может.
Но, тем не менее, я бы хотел вытащить из БЭМ-а идею независимых блоков, и по максимуму (в пределах планки для хомяков) использовать её в своих (простых смертных) проектах. Соответственно, понятное дело, что полной АНБ добиться не получится, да и мне этого не нужно, так как я считаю (возможно ошибаюсь), что БЭМ на обычных хомяках - это слишком, и что использовать его по максимуму можно и даже нужно, только на крупных проектах. И это касается не только Яндекса, да и других, более мелких, но всё же крупненьких :)
Моя цель - это повысить качество своей работы, путём максимального, но при этом разумного, использования АНБ, даже наверное НБ, потому что "Абсолютная" мне попросту не нужна, по факту.
Так как я ещё молод в этом деле и метаюсь в поисках истины, то хочу понять для себя, стоит ли мне повышать планку и использовать БЭМ на полную катушку или остаться на уровне своей "взрослой" вёрстки и этого вполне хватит для её пуленепробиваемости на обычных хомяках.
Тот же Рома, использует БЭМ в любых своих проектах, как в маленьких сайтах, так и в крупных. Я же привык думать своей (дурной) головой, а она всё никак не может определиться и понять, как же на самом деле правильно и железно? Вроде, с одной стороны я понимаю, что люди с большим опытом говорят, что БЭМ - это здорово, но с другой стороны... ну вот никак не могу я это принять и понять. Мне кажется, что, возможно, это и принесёт свои плоды, но, есть сомнения, не окажутся ли они бесполезными, лишним грузом в разметке, грязью и прочим хламом, который будет пылиться на полке, как старые книжки?
БЭМ — хорошо, но это не то к чему я привык!
Главное что "Любимый". Родину не выбирают, если стараться отобрать у человека то к чему он привык он всеми силами будет сопротивляться.
Синдром утёнка, есть такое понятие.
А как можно сопротивляться? Например, постарается найти изъяны:
Избыточный код
Да верстка в терминах БЭМ требует строго соблюдать принципы именования классов и поэтому БЭМ классы получаются достаточно длинными.
Классы становятся длиннее а размер кода проекта становится меньше - БЭМ парадокс :)
Излишний консерватизм
БЭМ отталкивает тем что он непривычен, в особенности людям которые начинали с постулатов о "семантической разметке" и "разделения содержания от представления".
"И это теперь правильно?" - немой вопрос патриотов "семантической разметки".
Не отказывайтесь от технологии просто потому что она вам не нравится или вам непривычна, сначала стоит хотя бы попробовать.
P.S. тонны
бессмысленныхосмысленных классов длябесполезнополезно гибкой сетки.Речь не о том, что классы длинные — вы привычно сползаете на любимую тему — речь о том, что делать БЭМ ради БЭМа глупо. Если вам не приходится часто менять местами элементы и даже вкладывать их в необычных сочетаниях, если вы не пользуетесь своей вёрсткой как многократно используемой библиотекой, то БЭМ это трата времени впустую.
Я внимательно слежу за развитием вёрстки в Яндексе, работал там, в том числе, и с первыми версиями АНБ из которых потом сформулировали БЭМ. И радовался, когда работал — там они были нужны.
Теперь про ваше «бунтарство», мол семантика и каскад говно. Прочитайте мой комментарий про принципы — базовый и местечковый. И подумайте, если ещё помните как это делается.
Сказано достаточно и, во избежание назревающего хамства, комментарии закрыты.