Pull to refresh

Грядёт Ragnarök! Или Opera 11.50 на подходе

Reading time4 min
Views634
Ragnarök — браузер викингов с новым алгоритмом разбора HTML5!

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



На этой неделе вы увидите классный пример HTML5.

Интернет изобилует играми на , HTML5 видео плеерами, drag-and-drop whizz-bangs и другими примерами HTML5 и «HTML5». Но здесь вы увидите действительно интересный пример, вероятно лучший на этой неделе. Готовы ли вы?
Итак:


<b><b><i>Yo!</b></i></b>


Я вижу что вы удивлены, что же давайте разберемся в чем дело. Элементы неправильно вложены, в этом случае тег
<i>
должен быть первым и закрытым. И как построят DOM различные браузеры?

Мы можем это проверить с помощью Opera Dragonfly и её эквивалентов или с помощью Ian Hickson's DOM viewer

Internet Explorer 9 и Safari 5 дадут такой результат:


<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B><I></I>
</BODY></html>


В то время как Opera, Firefox и Chrome дадут такой


<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B>
</BODY></html>


Все браузеры разобрались с неправильной вложенность, но не последовательно, обратите внимание что Internet Explorer и Safari имеют дополнительный пустой элемент
<i>
, в то время как Opera, Firefox и Chrome его не имеют. Что правильно? В HTML4, верны оба варианта. Потому что спецификация HTML4 описывает только то что делать с хорошей разметкой, но не с плохой и мы знаем что 95% веба не проходят валидацию. Таким образом браузеры брошены на произвол и сами вынуждены думать что делать с плохой разметкой, так-как обработка ошибок в спецификации HTML4 не предусмотрена.

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

К счастью, в настоящее время есть решение этой проблемы.

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


Так валидация ушла в прошлое?
Абсолютно нет. Она по прежнему остаётся жизненно важным инструментом обеспечения качества и только то что алгоритм разбора HTML5 будет воспроизводить совместимый DOM еще не означает того, что это тот DOM, который вам нужен.

Реализация в Opera
Наш старый алгоритм разбора HTML базировался на том что был написан 15 лет назад. Он постоянно дописывался чтобы идти в ногу с изменением стандартов и множеством путей чтобы не следовать спецификации. После всех изменений код стал походить на переукрашенную ёлку и добавление новых возможностей стало очень сложным без стука по всему дереву.

С решением переписать алгоритм разбора появилась возможность очистить весь дизайн.

Теперь мы с гордостью можем заявить что новый парсер Ragnarök проходит тест на соответствие спецификации HTML5, основаный на html5lib, на 99,9%. Недостающие 0.1% будут реализованы к моменту когда Ragnarök уйдет на золото. Весь набор тестов также будет опубликован и вы сможете сами убедиться во всём, ну и побаловаться с различными браузерами.

Ragnarök также набирает 11 из 11 (плюс 2 бонусных бала) на несколько не полном (и следовательно вводящем в заблуждение) html5test.com (два бонусных бала за внедренный SVG и MathML в HTML5)

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

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

Хватайте пока горячее!
Ссылки на загрузку выше.

Внимание
Это техническая демка и некоторые вещи в ней могут не работать, например m2 имеет некоторые проблемы.

Ваши замечания по поводу парсера или ошибки оставлять тут.
Tags:
Hubs:
Total votes 45: ↑38 and ↓7+31
Comments26

Articles