Ragnarök is coming! Or Opera 11.50 on the way

    Ragnarök - Viking browser with a new HTML5 parsing algorithm!

    This week our lab build called Ragnarok debuts, which contains our implementation of the HTML5 parsing algorithm. We would like you to test this assembly. You can pick up the following links.



    This week you'll see a cool HTML5 example.

    The Internet is replete with games on HTML5 video players, drag-and-drop whizz-bangs and other examples of HTML5 and "HTML5". But here you will see a really interesting example, probably the best this week. Are you ready
    So:

    Yo!


    I see that you are surprised, so let's figure it out. Elements are nested incorrectly, in this case the tag
    must be first and closed. And how do different browsers build the DOM?

    We can check this with Opera Dragonfly and its equivalents or with Ian Hickson's DOM viewer

    Internet Explorer 9 and Safari 5 will give this result:

    Yo!


    While Opera, Firefox and Chrome will give this

    Yo!


    All browsers sorted out with incorrect nesting, but not sequentially, note that Internet Explorer and Safari have an additional empty element
    , while Opera, Firefox and Chrome do not have it. What is right? In HTML4, both are true. Because the HTML4 specification only describes what to do with good markup, but not bad markup, and we know that 95% of the web does not pass validation. Thus, browsers are left to their own devices and themselves are forced to think about what to do with poor markup, since error handling is not provided in the HTML4 specification.

    Such simple markup already produces very different DOMs, and now imagine
    what will happen as a result of a larger number of real examples with tags where there are tens and hundreds of elements. Writing javascript code that should work equally in all browsers with such mismatches is one of the main reasons for hair loss and crying among web developers.

    Fortunately, there is currently a solution to this problem.

    HTML5 parsing algorithm.
    The HTML5 specification includes rules for parsing any markup that is both valid and non-valid. After all the browsers have received their HTML5 parsing algorithms, the same markup will produce the same DOM in all relevant browsers.
    There are two main consequences of this:
    • Javascript coders will be fun and with lush hair
    • Users can expect fewer incompatibility issues between their favorite sites and browser.


    So is validation a thing of the past?
    Absolutely not. It still remains a vital quality assurance tool, and just because the HTML5 parsing algorithm will play back a compatible DOM does not mean that it is the DOM you need.

    Implementation in Opera
    Our old HTML parsing algorithm was based on what was written 15 years ago. It was constantly being added to keep up with the changing standards and many ways to not follow the specification. After all the changes, the code began to look like a repainted Christmas tree and adding new features became very difficult without knocking on the whole tree.

    With the decision to rewrite the parsing algorithm, it became possible to clear the entire design.

    Now we can proudly declare that the new Ragnarök parser passes the test for compliance with HTML5 specification based on html5lib, by 99.9%. The missing 0.1% will be realized by the time Ragnarök goes to gold. The whole set of tests will also be published and you can see for yourself everything, well, and indulge in various browsers.

    Ragnarök also scores 11 out of 11 (plus 2 bonus points) on a somewhat incomplete (and therefore misleading) html5test.com (two bonus points for embedded SVG and MathML in HTML5)

    Memory consumption
    The main reason that we have kept the old algorithm for so long is its efficient use of memory when working with poor markup. Instead of duplicating nodes as specified in the HTML5 specification, our algorithm had a complex system of pointers that determined which nodes should be duplicated. This saved him from unnecessary allocation of memory, however, and greatly complicated the entire code. Now we have switched to copying nodes, which requires a bit more RAM. Before the final release, we minimize this side effect, because Opera always cared about the efficient use of memory and work on small devices.

    Performance
    This is not obvious right now as it is a technical demo and it is not optimized for speed like releases, however this is another advantage for increasing productivity. Since the time for parsing HTML code is relatively short compared with rendering and page loading, the overall performance gain will not be so noticeable, but are all the performance improvements for the better?

    Grab it while hot!
    Download links above.

    Warning
    This is a technical demo and some things in it may not work, for example m2 has some problems.

    Leave your comments about the parser or errors here .

    Also popular now: