«Готов» ли HTML?
Перевод статьи Is HTML «complete»? с сайта brucelawson.co.uk, автор — Брюс Лоусон.
Не так давно Тим Брей написал интересный пост под названием </html>, в котором он заявляет:
Никто, похоже, не заинтересован в работе над «словарем» (под которым понимаются те штуковины в угловых скобках, из которых состоит HTML).
На мой взгляд, HTML готов. Это ни в коем случае не означает, что я считаю, будто вся платформа веб-программирования находится в надлежащем состоянии…
Давайте отложим инструменты и сосредоточимся на более важных проблемах.
Я согласен с Тимом в том, что сейчас важнее исправить все недостатки веб-платформы, чем добавлять в HTML новые элементы. Он упоминает устранение тех проблем, которые пытаются решить jQuery, Backbone, Angular, Less, DART и др. Я бы хотел добавить в этот список Service Workers, Web Manifest, API для работы с различными устройствами. Во всём этом нужно срочно выровнять баланс возможностей между веб- и обычными приложениями.
Но я считаю, что заявлять, будто работа над HTML завершена, неправильно. Мы уже проходили это в декабре 1999 г., когда был издан HTML 4.01, считавшийся «готовым» на тот момент. В HTML5 было добавлено множество новых элементов, некоторые из которых широко используются (к примеру, 20% сайтов из 100 000 самых популярных используют доктайп HTML5, 12% из них используют тег <header>).
Некоторые из элементов HTML5 не получили большой популярности. Я склонен согласиться с Мэттью Томасом, который (в 2004-м!) писал, что новым элементам потребуется что-то вроде пользовательского интерфейса:
Одним из способов улучшения сложившейся ситуации могло бы стать сокращение количества новых элементов – например, забудьте об <article> и <footer>.
Другим способом могло бы стать создание более выразительного представления для каждого из этих элементов — к примеру, элемент <article> по умолчанию имел бы отформатированную первую букву, элемент <sidebar> использовал бы обтекание (float) по правому краю, элементы <header>, <footer> и <navigation> имели бы чуть более темный фон, чем их родительский элемент, а для структур <header>…<li> и <footer>…<li> по умолчанию бы использовалось строчное представление. Это бы повысило шансы того, что авторы будут выбирать подходящий элемент.
Однако не каждое проявление UI имеет визуальное представление. В языке по-прежнему имеется немало дыр, которые надлежит исправить с помощью WAI-ARIA; в блоге, посвященном webkit, Джеймс Крейг пишет:
Многие из исходных возможностей ARIA (такие как диалоговые окна, маркировка и меню) в последних версиях HTML были выделены в самостоятельные элементы. Однако с 1990-х годов в Вебе существуют определенные схемы взаимодействия, которые до сих пор не имеют встроенной поддержки или не всегда корректно отображаются, такие как календари, поля со списками, наборы вкладок, сетки с данными, окна для представления дерева элементов и т.д. Все эти элементы управления веб-разработчики должны создавать самостоятельно, используя специальный код или существующие JavaScript-фреймворки.
Стив Фолкнер создал список функций и свойств Aria, не доступных в HTML5. Я не говорю, что все они должны стать элементами либо атрибутами, но это демонстрирует, что то, что создают люди, постоянно опережает существующую семантику HTML.
С тех пор как WHATWG прекратила добавлять новые элементы, мы могли наблюдать появление в языке элемента <main>, который, несмотря на относительную молодость, используется в 5% сайтов HTML5 из 100 000 самых популярных. Несмотря на отсутствие визуального UI, он осуществляет привязку к вспомогательным технологиям, тем самым позволяя пользователям быстро найти на странице основной контент.
Аналогично, в язык был добавлен элемент <picture> и связанные с ним атрибуты для использования отзывчивых изображений (srcset, sizes, дескрипторы x и w).
Брайан Карделл, Леони Уотсон и Стив Фолкнер разрабатывают спецификацию для расширения «Панели и наборы панелей», которое «определяет элементы и атрибуты для создания панели или набора панелей, основываясь на единой парадигме взаимодействия».
В других случаях попытки добавления в язык новых полезных декларативных возможностей резко пресекаются. Например, для <table sortable>, чтобы сортировать таблицы с данными средствами самого браузера (очень частая потребность), уже была написана спецификация (подкрепленная личным опытом Стюарта Лэнгриджа за 9 лет), но реализацию отклонили, поскольку «Чем пытаться объять платформой необъятное, лучше бы кто-нибудь создал библиотеку веб-компонентов, поддерживающую спецификацию Хикси».
Ах да, веб-компоненты — еще очень нескоро они будут готовы для использования на реальных проектах, полностью зависят от JavaScript’a, а их реализация для авторов на порядок сложнее, чем добавление единственного атрибута.
В меня вселяет надежду Манифест о Расширяемом Вебе, который гласит:
Мы хотим позволить вести разработку новых возможностей на JavaScript, за которой будет следовать их внедрение в браузеры и стандартизация… Мы хотим, чтобы веб-разработчики писали более декларативный код, а не наоборот.
Думаю, что тестирование функциональности в JavaScript, а затем ее стандартизация и добавление в ядро HTML/CSS — это будущее стандартизации. Поэтому заявлять, что HTML «готов», пожалуй, еще рано.
(Благодарность Стиву Фолкнеру за его обработку данных для предоставления статистики использования элементов <header> и <main>).
P.S. Это тоже может быть интересно:
Ненавижу разработку сайтов!
Марина жжот