Является ли семантическая разметка слишком открытой?

Я заглядываю в Погружение в HTML5. Это кажется приятным и интересным, но я озадачен.

В 1990-х годах, когда Netscape был браузером, а HTML - HTML2 или HTML3, было много тегов: адрес, цитировать, код... Большинство из них не используются на сегодняшний день, возможно, даже устарели.

HTML5 вводит теги, чтобы выразить "семантическое значение" самому тегу. Это все забава и игры, но я вижу что-то очень странное в этом подходе. Технически семантика может быть очень открытой. HTML5 имеет теги для статьи, времени, навигационных баров, нижнего колонтитула. Почему он не должен содержать теги для значков сообщений, места автора, имени и фамилии или того, что еще нужно назначить для определенной семантики (я уверен, что <rant> и <nsfw> будут очень важными тегами):? Я думал, что XML - это стратегия назначения семантики материалам. Ничто не запрещает вам помещать фрагмент XML в элемент XHTML и назначать ему таблицу стилей, чтобы правильно его подобрать или делегировать правильному зрителю обработку этого пространства имен (например, при обработке RSS или SVG).

В заключение я не понимаю причины этих расширений, ориентированных на семантику, когда ясно, что семантика - очень широкая тема, которая гарантированно требует потенциально бесконечного количества семантических тегов. Поскольку я уверен, что есть умные люди в W3C, я думаю, что я ошибаюсь, но я хотел бы знать, почему.

Ответ 1

Почему метки для статьи, времени, навигационных баров, нижнего колонтитула полезны?

Потому что они облегчают разбор для инструментов обработки текста, таких как Google.

Ничего о семантике (по крайней мере, в "широком" смысле). Вместо этого они просто говорят: вот текст страницы (самая важная текстовая часть), и есть панель навигации, полная ссылок. При таком подходе вы можете легко извлечь только то, что вам нужно.

Ответ 2

Я слишком ненавижу то, как W3C идет со своими спецификациями. Есть много вещей, которые мне не нравятся, и эта "семантика" - одна из них. (Другие включают в себя принятие навсегда для завершения своих спецификаций и оставляя слишком много важных деталей для браузеров для реализации по своему усмотрению)

Больше всего мне это не нравится, потому что это затрудняет мою работу в качестве веб-разработчика. Мне часто приходится выбирать, делать ли веб-страницу "семантически корректной" или "визуально/эстетически приятной". Последнее, конечно, побеждает, потому что это то, чего хотят пользователи, но в результате проверки начинают сбой, и все это становится совершенно не семантическим (таблицы для макета и другие вещи).

Еще одна проблема, на которой я хмурится, заключается в том, что они официально объявили, что атрибут "class" предназначен для семантики, но затем они использовали его для визуальных селекторов представлений в CSS.

Нижняя строка - НЕ СМЕШАНЬ СЕМАНТИКУ И ВИЗУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ. Если вы используете какой-либо механизм для описания семантики (например, имена тегов, значения атрибутов или что-то еще не), тогда не используйте их для функциональных/визуальных целей и наоборот.

Если бы я создал HTML, я бы просто добавил атрибут "семантический", который мог бы (например, атрибут "class" ) быть добавлен в любой тег. Тогда будет множество предопределенных значений, таких как все те заголовки/нижние колонтитулы/статьи/кавычки и т.д.

Тэги определяли бы функциональность. В основном вы можете уменьшить HTML-теги только до нескольких, например, "div", "table/tr/td", "a", "img", "form", "input" и "select". Я, вероятно, пропустил несколько, но это большая часть. Визуальный стиль будет выполнен с помощью CSS.

Таким образом, три области - семантика, визуальное представление и функциональность - будут полностью независимыми и не будут сталкиваться с реальными решениями.

Конечно, я не думаю, что W3C интересуется практическими решениями...

Ответ 3

Уже существует много семантики в разметке HTML в формах классов и идентификаторов, из которых существует (почти) бесконечное количество возможностей, и каждый имеет свой собственный способ обработки этой семантики. Одной из целей HTML5 является попытка привнести некоторую структуру в это. вы все равно сможете расширить семантику тегов с помощью классов и идентификаторов. Это также, скорее всего, упростит работу поисковых систем.

Ответ 4

Посмотрите на это с точки зрения попыток сделать заявления либо о странице, либо о объектах, на которые ссылается страница. Если вы видите тег <footer> , все, что вы можете сказать, это "материал здесь, это нижний колонтитул" и передать его. Таким образом, добавление пользовательских тегов не является таким общим решением, как добавление атрибутов и позволяющее людям использовать свой собственный выбор URI для указания предикатов и необязательных значений - RDFa выигрывает раздачу, потому что вы можете выразить любую тройку -statement вам нравится из RDF на странице, так или иначе.

Ответ 5

Я просто хочу рассмотреть одну часть вашего вопроса. Вы говорите:

В девяностые годы, когда Netscape был браузером, а html был HTML2 или HTML3, было много теги: адрес, цитата, код... Большая часть они не используются на сегодняшний день, вероятно даже устаревшие.

В html есть множество тегов, но отсутствие использования не означает, что они устарели. В частности, теги заголовков <h1> и т.д. И <ul>, <ol> используются для объединения элементов в списки так, как я считаю семантическими. Многие люди могут не использовать теги семантически, но усилия по созданию микроформатов являются продолжением идеи, которую вы считаете артефактом 1990-х годов. Усилия, чтобы сделать семантический веб, будет победителем, несмотря на то, что полнотекстовый поиск и анализ ссылок (в форме Google) являются победителями как найти и понять Интернет.

Было бы здорово увидеть обновленную версию Google Web Stats, которая показывает "html, поскольку она говорит". Но вы правы, что многие теги недоиспользуются.

Будет ли html5 успешным - это открытый и интересный вопрос, но теги, которые вы описываете как устаревшие, никуда не денутся, они были там в HTML 4.01 и xhtml. HTML5 кажется попыткой упрочить то, что полезно в тегах. В конце концов, если html5 получит поддержку в браузерах и упростит работу веб-разработчиков, это сработает. xhtml2 не удалось, потому что он не смог получить одобрение в браузерах и ничего не сделал, чтобы облегчить работу разработчиков веб-страниц. Силы, работающие над html5, по-видимому, прекрасно знают об отказе xhtml2, и я думаю, что избегают того, чтобы html5 страдал от подобной участи.

Ответ 6

"Почему он не должен содержать теги для значков сообщений, имени автора, имени и фамилии или любого другого, что вы хотите присвоить определенной семантике (я уверен, и это были бы очень важные теги):?"

Вы используете <dialog> для описания разговоров или комментариев. Rant и NSFW являются субъективными терминами, поэтому имеет смысл не использовать их.

Из того, что я понимаю, группа опытных веб-разработчиков провела исследование и посмотрела, что у большинства сайтов есть в html. Они заметили, что большинство websitse имеют id = "header", id = "footer", id = "section" и id = "nav", поэтому они решили, что нам нужны теги HTML для замены этих идентификаторов. Другими словами, не ожидайте, что они дадут вам ОГРОМНОЕ количество словарей HTML. Просто держите его как можно более простым, как вы можете, обращаясь к общим общим HTML-тегам MOST.

NAV tag ОЧЕНЬ важно для обеспечения доступности. Вы хотите, чтобы они знали, где находится навигация, а не заставлять их находить, являются ли ссылки для навигации или нет.

Ответ 7

Я не согласен с добавлением дополнительных тегов. Если подробный словарь был фактически импортирован, то для каждого слова в словаре может быть другое имя тега. Названия дополнительных тегов не помогают, поскольку они могут сообщать людям о других смыслах, но ничего не делают для облегчения машинного разбора языка. Вот почему мне не нравятся "семантические" теги для HTML5, так как я считаю, что это скользкий наклон к тому, что он слишком сложный, хотя и обеспечивает слабое решение проблемы, которая не полностью решена.

По-моему, данные структуры языка разметки так же, как описывают ее в форме древовидной диаграммы. Благодаря анализу структуры и правильному использованию семантических соглашений, таких как RDFa, контекст может быть использован для обеспечения определенного значения для имен общих имен общих имен. В таком случае избыточный словарь не должен существовать, а структурно избыточные имена тегов, такие как нижний колонтитул и в сторону, могут быть устранены. Конечная цель состоит в том, чтобы сделать контент более быстрым и точным для интерпретации как людьми, так и машинами одновременно, используя как можно меньше кода для достижения этого результата. Как это решение имеет меньшее значение, кроме HTML5.

Ответ 8

Я думал, что XML - это стратегия назначения семантики.

Насколько я знаю, это не так. XML позволяет определять новые языки, которые все разбираются одинаково, потому что все они используют синтаксис XML.

Он сам по себе не предоставляет никакого способа добавить значение ( "семантический" означает "значимый" ) для этих языков. И пока компьютеры не получат искусственный интеллект, они не понимают смысла, поэтому смысл - это то, что согласуется между людьми. HTML является наиболее часто используемым языком с согласованным значением его тегов.

Поскольку HTML настолько распространен, полезно добавить к нему несколько значимых тегов, которые довольно распространены в их приложении. На это нацелены новые теги HTML5. Авторы спецификаций HTML5 действительно могли продолжить этот маршрут, создав теги для каждого конкретного значения смысла, но поскольку они не являются роботами, они, вероятно, не будут.

<section> является полезным и достаточно общим для значимого применения во многих документах. <author-last-name> isnt. Различие между ними - это вызов суда, поэтому люди, а не компьютеры, пишут спецификацию.

Для пользовательской семантики, которая слишком специфична для добавления в HTML как теги, HTML5 определяет микроданные.

Ответ 9

Я читал книгу Энди Кларка Превышение CSS (стр. 33).

..., теперь широко признано, что имена презентаций, такие как заголовок, слева или красный, которые описывают элементный вид или положение - плохой выбор.

После прочтения этих строк я спросил себя: эй, нет ли элементов в спецификации HTML5, таких как header, footer? Почему нижний колонтитул более семантический? Энди в своей книге выступает за site-info для идентификатора нижнего колонтитула, и это имеет больше смысла ИМХО. Нижний колонтитул представляет собой презентационное имя (описывает положение элемента).

Ответ 10

Одним словом, AJAX. Новые теги предназначены для поддержки того, что делают разработчики реального мира, заменяя некоторые из типов титанов <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav">, с которыми страдают многие веб-сайты. Единственным <div>, оставшимся в HTML5, является крючок стиля.

Семантика, которая распространяется на теги из классов, это те, которые разработчики свободно использовали в качестве лучших практик, учитывая расширенный период принятия xhtml/css. Просмотрите версию разработчика WHATWG на странице разделов спецификаций здесь. Сам документ - это удовольствие, но я не буду его испортить, если вы еще не видели его.

Одной из менее очевидных причин для некоторых решений, принятых W3C, является важность Webkit. Если вы посмотрите, вы можете видеть, что они были лучше, чем некоторые, чтобы взять текущую работу рабочей группы HTML5 и реализовать идеи. Они исторически были в ожидании соответствия (см. Здесь). W3C поставил высокий приоритет на своих (т.е. Android, iPhone, Googlebot, Chrome, Safari, Dreamweaver и т.д.). Google, пользователи рамок, Wordpress/Moveable Type/Joomla! пользователи типа и другие хотели самостоятельные строительные блоки, так что это стиль, который мы получаем.

Facebook является модульным. Решающие дизайнерские сетки являются модульными. Wordpress является модульным. Ajax лучше всего работает с модульными структурами страниц. Виджеты - это модули. Плагины - это модули. Казалось бы, мы должны пытаться выяснить, как применять эти теги, чтобы упростить привязку соответствующих элементов и активировать их в нашем гибридном веб-сервере document/application/info-network.

В заключение HTML5 должен быть написан как xml (опять же, см. спецификацию), чтобы гарантировать, что инструменты и машины, создающие запросы ajax для части документа, получат хорошо сформированный полезный ответ. Насколько это удивительно в сочетании с вещами, такими как медиа-запросы для таких устройств, как устройства чтения каналов, брайлевские принтеры, аннотаторы и т.д.. Я вижу (близкое) будущее, когда что-либо с хорошим семантическим контентом - это автоматическая подача новостей! Это происходит только в том случае, если разработчики принимают и записывают совместимые документы.