Десять возможностей, которые мы хотим видеть в HTML6

29.01.2015 | 19:41 Аналитика

Больше контроля над видео, подключаемые языки, сильные микроформаты — вот чего стоит придерживаться W3C в следующем стандарте HTML

Название «HTML5» появилось несколько лет назад, но сам стандарт не был окончательно принят до конца 2014 года. За пять с лишним лет он получил второе воплощение, чтобы полностью реализоваться и быть ратифицированным. Ранние пользователи HTML5 быстро достигли его пределов, и обнаружили горькую правду об ограничениях спецификации.

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

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

Вот 10 предложений по улучшению HTML6.

Предложение № 1: Больше контроля над видеообъектами

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

Некоторые умные люди начали использовать это, чтобы синхронизировать аннотации с другими объектами DOM (Document Object Model — «объектная модель документа»). Но как насчет лучших callback hooks и механизмов синхронизации? Как насчет способности смешивать DOM с видео?

Предложение № 2: Выбор размера картинки браузером

Сколько пикселей нужно фотографии, чтобы хорошо выглядеть на экране? Это значение зависит от мобильного телефона, ноутбука или монитора. Даже размер окна изменяет минимальное разрешение. Но стандарт HTML тэга <img> имеет только один SRC, который указывает на один файл изображения, который может иметь слишком много или слишком мало пикселей для эффективного рендеринга. Если картинка слишком большая, браузер должен уменьшить ее, чтобы отобразить, тратя пропускная способность сети и время. Если она имеет слишком маленькое разрешение, то выглядит зернистой. Лучшее, что протокол HTML может предложить — нужную ширину или высоту изображения, а сервер может предоставить оптимальное разрешение.

Предложение № 3: Подключаемые языки

Если вы любите JavaScript – хорошо. Если нет – вам придется нелегко. Стандартный HTML-браузер говорит только на JavaScript, но по какой-то причине мы должны указывать тип языка text/javascript в каждом тэге. Уже в HTML4 это не является значением по умолчанию.
Рекомендации HTML4 предполагают, что кто-то может использовать такие типы, как text/tcl или text/vbscript, но кто-нибудь использует их на самом деле? Microsoft уже убрала устаревший text/vbscript в IE11, и вряд ли многие работали с tcl в последние годы.

Так быть не должно. Google медленно продвигает Dart, и веб-страница для версии Chromium с реальной версией Dart включает в себя это зловещее предупреждение: «Не используйте Dartium в качестве основного браузера, и не распространяйте Dartium пользователям!»

Но в будущем, мы могли бы иметь более надежный и подключаемый набор языков. Почему нет? Будет ли это работать? Это добавит больше гибкости и выбора дизайна для разработчиков. Разделит ли это на враждующие группы Интернет? Если есть твердая реализация с открытым исходным кодом, она может быть принята всеми браузерами. Возможно будет трудно заставить веб-сайты использовать подключаемый язык для контента широкой аудитории — JavaScript может продолжать владеть большей частью Web — но это может быть хорошим вариантом для более специализированных расширений, которые используют специализированный язык.

Предложение № 4: Подключаемые препроцессоры

Другим решением для расширения выбора разработчиков за границами JavaScript, является охват инструментов, которые преобразуют языки в JavaScript. Многие разработчики уже используют препроцессоры для перевода «языков», таких как CoffeeScript в JavaScript. Конечно, под капотом, CoffeeScript не сильно отличается от JavaScript. Это, скорее, альтернативный синтаксис, чем другой язык.

Не существует причин, по которым все Тьюринг-полные языки не могут быть переведены. Список языков Джереми Ашкенаса, которые могут быть скомпилированы в JavaScript, удивительно широк. Lisp, Python, Ruby, Erlang, Scala — список можно продолжать и продолжать.
Такое предложение имеет свою цену. Когда один язык кросс-компилируется в JavaScript, он, как правило, минимизирован, и в то же время, производит версию, которая меньше и легче передается через Интернет. Сделать это один раз в момент развертывания является гораздо более эффективным, чем делать каждый раз в браузере каждого пользователя.

Но уменьшенная версия имеет свои недостатки. Открытость всегда была одним из самых больших преимуществ Интернета. Все могут прочитать и найти ошибки кода JavaScript, который пишется в удобной для восприятия человеком форме. Кросс-платформенный и уменьшенный код бесполезен для других людей. Это медленно ломает открытость Интернета.

Есть и другие преимущества для осуществления преобразования в браузере. Каждая машина немного отличается и процесс преобразования может воспользоваться знаниями о размере оперативной памяти, библиотеках видеокарты и т.д. Текущая версия HTML предполагает общий вариант JavaScript и делает гораздо более трудным оптимизацию кода для локальной машины.

Предложение № 5: Гарантированные библиотеки

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

Некоторые веб-сайты используют стандартные кэшируемые версии некоторых библиотек, поддерживаемых такими компаниями, как Google или Yahoo, и это может сэкономить трафик, но следующий стандарт HTML должен делать это лучше. Если значительное число дизайнеров утвердит библиотеку, она может распространяться с браузером. Это позволит сэкономить еще больше времени на очередном обновлении в кэше версии jQuery 1.9.

Предложение № 6: Охраняемый доступ к контактной информации

Браузеры уже обмениваются информацией о местоположении — если пользователь нажимает соответствующую кнопку. Почему бы не пойти дальше? Люди часто хотят получить адрес электронной почты или номер телефона для базы данных контактной информации устройства.

Сейчас им приходится копировать и вставлять. Почему бы не позволить JavaScript самому искать, чтобы избавить от копирования и вставки? Это было бы здорово для мобильных устройств. Интерфейс может предложить точный контроль, позволяя людям получить автоматический доступ к коду, получаемому из определенных доменов.

Предложение № 7: Интеграция камеры

Учитывая распространенность веб-камер и камер на мобильных телефонах, редко случается взаимодействие пользователя с браузером, у которого нет доступа к камере и микрофону.W3C уже изучает возможность добавлять фото- и видео-захвата в формы, и некоторые браузеры поддерживают свою собственную версию, как webkitGetUserMedia. Легко представить и больше.

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

Предложение № 8: Укрепление аутентификации

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

Предложение № 9: Улучшение аннотаций

Секция комментариев у основания статей — только часть того, как мы можем оставлять комментарии, но стандартная структура может позволить добавлять аннотации, привязанные к параграфам, предложениям или даже словам. Сложный вариант может даже позволить аннотации к изображениям или моментам внутри видео. Некоторые веб-сайты начинают предлагать эти возможности, но некоторые преимущества заключаются в стандартизации API, чтобы все веб-сайты и браузеры обращались с аннотациями одинаково. В W3C есть группа, изучающая области и предлагающая базовые стандарты.

Предложение № 10: Более сильные микроформаты

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