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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

  

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

  

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

Насколько я знаю, нет, это не было & # 8217; t. XML позволяет определять новые языки, которые анализируются одинаково, поскольку все они используют синтаксис XML.

Это не & # 8217; t само по себе не предоставляет какого-либо способа добавить значение (& # 8220; семантическое & # 8221; просто означает & # 8220; значимое & # 8221 ;) на эти языки. И до тех пор, пока компьютеры не получат искусственный интеллект, они на самом деле не понимают смысла, поэтому смысл - это то, что согласовано между людьми. HTML является наиболее часто используемым языком с согласованным значением его тегов.

Поскольку HTML настолько распространен, & # 8217, полезно добавить к нему несколько значимых тегов, которые являются довольно общими в их применении. Новые теги HTML5 нацелены на это. Специалисты по HTML5 & # 8217; авторы действительно могли продолжать этот путь, создавая теги для каждого конкретного возможного значения, но поскольку они & # 8217; не роботы, они, вероятно, победили & # 8217 ;. т

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

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

Answer 9

Я читал книгу Энди Кларка Превосходящий CSS (стр. 33).

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

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

Answer 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 лучше всего работает с модульными структурами страниц. Виджеты - это модули. Плагины - это модули. Казалось бы, мы должны попытаться выяснить такие вещи, как применение этих тегов, чтобы упростить подключение соответствующих элементов и активировать их в нашем документе / приложении / информационной сети гибридной Web 2.0.

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