id для js — плохая практика. Лучше воспользоваться классами (с префиксом, на которые не накладываем стили), либо data аттрибутами
Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
1) Чем сложнее сайт, тем сложнее разобраться с такими стилями
2) Неоднородное поведение элементов. Иногда можно столкнуться со следующими идеями интерфейса — на страницах с какой-то объемной информацией header может «спускаться» за пользователем (быть фиксированным) на других страницах этого не надо (да, вырвиглазно, но присутствует)
3) «Шаблонность» (по отношению к header\body\footer) это проверенная годами возможность предоставить пользователю удобное понимание сайта. Было б непривычно, если бы каждый из сайтов был построен «как душеньке захотелось»
Если разобрать Вашу идею можно найти множество проблем данного кода (начиная от пометки выбранного пункта меню и т.д.)
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
Если Вы приходите в компанию, где работают без БЭМ и их продуктом является таки веб-сервис, то у них почти всегда есть концепция построения проекта. Иначе держать всю структуру просто-таки невозможно.
Я его выделил как элемент внутри блока. Сам по себе он может быть также блоком.
Яркий пример — верстка меню — есть блок меню, который включает элементы — пункты меню, которые включают в себя блок — ссылка
Для сайтов, которых цель — бложик или статика, либо форумы (подобное им) БЭМ не нужен.(читать как не является нужным) Так как такие сайты создаются один раз и следующий раз изменятся только при редизайне.
Я думаю, что стоит. Яндекс (могу ошибаться) никогда кардинально не менял всю верстку. Используется как старая, так и новая. (по мере наработки — спасибо независимым блокам)
Далее, такие сайты как lenta.ru — постоянно дорабатывают сайт -> без независимости постоянно бы вставал вопрос о «переписки»
hh.ru -использует БЭМ + XSLT — аналогично использование наработок позволяет использовать заново блоки -> сокращается время разработки.
Инструменты для БЭМ были разработаны много позже методологии.
БЭМ предлагает правила именования. В этом его прелесть — разработчикам не нужно «искать то какой принцип исопльзовал предыдущий разработчик при именовании»
Вы сейчас говорите о шаблонизаторах. Однако БЭМ это не шаблонизатор. Это методология написания html\css кода.
Это такая же методология, как, например, SMACSS или OOCSS (весьма популярные технологии разработки html\css кода)
Многие компании используют XSLT шаблонизатор + БЭМ методологию.
БЭМ описывает то, как организовывать структуру HTML кода, чтобы добиться ее переносимости и плавного расширения.
В проектах без БЭМ (а если быть более точным — без методологии разработки), зачастую случается следующего рода проблема — создан сайт. Затем появляется необходимость поправить расположение блока меню, блок регистрации поменять местами с лого. Используя БЭМ вы отлично знаете, что, чтобы поменять местами достаточно сменить стили у элементов блока хедер (если говорить о примере в статье) Если необходимо сменить цвет — Вам не надо лезть в код и менять что-то там. Достаточно лишь добавить нужный модификатор. Код становится гибким.
Отказ от наследования…
В статье писал, что может случиться, если Вы в блок добавите вложенный элемент с тем же названием, что и для тех, кои были раньше. БЭМ это учитывает, а в проекте построенном на каскаде может потребоваться переписать код (пример есть в статье)
Вы опять идете на каскад. Идея, сама СУТЬ БЭМа — уйти от каскада. Этот код переписывается и Вы освобождаетесь от каскада.
В БЭМ вы переплачиваете за размер «букоф», выигрывая на этапе отрисовки веб-страниц: использование классов БЕЗ каскада позволяет браузерам быстрее применять стили -> пользователь быстрее получает запрашиваемую страницу.
Вы создаете inline стиль, который имеют самую высокую специфичность.
Вы не можете повторно использовать данный код. Возьмите большие сайты, которые развиваются постоянно.
Можно «поколдовать» еще со специализациями =)
Разве что будет примесь С\С++ разработчиков
id для js — плохая практика. Лучше воспользоваться классами (с префиксом, на которые не накладываем стили), либо data аттрибутами
Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
1) Чем сложнее сайт, тем сложнее разобраться с такими стилями
2) Неоднородное поведение элементов. Иногда можно столкнуться со следующими идеями интерфейса — на страницах с какой-то объемной информацией header может «спускаться» за пользователем (быть фиксированным) на других страницах этого не надо (да, вырвиглазно, но присутствует)
3) «Шаблонность» (по отношению к header\body\footer) это проверенная годами возможность предоставить пользователю удобное понимание сайта. Было б непривычно, если бы каждый из сайтов был построен «как душеньке захотелось»
Если разобрать Вашу идею можно найти множество проблем данного кода (начиная от пометки выбранного пункта меню и т.д.)
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
О данном (не знаю, как точно определить..) ходе не предполагал.
Яркий пример — верстка меню — есть блок меню, который включает элементы — пункты меню, которые включают в себя блок — ссылка
Единственная вещь, которую можно записать в «стоит» — это следование единому стилю оформлению
Далее, такие сайты как lenta.ru — постоянно дорабатывают сайт -> без независимости постоянно бы вставал вопрос о «переписки»
hh.ru -использует БЭМ + XSLT — аналогично использование наработок позволяет использовать заново блоки -> сокращается время разработки.
БЭМ предлагает правила именования. В этом его прелесть — разработчикам не нужно «искать то какой принцип исопльзовал предыдущий разработчик при именовании»
Я думаю, Вам будет очень интересна дискуссия в статье здесь — marow.net/archives/161
Для данного треда вынесу цитату:
«Каждый их разработчиков, рано или поздно приходит к чему-то подобному БЭМу»
Возвращаясь к каскадированию — вы вправе использовать его внутри одного блока, например. Все зависит от принятых соглашений для проекта
Также добавлю, если посмотреть на SMACSS — он очень похож на БЭМ.
БЭМ == Независимые блоки.
Изначальное название БЭМ: Верстка на независимых блоках (точное название не припомню, но суть эта)
Это такая же методология, как, например, SMACSS или OOCSS (весьма популярные технологии разработки html\css кода)
Многие компании используют XSLT шаблонизатор + БЭМ методологию.
БЭМ описывает то, как организовывать структуру HTML кода, чтобы добиться ее переносимости и плавного расширения.
В проектах без БЭМ (а если быть более точным — без методологии разработки), зачастую случается следующего рода проблема — создан сайт. Затем появляется необходимость поправить расположение блока меню, блок регистрации поменять местами с лого. Используя БЭМ вы отлично знаете, что, чтобы поменять местами достаточно сменить стили у элементов блока хедер (если говорить о примере в статье) Если необходимо сменить цвет — Вам не надо лезть в код и менять что-то там. Достаточно лишь добавить нужный модификатор. Код становится гибким.
Отказ от наследования…
В статье писал, что может случиться, если Вы в блок добавите вложенный элемент с тем же названием, что и для тех, кои были раньше. БЭМ это учитывает, а в проекте построенном на каскаде может потребоваться переписать код (пример есть в статье)
В БЭМ вы переплачиваете за размер «букоф», выигрывая на этапе отрисовки веб-страниц: использование классов БЕЗ каскада позволяет браузерам быстрее применять стили -> пользователь быстрее получает запрашиваемую страницу.
Затем, как подчеркивал в статье — БЭМ используется для сайтов, которые имеют >20-30 уникальных страниц. Когда блоки могут повторяться и т.п.
Именно для таких вещей и был разработан БЭМ, чтобы вместо этого ада —
Было:
Вы создаете inline стиль, который имеют самую высокую специфичность.
Вы не можете повторно использовать данный код. Возьмите большие сайты, которые развиваются постоянно.