Перевод статьи Long Term Web Semantics с сайта infrequently.org, c разрешения автора — Алекса Рассела.

Что-то раздражает меня во фразе «семантичный HTML».

Подразумеваемый смысл вполне ясен: использование HTML так, чтобы он был читаемым, описание вещей простым языком. Но «семантика» означает совсем не это. Можно было сказать просто «хорошо написанный» или «проверенный редактором». Это подошло бы лучше. Разметка, которую мы сегодня называем «несемантичной», на самом деле не такова: для конечных пользователей-то смысл есть, просто он передается слишком многословной разметкой. Рассусолено, но не «несемантично» (т.е. не «бессмысленно»).

Замысловатое и ускользающее от понимания — вроде того, что выходит из-под моего пера — плохо. Простое и ясное — хорошо. Сложно определить, что такое «просто» и «ясно», поскольку здесь замешаны вопросы значения и то, чего авторы (веб-разработчики) могут ожидать от читателей (браузеров). Для этого есть специальные фразы, напр. «Чтение на уровне 8 класса». Расчет на продвинутого читателя позволяет писать кратко и передавать тонкие оттенки. Знатокам не нужно разъяснять термины. Есть реальная польза в повышении общей грамотности в сообществе.

Употребление слова «семантичный», при котором речь идет о простоте, и подразумеваемое при этом значение этого слова говорят о глубокой путанице насчет того, как работает язык, роли разработчиков в донесении этого значения и реального потенциала смыслового развития для веба. Почему это важно? И чем плох «семантичный HTML»?

Возможно, ничем. Я склоняюсь к мысли, что это зависит от того, насколько мы приписываем успех веба как платформы везению, и как оцениваем вклад его специфики в этот успех. Моя версия, что везение (плюс удачность момента) и специфика соотносятся примерно как 40/60. У этой оценки нет экспериментальных подтверждений помимо сравнительных наблюдений за Flex, XAML, OpenLaszlo, JavaFX и Android-раскладками, а также их более настойчивыми конкурентами. Трудно планировать и проводить эксперименты по внедрению фреймворков для UI.

Как бы то ни было, мы можем набросать работающую схему участников, их интересов и того, что дает им HTML, чтобы лучше объяснить значимость, созданную теми ~60%. Это поможет нам осознать, в чем реальная семантика HTML, как она стала такой, и в чем может быть смысл ее осмысленного развития. Держа в уме эту схему, мы сможем выяснить, как изменения в HTML влияют на столь разных его потребителей. Она также позволит нам предвосхищать влияние JavaScript и расширений HTML (микроформатов, RDFa и Schema.org). С ними связано множество надежд и опасений, но если у нас будет работающая схема, которую мы можем примерить к наблюдаемой реальности, мы сможем перейти от чистых догадок к обсуждению механизмов.

Построить такую схему можно несколькими способами, но я думаю, что эффективнее всего рассмотреть основные аудитории HTML и выяснить, чего они хотят и что получают от HTML, CSS и JS. Тогда мы сможем очертить зоны пересечения этих интересов и обсудить, как возникает и передается значимость.

Аудитории

Разработчики

Огромная значимость высокоуровневых систем вроде HTML в том, что они дают возможность манипулировать множеством жутких программных слоев, не заставляя в них углубляться. Даже средь исканий объяснения структуры слоев веб-платформы в низкоуровневых терминах мы не вправе забывать важности высокоуровневых, по большей части декларативных форм.

Простой для модификации и повторения формат, дающий разработчикам (косвенную) власть над этим программными слоями, причем так, что это оказывается по силам даже тем, кто и не представляли себя «разработчиками», порождает монументальную мощь. Мощь в стиле «Вижуал-Бейсика»: то, благодаря чему сообразительные люди могут полностью обойтись своими силами даже при технологических ограничениях. Ctrl-R в роли команды «make all» для веба — не идеал, но и он дает огромные возможности. Нынешняя революция в инструментах разработчика — тем более. Влияние непосредственности нельзя переоценить. Слово Брету Виктору: «творцам нужна мгновенная связь». Декларативные формы сполна оправдывают себя, когда отвечают нуждам пользователей.

HTML превращает смертных в героев. Подобно тому, как это бывает в завязках дешевых комиксов, непосредственность и нетребовательность HTML дают «не-разработчикам» способность создавать вещи, которыми они могут делиться с другими людьми. Вещи, которые нужны людям. Именно этим отличаются хорошие инструменты. Он даже и на код не очень-то похож.

Значимость HTML с точки зрения разработчиков состоит полностью в показе разных штук на экранах, чтобы смотреть на них и взаимодействовать с ними. У модных течений «связанных данных» и «семантического HTML» есть странная склонность забывать об этом. Главная причина, по которой люди создают что-то в вебе — желание, чтобы другие люди нашли это что-то, и оно обогатило бы их жизнь. Обычно речь о визуальной и интерактивной значимости: показать, ввести в контекст, отобразить.

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

Разработчики пытаются добиться от пользователей, чтобы те восприняли именно то, что сами разработчики имели в виду. Что в статье важно. Что тут навигация, а что — основной контент. Какие элементы формы действительно обязательны. Для пользователей всё это — не «технические подробности». Семантичный контент — это то, что воспринимают конечные пользователи.

Пусть это отложится как следует. С точки зрения пользвателей, слайды PowerPoint или формы в PDF могут передавать практически ту же семантику, что HTML — визуальный и интерактивный контент, воспринимаемый как «значение» контента большую часть времени.

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

Подумайте о скромном <a href="...">: у него изначально есть интерфейс, чтобы отличить его от обычного текста (подчеркивание), плюс системная поддержка адресов и соглашения для них (посещенность, наведенность и т.п.), а также способность реагировать на ввод (переход по клику). Код для всего этого устрашал бы своим размером, и вам никогда не удалось бы навязать всем единые соглашения, если бы система не предоставляла свои. Но у тега ссылки всё это уже есть: связь между текстом и адресами, встроенный UI, поддержка поведения и прежде всего — невероятно компактная упаковка, благодаря которой вся эта мощь стала доступной любому, у кого есть текстовый редактор и FTP-клиент.

Дабы устоять пред искушением недооценить визуальные и интерактивные соглашения, представьте себе мир без них. Или мир, где у браузеров есть JS-овые API для перехода к другим документам, но нет встроенной системы, связывающей клики с переходами. Конечно, стихийный порядок мог бы возникнуть, но едва ли. За всё время, сколько существует флэш-контент, так и не появилось стандартного способа для «ссылок» между его единицами. Можно смело сказать, что обеспечение пользователей наглядными возможностями, чтобы помочь им решать свои задачи, и есть то, благодаря чему HTML преуспел.

Эти наглядные возможности, с точки зрения пользователей, и есть семантические соглашения веба. Это строительные блоки визуального и интерактивного языка. Они — и содержание, и значение.

Конечные пользователи

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

Технология, веб, «приложения»… это всё посредники. С хорошими посредниками нам проще получить нужное, и у них будут постоянные клиенты. Задача хорошей технологии — помочь пользователям получить то, что им нужно, быстрее, проще и с минимумом помех. Поэтому от нее не требуется обладание уникальным UI, если только вы не желаете выразить что-то очень ценное, что не по силам существующей системе. То, что визуальные и интерактивные соглашения не дают интерфейсам быть слишком индивидуальными — не случайность. Пользователи, дизайнеры и платформы изменяют наш визуальный язык все вместе. Если ваше приложение слишком далеко отобьется от стаи, его съедят.

Экономика HTML предпочитает встроенные компоненты UI дизайнерскому эксклюзиву: они быстрее и проще, даже если впечатление от их использования для данного сайта не идеально. Их понимают как пользователи, так и система, предоставляющая дефолтный UI «бесплатно» (сайтам не нужно строить его скриптами). По сравнению с ним изобретение JS-велосипедов оказывается еще менее выгодным.

Крупнейшей революцией в вебе стали поисковики. Построенные на основе соглашений HTML, поисковики позволили не только каждому публиковать, но и большинству — находить. PageRank лихо сыграл на соглашениях веба, чтобы извлечь смысл из хаоса. Поисковикам «виден» тот же контент, что пользователям (если он не спрятан в двоичном коде, открываясь лишь во время исполнения), так что можно передавать значение пользователям совершенно по-новому.

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

Не все пользователи одинаковы, конечно. Для многих UI по умолчанию бессмыслен или близок к тому. HTML приносит пользу и им, не потому, что заставил всех заботиться о доступности, а потому, что позволяет сторонним инструментам, выступающим от имени пользователей, заново интерпретировать высокоуровневый замысел в других низкоуровневых контекстах (напр. чтение вместо копирования блоками).

Опять же, невероятная мощь дефолтности играет поддерживающую роль: никакая вспомогательная технология не возникла бы, если бы встроенная библиотека элементов обычно не использовалась в основном одинаковым образом. Та же история и с поисковиками. Стимулы, которым подчиняются веб-разработчики — единственное, благодаря чему <a> не начал давным-давно стилизоваться по умолчанию как блочный контейнер (почему бы нет, это ведь короче, чем <div>). Эти стимулы вытекают из потребности быть понятыми большинством пользователей (теми, кто не пользуется вспомогательными технологиями). Простейший и лучший способ для этого — избегать переопределения слов. Пусть браузер рисует UI, придерживайтесь стандартного набора для всего остального и не пытайтесь вводить слишком много новых слов без крайней необходимости.

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

И последнее… Не могу не отметить важности адресов ссылок для конечных пользователей. Ни до, ни после них ни одна система не позволяла настолько легко делиться чем-либо, как распространение ссылок для обращения к контенту. Они — основа социальной составляющей веба. Для пользователей способность копировать ссылки создает мир возможностей делать то, для чего авторам приложений не нужно обеспечивать поддержку заранее. И еще раз, обеспечиваемое браузерами поведение по умолчанию дает огромную поддержку.

Издатели

Разметка, чисто текстовый веб и возможность поиска — неожиданное сочетание для издательского бизнеса, конечно. Но в пользовании этими благами он — ас. Допустим, издатель хочет публиковаться электронно… чем его может порадовать веб?

Адреса ссылок и возможность поиска. Если ссылки и возможность делиться ими хороши для пользователей, то для издателей они — просто бомба. Они получают наиболее непосредственную выгоду от социального поведения, и ссылки — смазка в шестернях этого механизма. Не требуя выпуска 2-й или 3-й версии, веб сделал «создание сайта» еще и возможностью связать всё со всем без лишних хлопот. И, конечно, в большинстве современных фреймворков вам придется еще постараться, чтобы адреса не получились более-менее приличными.

Наличие поиска в вебе де-факто позволяет издателям наращивать свой вклад в инфраструктуру публикации конечных пользователей. Никакой пересборки новой версии. Никаких одноразовых форматов обмена данными. Конфигурирование? Да. Надстройки и дополнительные соглашения, чтобы уплотнить поток информации? Наверняка. Но больше никакого переписывания целиком.

Поисковики

Роль поисковых ботов и движков недопонимают почти все, с кем я говорил. Вебмастера тратят массу времени, размышляя о «семантике» и «SEO» без какого-либо реального представления о целях и мотивах, стоящих за механизмами поиска. Здесь есть глубокие вопросы — что надо бы вернуть поисковику, когда я задаю вопрос, каковы мои с ним взаимоотношения? — но их пока мы можем опустить. Мне видится, что лучший ответ, который может дать вам поисковик — тот, который вы дали бы себе сами, будь у вас физическая возможность прочитать целые миллиарды документов. И явная цель разработчиков поиска, с которыми я общался — осуществить эту мечту.

Каковы практические выводы из этого для семантики? Ну, вы же не выберете документ, где половина контента от вас спрятана, верно? И уж точно не выберете его ради того контента. Действительно, документы, выдающие ботам и пользователям разный контент — скорее всего, спам. Из презентации Мэтта Каттса вполне ясно: индекс пытается увидеть веб так же, как видите его вы… и, конечно, помочь вам с выбором ответа. Но всё это основывается на определенном «понимании»… и платоновский идеал «понимания» контента не имеет никакого отношения к тайно внедряемым данным, он в первую очередь в том, что страница пытается донести до пользователя так, как сам пользователь это поймет.

Не знаю, как еще это подчеркнуть: когда мы, веб-разработчики, завязываемся в узел по поводу «семантики» и поисковиков, мы почти всегда волнуемся совершенно не о том. Конечно, можно выяснить, что действует, а чего делать не надо, но нужно постоянно держать в уме, что всё это временно. Задача поисковиков — понимать страницы так, как их понимаете вы. То, что они понимают их иначе — баг, который надо исправлять. И его исправят.

Если цель поисковиков — понимать страницы так, как пользователи, то и семантика, о которой мы заботимся — та, что имеет значение для пользователей. Мысль, что нам нужно создать еще один смысловой слой над/под/сбоку от контента… совершенно ниоткуда не вытекает.

Рассмотрим таблицы.

Наверняка всю вашу профессиональную карьеру вам говорили, что использовать <table> для чего-либо, не являющегося табличными данными — БЯКА (как минимум, «неправильно»). И всё же вы видите, что множество компьютеров в мире не взрываются из-за неправильного применения <table> . Или <li> . Или <dt>/<dd> .

С одной стороны, да, таблицы помогают визуально оформлять что-либо в табличном виде. Но история свистопляски с механизмами веб-раскладок привела к ситуации, когда единственным универсальным способом добиться полной программной власти над раскладкой было использование таблиц для нетабличных данных… как каркас верстки. У этого были практические проблемы: некоторые браузеры отображали их плохо или медленно. О постепенной отрисовке не было и речи. Хватало багов. Всё это привело к тому, что использование <table> расширилось далеко за пределы табличных данных. Без общеупотребительного толкования значимость интерфейса выхолостилась. Как бы ни теплилась у HTML-пуристов надежда на то, что когда-нибудь данные внезапно станут машиночитаемыми оттого, что они в элементе <table>, это точно далеко от сегодняшнего положения дел, по трем причинам:

1. Нахождение табличных данных в таблице не делает их полезными для кого-либо еще. Элемент <a> хотя бы дает пользователям какую-то возможность воспользоваться связями между UI и тем, к чему он относится, помимо «чистого представления».
2. В HTML больше нет ничего, что умело бы пользоваться этими данными. Даже если вы поместите все свои табличные данные в <table> , это не добавит мощности никакой другой части вашего UI.
3. Люди лгут.

Забудьте о машиночитаемости. Тег <table> не «растерял свою семантику», потому что его якобы «не так использовали», наоборот, он так и не стал чем-то «семантичным», потому что не смог развиться достаточно, чтобы иметь осмысленные отношения с чем-то еще, будь то с пользователями или с другими частями системы.

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

Ах да, я же упоминал ложь, так?

Да, люди лгут. И заставляют машины лгать за себя. Такова жизнь. HTML может быть «семантичным» в рамках своего предопределенного словаря лишь в той мере, в которой мы согласны использовать некоторые слова одинаковым образом — то, что мы чаще делаем по указке пользовательского интерфейса: посмотрите, в какое месиво превратились <article> , <section> и т.п. из HTML5. Добросовестные в целом действия добропорядочных людей не делают весь контент более достоверным или авторитетным, они лишь повышают средний уровень. Наша мысленная схема про веб-семантику должна учитывать, что в этом большом и страшном интернете какие-то куски кода, обозначающие себя как то-то и то-то, возможно, пытаются пользователя как-то обмануть. Так что показатели качества — первая попытка классификации в открытом вебе.

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

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

Семантика слезами обливается, когда не компьютеры, а люди создают язык и сами им пользуются. Хоть браузеры и выступают посредниками, вполне ясно, что HTML спроектирован для (некоторых) людей, и его визуальная семантика вертится вокруг того, чего хотят люди. Проблема с академическими подходами к семантике в том, что они не прошли испытания передачей семантики между поколениями. Можно описать всё в одном поколении — возможно, даже заставить всех использовать некое подмножество языка одинаковым образом, но что будет, когда пройдет время? Настоящая проблема веб-семантики — вероятностная природа значения, и ее не устранить уточнением локальных описаний, нужен более глобальный взгляд.

Семантический дрейф

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

HTML в этом не отличается. С чего бы ему отличаться? Что означает <b>? Это оформление? Можно ли найти случай, где он не был бы оформлением? Чем теснее привязка к изначальной модели данных, тем сильнее тяга к дрейфу. Слова, в конце концов, пластичны. Да, если мы скажем «голубь», подразумевая «тыква», все услышавшие это посчитают нас идиотами, но когда достаточно людей воспримут это значение и начнут его использовать, неизбежный дрейф возьмет своё.

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

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

Латынь в наши дни накапливает не так уж много новых значений.

И, кстати, никто на ней и не говорит.

Это не совпадение.

Создатели браузеров

Мотивы компаний, разрабатывающих браузеры, на самом деле понять легче всего. Для этого нужны лишь тонкая, нерыночная версия понятия «конкурентный» и понимание, что компании продвигают браузеры, каждый под своим брендом и со своим рекламным бюджетом, но которые при этом поставляются с браузерными движками, у которых ничего этого нет. Почему? Потому что браузерные движки не приносят денег — в лучшем случае производитель браузера является еще и производителем платформы и хочет использовать веб-технологии в борьбе платформ, но это крайне мало связано с браузерами.

Ключевая вещь, которую нужно понять насчет команд разработчиков движков, фанатов стандартов, шлифующих их «острые углы», и (главным образом) C++-программистов, заставляющих всё это работать — то, что большинство из них не делает сайты. Как и их клиенты (конечные пользователи). Большинство программистов браузеров получают информацию, что надо бы реализовать, а что нет, из вторых рук. Самым сильным аргументом при этом оказывается «наши конкуренты реализовали нечто». Следующий по силе — «есть такая спецификация». Последний — «Это отличная идея, решающая проблему». Звучит как какое-то ретроградство? Подумайте о стимулах: если вы не главный источник прибыли, стоит ли вам разбиваться в лепешку ради «фичи», которой вы не сможете выделить свой продукт среди других (кроме, разве что, общего впечатления от его быстродействия). Веб-разработчики приведут ваш движок к «общему знаменателю» для конечных пользователей, и почти никто из веб-разработчиков не бросится использовать только новые (они же «проприетарные») возможности. Чтобы выйти из патовой ситуации, производители ищут признаки меньшего риска: действия конкурентов и спецификации. Если другие это сделали, наверное, это безопасно, и никто не хочет быть последним. А раз есть спецификация, то она наверняка прошла несколько этапов обтачивания самых неудобных углов (эх, если б только это было правдой!).

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

Семантическая эволюция

Логичное представление об эволюции веб-платформы начинает вырисовываться. Она должна:

• позволять разработчикам создавать новую семантику (визуальную и интерактивную) для конечных пользователей, когда словаря HTML недостаточно;
• быть осмысленно декларативной, желательно путем ссылок на другие данные/URL-ы для улучшения опыта;
• иметь возможность стандартизироваться со временем.

Последний пункт, возможно, противоречив: многие из разработчиков JavaScript-библиотек уверяли меня, что если они могут убедить каждого использовать определенное окошко выбора даты (например) на базе jQuery, то зачем заморачиваться созданием стандартной версии?

Аргумент за стандартизацию — не то, что она ускорит внедрение новых существительных/глаголов, а скорее то, что она может помочь распространению их для новых поколений, тем самым снижая «цену» использования их в диалоге. Это роль словарей, и это логичная роль для HTML: как только семантика чего-либо доказала свою ценность, широко используется и имеет единую семантическую трактовку (визуальную, интерактивную и декларативную), HTML может узаконить наиболее массово используемый набор значений, тем самым позволяя создателям браузеров внедрить эти канонические версии. Для веба есть разница в эффективности между использованием «бесплатного» HTML-элемента и затратами на подключение виджета из библиотеки, всех ее зависимостей и интеграцию скрипта в свое приложение. Словами, которые, предположительно, знают все остальные, проще всего выразить значение. HTML — это человеческий язык для людей, разве в нем должно быть по-другому?

Это одна из идей, которыми руководствовались создатели веб-компонентов. Позволяя разработчикам расширять семантику HTML напрямую, мы получаем реальный шанс сделать веб-семантику для конкретных случаев, вроде той, что предлагают микроформаты и Schema.org, более осмысленной — во-первых, придавая ей непосредственную значимость для конечных пользователей в форме UI, во-вторых, обеспечивая такую интеграцию разметки, которая позволяет поисковикам извлекать какой-то смысл из обоих вышеупомянутых.

После долгих блужданий, в ходе которых библиотеки виджетов бьются друг с другом, сплавляются воедино и становятся «стандартами де-факто», сленг может попасть в каталог. Не дословно, конечно. Точная форма <person> или <place>, скорее всего, отбросит библиотечный префикс (напр. <polymer-person>), а встроенный UI пожертвует настраиваемостью в обмен на интеграцию с системой (для мест может всплывать карта, для людей возможно взаимодействие с адресной книгой). При таком раскладе у браузеров будет осмысленное занятие, и при расширяемости в самом ядре этой экосистемы, такой процесс может сформировать иерархию, где фантазии и типы данных стремительно эволюционируют (и вымирают) по краям, но те, что выживают и действительно входят в обиход, в итоге заслуживают включения в «словарь» — живую спецификацию HTML.

Не приведет ли это к повторению истории с вавилонской башней?

Всё может быть, но вряд ли; как минимум до тех пор, пока словари не отстают от языка, что у нас в ходу. Если HTML и браузеры продолжат интегрировать новые существительные и глаголы, решающие реальные задачи, преимущества общего словаря перед громоздкими определениями создадут огромный антистимул против дальнейшего использования самописных решений. Сила экономии байтов при передаче и оптимизации, которым браузеры дают добро, порождают огромные волны унификации, которые позволят нам и далее развивать язык до края и через край, насколько нужно, не боясь, что он скатится до не понимающих друг друга поддиалектов.

Мы снова и снова убеждаемся, что процесс стандартизации HTML лучше всего работает, когда обтачивает острые углы существующих хороших идей, а не взваливает на себя ношу изобретения их впервые. Возможность для сообщества людей изобретать, воспроизводить и распространять новую веб-семантику — моя величайшая надежда на веб-компоненты. Это одна из причин, почему я захотел работать над ними, и теперь, когда они уже почти у нас в руках, пора задуматься о том, что дальше. Чему мы научимся на них? Как нам поощрять полезную семантику, теперь, когда мы не ограничены словарным запасом HTML-третьеклассника? Как нам с ответственностью вырастить HTML во взрослую платформу, основываясь на примерах и внимании к тому пользовательскому опыту, которого мы все от него ждем?

Это вызов для нас. Мы должны видеть эпохи в вебе не как вещи в себе, которым мы можем лишь подчиняться, но как ландшафт, который, стоит нам правильно определить правила, мы сами сможем быстро формировать для себя и медленно — для всех остальных.

Благодарности

Я благодарен Брюсу Лоусону, Дайону Элмаеру, Стиву Фолкнеру, Джейку Арчибальду и Фрэнсис Бэрриман за их комменатрии к раннему черновику. Все ошибки и опечатки целиком мои.

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

• Удар откуда не ждали: псевдокласс :has() ломает сайты на jQuery
• Голограммы, пленочные засветки и шейдеры на чистом CSS
• Как читать W3C-спецификации