CSS-live.ru

Почему мы не добавим в HTML элемент <чудесный>?

Перевод статьи Why don’t we add a <lovely> element to HTML? с сайта www.brucelawson.co.uk, опубликовано на css-live.ru с разрешения автора — Брюса Лоусона

Вчера был интересный разговор, который начала Сара Суайдан:

твит Сары Суайдан (@SaraSoueidan), 8 октября 2018 г. в 16:36:

Вот что я хотела бы увидеть в HTML:
<color value=“” />
Просто. Чрезвычайно полезно, особ. для дизайн-систем сегодня.

Тут, пока никто второпях не подумал «но ведь цвет — это не контент, а оформление!», Сара говорила о страницах с палитрами образцов цвета. В этом случае цвета — именно контент. Кажется, что это хороший кандидат в семантические элементы, потому что у него есть значение.

На правах Древнего Старожила Веба, я сел и пораздумывал над этим.

картина Рембрандта «Размышляющий философ»

HTML: растраченная молодость

Первая редакция HTML была маленьким набором тегов, упомянутых в письме Сэра Дядюшки Тимбо (т.е. Тима Бернерса-Ли — прим. перев.) в октябре 1991 г. и принятых в ноябре 1992 г. Когда появился HTML2, некоторые теги сменили названия, и добавилось еще немного тегов, по которым видно, что HTML задумывался в основном как язык для математиков и компьютерных гиков: <var>, <samp>, <code>, <pre>, <kbd>, а также ныне покойные <xmp>, <dir> и <listing>.

В то время у нас было всего два оформительских элемента — <b> и <i> (и то еще вопрос, считать ли <i> оформительским — спецификация гласит «Если необходимо определенное отображение — например, при указании на определенный атрибут текста, как во фразе “Выделенный курсивом текст является обязательным” — с помощью элемента для типографики можно обеспечить, чтобы требуемая типографика применялась везде, где можно»).

Последующие редакции HTML отражали перемены в использовании веба: это были уже не просто документы для чтения, как представлял себе Сэр Дядюшка Тимбо, так что нам понадобился способ отправлять информацию обратно на сайты — отсюда произошло всё разнообразие разметки для форм, впоследствии как нельзя лучше послужившее электронной коммерции. Добавились таблицы, чтобы показывать данные, расширяя исходную нишу веба для показа математических статей и обмена ими. Побочным эффектом этого стало то, что креативные личности смогли (зло)употреблять таблицами для создания красиво выглядящих сайтов, что означало, что сайты стали еще привлекательнее коммерчески (а также целый зоопарк презентационной разметки, сейчас отмененный, поскольку есть CSS).

Когда появился HTML5, мы добавили еще целый ряд элементов для разграничения ориентиров в типичных дизайнах веб-страниц — <nav>, <header>, <article>, <main> и им подобные, что добавило удобства пользователям вспомогательных технологий.

По моим подсчетам, сейчас у нас 124 HTML-элемента, многих из которых веб-разработчики вообще не знают или регулярно путают друг с другом — например, в чем разница между <article> и <section>. Это подсказывает мне, что когнитивная нагрузка от изучения всех этих разных элементов становится чрезмерной.

HTML: спокойная зрелость

Есть масса всего, для чего у нас нет элементов в HTML. Годами я мечтал об элементе <location> для географической информации и элементе <person> (<person honorific="мистер" givenname="Брюс" familyname="Лоусон" nickname="Великолепный"> и т.д.)

Но вот некоторые из главных причин, почему мы вряд ли увидим их (или Сарин элемент <color>):

Правило 80/20 (оно же «закон Парето» — прим. перев.)

Смысл существования веба в том, чтобы делиться всем мыслимым человеческим знанием. Поэтому список возможных вещей, для которых можно было бы завести семантику, бесконечен. Учить и держать в голове наш теперешний список элементов, их семантики и атрибутов, и так уже становится для нас слишком большой нагрузкой. Так что у нас (хочется надеяться) есть как раз такой набор элементов, который выражает самую общеупотребимую семантику (если не обращать внимания на исторические артефакты, которые браузеры вынуждены по-прежнему поддерживать, ведь не можем же мы поломать веб).

Четырнадцать лет назад (!) Мэтью Томас написал:

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

Тестирование

Браузеры — зверюги сложные. Бьюсь об заклад, что это самые сложные программы из всех, что вот сейчас работают на вашем устройстве. Как человек, некогда работавший в браузерной компании, я знаю, какое сопротивление встречают попытки добавить новый элемент в язык — это увеличивает список того, что приходится тестировать, и повышает риск регрессий. Как написал Мэт Марквис в своей недавней истории отзывчивых изображений,

Но что важнее всего, это значило, что нам не нужно было воссоздавать в новёхоньком элементе все особенности img, потому что picture ничего собой и в себе не отображал.

Где и как этим пользоваться?

Самый важный вопрос: если бы элементы <person>, <location> или <color> были, что браузер с ними делал бы?

Мэтью Томас считал, что новым элементам нужна какая-то форма пользовательского интерфейса, чтобы веб-разработчикам было легче выбрать нужный:

Одним из выходов, как улучшить эту ситуацию, было бы уменьшить количество новых элементов — забыть про <article> и <footer>, например.

Другим выходом было бы рекомендовать более явное оформление по умолчанию для каждого из этих элементов — например, чтобы у <article> по умолчанию первая буква выделялась как буквица, <sidebar> прижимался к правому краю, у <header>, <footer> и <navigation> фон был чуть темнее, чем у их родительского элемента, а у <header>…<li> и <footer>…</li> по умолчанию было строчное представление. Тогда авторы с большей вероятностью выбирали бы подходящий элемент.

Как написал Робен Бержон,

Практически каждый в веб-сообществе согласен, что «семантика — это вкусно и принесет вам печеньки», и это, пожалуй, правда. Но стоит начать вникать чуть-чуть глубже, как становится ясно, что очень немногие действительно могут обосновать, почему.

Так что, прежде чем начинать всё по новому кругу, я вынужден спросить: что вы собираетесь дальше делать с этой треклятой семантикой?

Типичный ответ — «чтобы переосмыслить контент». На первый взгляд замечательно, но очень скоро приходит момент, когда приходится спросить «а переосмыслить для чего?». Например, если вы хотите отображать страницы на маленьком экране (тоже своего рода переосмысление), то <nav> или <footer> подскажут вам, что эти части — не контент, и их можно скрыть от глаз; но если вы разбираете юридические нюансы, от копания с некой эвристикой внутри <footer> толку не очень много.

Я думаю, что HTML должен добавлять только либо те элементы, функциональность которых по-другому просто немыслима (напр. <canvas>), либо те, семантика которых помогает переосмыслению *для задач просмотра веба*.

Так что же нам делать?

К счастью, в HTML уже есть малоизвестный элемент, в который можно оборачивать данные, чтобы сделать их машиночитаемыми — элемент <data>:

Этот элемент может использоваться для разных целей.

В сочетании с микроформатами или микроданными, этот элемент помогает обеспечить как машиночитаемое значение для анализаторов данных, так и человекочитаемое значение для отображения в браузере. В этом случае формат, который должен использоваться в атрибуте value, определяется используемым словарем микроформатов или микроданных.

Мануэль Штрель набросал быстрый пример палитры цветов Сары с помощью элемента <data>. Можно добавить к этому больше семантики, используя микроданные и свойство color из schema.org.

Некоторые словари из schema.org выдерживают «проверку на браузерный интерфейс» Робена и Мэтью (постольку-поскольку). Мы знаем, что расширенные сниппеты в результатах поиска Google используют кое-что из микроданных, равно как и WatchOS от Apple, вот почему я размечаю даты публикации в своём блоге с их помощью:

<article itemscope itemtype="http://schema.org/BlogPosting">
<header>
<h2 itemprop="title">
<a href="https://www.brucelawson.co.uk/2018/reading-list-201/">Список для чтения</a></h2>
<time itemprop="dateCreated pubdate datePublished"
datetime="2018-06-29">Пятница, 29 июня 2018</time>
</header>
<p>Некий восхитительный, достоверный контент</p>
<p><strong>Обновление: <time itemprop="dateModified"
datetime="2018-06-30">Суббота, 30 июня 2018</time></strong>Обновленный контент</p>

Google говорит:

Можно добавлять на страницы дополнительные элементы структурированных данных schema.org, чтобы помочь Google понять назначение и содержимое страницы. Структурированные данные могут помочь Google правильно классифицировать вашу страницу в результатах поиска, а также сделает вашу страницу пригодной для будущих возможностей результатов поиска.

Это весьма не точно (секретные алгоритмы Google и всё такое), но я не думаю, что это может повредить. Что-что вы там бормочете? Это добавляет в разметку вашей страницы десяток-другой байт? Посчитайте сначала свои килобайты из-за jQuery и React и от картинок во весь экран, а до этого нечего и беспокоиться об избыточной загрузке семантических калорий.

Что насчет кастомных элементов?

Кастомные пельмени вот-вот появятся™ в Edge, за флагом в Gecko и уже есть в Blink. Они позволяют вам заводить свои собственные новые теги, в которых должен быть дефис — напр., <лапочка-Брюс>. Однако, они — в первую очередь способ собирать отдельные куски функциональности («Компоненты») и обмениваться ими, и никакой семантики не добавляют.

Заключение

Итак, вот почему мы не особо включаем новую семантику в HTML (но не стесняйтесь предлагать свою, если для нее есть реальное применение). Однако, много чего можно сделать и с имеющейся семантикой, универсальными контейнерами типа <data> и встроенной расширяемостью. Счастливой вам разметки!

P.S. Это тоже может быть интересно:

7 комментариев

    1. В оригинале «Custom elephants» :). Долго думал, как лучше передать этот каламбур (чтоб было созвучно с «элементы» и смешно), решил, что «пельмени» подходят если не идеально по звучанию, то хотя бы неплохо по смыслу (их ведь каждый может лепить по-своему и начинять какой угодно функциональностью). А может, просто не пообедал вовремя..:)

  1. Кастомные пельмени вот-вот появятся™ в Edge, за флагом в Gecko и уже есть в Blink. Они позволяют вам заводить свои собственные новые теги, в которых должен быть дефис — напр., <лапочка-Брюс>. Однако, они — в первую очередь способ собирать отдельные куски функциональности («Компоненты») и обмениваться ими, и никакой семантики не добавляют.

    Imho. Браузеры, как обычно, на шаг позади придуманных сторонних «стандартов», и как обычно делают это чуть хуже и менее удобно.

    Под «стандартами» я имею ввиду компоненты React/Vue, а ещё ранее jQuery. Там уже всё придумано, вылизано тысячами фронтендщиками, сделано удобно и для себя любимых. Но нет же, надо сделать  нуля по-своему, так, чтобы без слёз было нельзя смотреть. Посмотрел я про эти «пельмени»… да застрелитесь они.

    1. У нас есть перевод статьи одного из «зачинателей» этих «веб-компонентов», где он поясняет, почему и зачем они с коллегами из Гугла выбрали именно такой подход (с учетом того, что это было еще в 2010-2011 гг.). Потом, правда, браузеры много лет не могли договориться, и во многом получилась типичная проблема компромиссов… но сейчас вроде наконец договорились, так что посмотрим, куда всё вырулит:)

    2. Придуманные сторонние «стандарты» меняются как перчатки каждые пару лет. Сейчас реализаций разных компонентных подходов невероятно много. Как только браузеры договорятся про использование shadow DOM все библиотеки смогут наконец-то выкинуть свои велосипеды и перейти на нормальный уровень абстракции.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.