Open FMRobot opened 10 years ago
@RamallahS знаешь, я — тоже :) Хотя бы на английском, для начала.
Очень не хватало такой статьи =)
Интересная статья =) Мне вообще интересна тема семантической разметки.
Авторам настоятельно рекомендуется рассматривать элемент div как элемент на крайний случай, когда никакой другой элемент не подходит.
Мне кажется, что этот «совет» из спецификации опускает значимость тега div
ниже плинтуса и ведёт к тому, что неопытные разработчики будут придумывать семантический смысл где его нет.
Смотрите что происходит с тегами section
и article
на типовом сайте — они лепятся вообще от балды и, чаще всего, служат для группировки контента. Считаю, что отсутствие хоть какого-то заголовка h1-h6
у такого блока является индикактором неправильного использования структурного элемента. Хоть в спецификации наличие заголовка и носит рекомендательный характер, но по факту становится своего рода «Best practice». Будьте уверены, если структурный элемент сопровождается заголовком, то он применён к месту. А вот если заголовка нет, то — не факт.
Ещё раз. Не нужно путать структурные элементы (например, section
и article
) и группирующие элементы (например, div
и main
) между собой.
Так же отсутствие контента при наличии структурного элемента с заголовком является грубой ошибкой. Я видал много примеров типа:
<section>
<h1>Page header</h1>
<h2>Sub header</h2>
</section>
Очевидно же, что это никакой не раздел документа, а несколько объединённых между собой заголовков — нужен <div>
!
Мой совет — не ищите чёрную кошку в тёмной комнате, особенно если её там нет.
А потом приходят сеошники и говорят, что в этом месте нам не надо использовать <h1>
и он должен использоваться только один раз на странице. И <h1>
превращается в <div class="title">
. А <h2>
можно использовать только в приделах статьи и он превращается во что-то типо <div class="subtitle">
. А <h3>
вообще надо удалить. А вот этот дополнительный <article>
давай удалим, потому-что не понятно как его Яндекс распарсит...
Все очень сыро, и теория(спецификация) опять идет вразрез с практикой. Впрочем, как и всегда.
Считаю, что отсутствие хоть какого-то заголовка h1-h6 у такого блока является индикактором неправильного использования структурного элемента.
article представляет независимый самостоятельный блок. Там не то что заголовка, там даже текста может не быть. Почему ты пришел к таким странным выводам?
div действительно стоит применять тогда, когда нет более подходящего элемента6 но это не значит «пихать куда не надо section».
<section>
<h1>Page header</h1>
<h2>Sub header</h2>
</section>
Вообще тут нужен почивший в бозе hgroup а сейчас пожалуй header
Так все структурные элементы про контент. Представь себе заголовок (а он тоже является структурным элементом) без контента. Странно, не правда ли? В спецификации нет запрета на отсутствие контента. Зато есть такое:
A general rule is that the article element is appropriate only if the element's contents would be listed explicitly in the document's outline.
«Основное правило таково, что элемент article можно использовать, только если контент элемента может быть явно отображен в плане документа»
У меня простая логика: нет контента — нет <article>
. @SilentImp, расскажи почему ты думаешь, что отсутствие контента в таких ситуациях — это норма. Зачем нужна пустая статья?
<article style="background-image: url(image.jpg); background-size: cover"
title="Картинка с изображением продукта и рекламным слоганом"></article>
А такая статья имеет право на жизнь?
Авторам настоятельно рекомендуется рассматривать элемент div как элемент на крайний случай, когда никакой другой элемент не подходит.
Изначально я процитировал фразу, которую можно легко начать трактовать как: «Используйте что угодно кроме div». Но это совсем не так. Спецификация адаптирована под алгоритм: «если — то, иначе если — то… (и так много раз) иначе <div>
». В повседневной жизни человек так не мыслит. Крайний случай — это что-то экстраординарное. В веб разработке мы в 99,999% ситуациях имеем сдело с описываемый «крайним случаем». Поэтому формулировка сбивает с толку и подталкивает делать глупости.
Зачем вообще "семантическая" верстка?
Заботиться об ограниченных пользователях - дело, конечно, хорошее, только никто ведь искренне не верит в это.
Или об ограниченных устройствах. Чтобы они из-за того, что не могут отобразить контент, как задумывалось, показывали хотя бы как-то, чтобы человек мог нормально интерпретировать. Только на практике таких устройств просто нету - о попытке "распарсить интернет" можно только мечтать, а семантическая верстка никак не приближает к этому чудесному, открытому связанному интернету. Хотя вообще-то для этого существует на самом деле понятие "открытое API", которое как раз предназначено для получения "чистых данных".
Семантика и метаданные - есть различные специализированные на этом средства, вроде RDF и прочие.
Использовать меньше классов? Зачем? Если, например, писать на Jade, то размер вовсе не меняется, а итоговый HTML будет отличаться незначительно. К тому же, не понятно, как определять нормальные селекторы, если известные методики стилизации (BEM, SMACSS и в особенности OOCSS) в самом своем фундаменте загромождают классы - факт, конечно, грустный, но иначе никак не получается. Нельзя просто взять, и не думать о стилях при написании HTML. Еще, кстати, в этих методиках не рекомендуют использовать селекторы с названием элементов - и понятно, почему, сам до этого дошел быстро.
Разумным выглядит попытка семантической версткой помочь поисковым машинам лучше интерпретировать контент. Но если это действительно значительно влияет на поисковую выдачу - это нужно изучать отдельно, и пусть тогда этим занимаются SEO-специалисты, и пусть они лезут в верстку и меняют вездесущие div'ы на article.
HTML нужен браузеру, а не пользователю. Браузеру же не важно, что содержится на страничке, главное - отобразить корректно.
Надо будет почитать что там нового в этом HTML5, а то от жизни отстал ))
@iofjuupasli, с языка снял. Я вижу в семантической вёрстке только одно практическое преимущество — облегчение поддержки. Если html семантичный, то беглым взглядом можно понять, что декларируется в коде, а как теоретический концепт она прекрасна.
Такую же пользу, в частности, несёт программирование в функциональном стиле (а ля Haskell), на мой взгляд — сразу понятно что примерно происходит.
@SilentImp, hgroup снова начинают активно использовать, я например всегда все заголовки в
При просмотре схемы документа просматривается логика документа.
Ребят, очень ждем продолжения статьи. Нужна часть 2. Готов проявить инициативу и помочь со сбором информации, если требуется, на общественных началах.
Спасибо! Очень буду ждать продолжения!!!