Есть ли какие-то специальные рекомендации в методологии БЭМ при верстке HTML5?
Лично мне очень помогла история создания БЭМ. Из этой статьи я вынес несколько интересных идей для собственных проектов, и отложил БЭМ до того момента, когда начну реализовывать свой очередной план по захвату галактики ;)
Зайки кушают морковку, волки кушают овес, и все бы замечательно было бы в лесу, если бы не контекст.
- HTML5 не идеальная штука, верстать в четком соответствии с его стандартнами — равно смертный приговор внешнему виду проекта. Это достаточно сырой продукт, который производители браузеров решили кусочно выложить в свет. Что из этого получится — будет известно через пару лет, когда все грабли познают своего на них наступившего.
- Количество проблем с кодом будет увеличиваться линейно или даже квадратически, в зависимости от ваших навыков. В любом случае, вы никогда не уйдете от классов и элементов. И скоро работы ваших сайтов при описанном подходе (поиск по тегам, поиск по data-атрибутам, смешанные селекторы и пр.) будет влиять как на первичную отрисовку страницы, так и на все последующие перерисовки достаточно сильно просто потому, что оптимизация, конечно, есть, но от полного перебора дом дерева при его перестройке никто не уйдет.
Я, как и некоторые, уже давно не считаю html и css чем-то, что стоит писать руками. Если в js можно просто забыть и не использовать неудачный опыт типа with, отстуствия разделителей (;) при переносе строк, и т.п., это все-таки императивная среда, то с декларативной природой css и html — можно абстрагируясь писать языки разметки, вычленять кусочки из целого и реиспользовать много раз где нужно, и прочее.
Вам HTML5 говорит о том, что хорошо бы вычленить все описание section в отдельное место, всякие стили, скрипты, и прочее?
Да и ваш подход, с тэг = блок, не приживется. Подойдет только для очень мелких сайтов. Просто потому, что у вас тэги кончатся. Попробуйте заверстать страничку пользуясь своим руководством, и все поймете. Я уже не упоминаю про семантику.Если применять БЭМ в чистом виде к HTML5 получиться избыточное количество классов, которые добавляют "независимость блокам" так где она есть или не нужна.
Лучше иметь класс .blockquote, чем зависеть от тега blockquote, который в каких местах может не быть блоком .blockquote, а просто элементом другого блока с совершенно другим видом типа blockquote.comment__quote, каким могла бы эта безымянная цитата конкретно в этом комментарии.
Отвечая на вопрос, рекомендации все те же: не использовать каскады, разделять интерфейс на блоки, писать элементам внутри блоков и модификаторам полные названия, чтобы было понятно чей он и оно не сломалось в один прекрасный день где-то, группировать шаблоны, стили и скрипты блоков на файловой структуре по своим папкам, понять и использовать примешивания там, где нужно связать блоки/элементы, и т.д, и т.п.
Порог входа не низок, не высок, но есть. Все кто против — либо любят наступать на грабли, либо ничего долгосрочного не делали, либо фанаты w3c (а не здравого смысла), либо ваш вариант.