It’s just data

Live HTML5 Parser

Henri Sivonen: So without further ado, here’s Live DOM Viewer with an HTML5 parser running as JavaScript in your browser.

Wow!  Try:

<svg><path d=M0,0h100v100

I’m impressed by the speed.  I can definitely see myself tweaking, if not outright developing, the SVG images I create using this.  For example, try the following:

  <g transform=scale(1.5)>
  <image xlink:href= width=100 height="100"/>
  <g opacity=0.5>

  <path d="M38,38c0-12,24-15,23-2c0,9-16,13-16,23v7h11v-4c0-9,17-12,17-27c-2-22-45-22-45,3zM45,70h11v11h-11z" fill="#F00"/>
  <circle cx="50" cy="50" r="45" fill="none" stroke="#F00" stroke-width="10"/>

Note the quotes around the height attribute on the third line.  By the (still commented out) HTML5 SVG parsing rules, either they (or a space) are required here.

I can also see this being used in a comments live preview function.  A user can type in free-form markup, see the results, and when they click submit, what is sent to the server is a serialized DOM.

Neat, though it blew up when I innocently put a <body> tag in there.  With the DOCTYPE declaration it appears to want you to put the full markup in there, but it apparently prepopulates <head> and <body>.

Posted by anonymous at

It is very cool, and fast.

anonyous: “With the DOCTYPE declaration it appears to want you to put the full markup in there, but it apparently prepopulates <head> and <body>”

The DOM viewer shows the body element, so yeah that would be given. Your point is good, though, that a note to that effect at the bottom wouldn’t be amiss.

Posted by Shelley at

How did it “blow up”? Note that the <html>, <body>, <head>, </html>, </body> and </head> tags are optional in HTML5 (and in HTML 4) but the elements are not, so the parser infers the elements if the tags are omitted. That is, regardless of input, the DOM always gets html, head and body nodes.

You can try your browser’s own parser using the original Live DOM Viewer. The the DOM always gets html, head and body nodes there, too.

(Character reference parsing in attribute values had a pretty serious bug. Now fixed.)

Posted by Henri Sivonen at

HTML5 Live DOM Validator

Henri Sivonon has taken Hixie’s Live DOM Viewer, and is now running the HTML Parser within it, using GWT 1.5 RC2, which fixed a bug to do with JavaScript in hosted mode. Simply open the tool and put in some markup and see the puppy run....

Excerpt from Ajaxian » Front Page at

“blow up” is too strong a term.  The underlying script goes into some sort of loop and causes the “Unresponsive Script” dialog to appear.  This is in Firefox 3.0.1 by the way.

I just tried it again and got the same issue:

I typed:


As soon as the final “>” bracket is typed the window freezes and the “unresponsive dialog” appears.

Posted by anonymous at

The Unresponsive Script issues on </body> is now fixed. It appears that GWT 1.5 RC2 still has a variant of the previous compiler bug left. (The “fix” was that I added stuff that does nothing but the compiler can’t prove does nothing, so it can’t be optimized away. This way an important line immediately after doesn’t get wrongly optimized away.)

Posted by Henri Sivonen at

Add your comment