Mathematically optimal markup with HTML5 | Hacker News Reader

Mathematically optimal markup with HTML5

shinyplasticbag.posterous.com

32 pointsmarkchristian26 comments

I hope that in determining which HTML is optimal bandwidith wise, there is also some consideration of what HTML is optimal rendering wise. (obvious cost savings of going hard down the bandwith optimizing aside)

Knowing how the parser treats certain constructs and deviations from the spec. probably gives us some insight into how long things will take to parse. Or is client side that much faster than waiting on normal network latency?

The parsing time is probably negligible. I would guess that parsing HTML5 would be a few if not dozens of megabytes per second on modern hardware.

Parsing speed depends on the markup. One example is text layout, which is O(N) in the size of the text area. So 1 MB of text might be a lot slower to parse than 1 MB of no-op tags.

I would not say text layout is done during parsing, it is done when the parse tree that parsing produced is used to produce a render tree ('execution time'?)

If you've seen Google's Chrome Fast ads where a potato rocket passes the length of a computer monitor slower than it takes to render a somewhat cluttered web page, that's loading from disk.

Honestly I was hoping this was going to be an article about optimal markup ordering and nesting for lightening quick rendering time and javascript event handling..

I'm curious if we will see actual packers that rename tags and rewrite css to drop markup size. HTML5 seems to make it easier to create your own tag soup. :)

I love how the author uses omitted-</p> as their example, when that's one of the things that was actually already defined in HTML4 and isn't a syntax error.

Yeah, I know that. Another random example is <li>, which doesn't require a closing tag. It was just included as an example. Finding a genuine example would require actually grokking the HTML5 parsing algorithm and starting to try to find optimizations.

I suppose some day I'll have to start writing my HTML to be read by machines, rather than humans. Right now I treat it like code: proper indentation, helpful comments, and the occasional hidden message for the reader.

Sure — I write my JavaScript that way, too. But when it's time to deploy to production, it gets packed.

If you write it, then surely you should be able to read it. Then you have a minifier convert it into non-human-readable form, if you like.

Except he doesn't write it. It's output from a program. Compilers don't emit readable output either.

I'm not saying I'm against clean HTML. But the argument you give is probably invalid.

  I suppose some day I'll have to start writing my HTML to be 
  read by machines, rather than humans.

I'm curious how you defend the assertion that you write HTML for humans. You write it on a computer, for other computers, with quite a lot of markup that humans are never going to see. For every ten thousand pageloads, how many people do you think are going to hit "view source?" Writing for "other humans" would be something like a document in a WYSIWYG editor, like Word.

The comparison to code is even more hilariously in-apt. A parser or a complier ignores the indentation and commenting when producing the final product.

I write my code and HTML to be read by a human because:

1. I may need to work on that code or page in the future,

2. Someone else may need to work on that page/code,

3. Some of that code may end up as open source,

4. I'm showing off to the 0.01% of people who view the source. I'd like everything I do to be of educational value to someone, somewhere, even if all they learn is how bad I am at writing compact HTML.

If I ever have any high-traffic sites, I'll most likely use a compacting system to shrink properly-indented templates and/or cached output from Ruby on Rails, rather than manually compact the HTML.

Interestingly, the HTML serialiser in html5lib[1] actually defaults to omitting omittable tags; I wanted a small script like htmltidy that used the HTML5 parsing algorithm, so I hooked up the html5lib parser and serialiser, and wound up with output even more chopped and cryptic than what I put in.

Luckily, setting the include-optional-tags option gave me much more readable output.

[1]: http://code.google.com/p/html5lib/

<sarcasm> Sure, let's just start to omit ending tags from HTML. Who cares about older browsers that will fail to properly render our sites. I'm sure that every business and user keeps their browsers up to date. </sarcasm>

Actually, the HTML5 parsing algorithm was derived by reverse engineering the existing browser parsers. It's pretty compatible.

Does anyone have more details or examples of Google's "crige-worthy" HTML for efficiency?

their home page

Go view the source of Google.com

No </body> or </html> tags for one.

Which is funny, because there are so many better ways for them to reduce the data transfer. They have colors specified in hex that could be reduced to shorthand and save 3 characters.

Example: <body bgcolor=#ffffff text=#000000 etc

They are also wasteful in their embedded styles:

Example: margin:3px 0 4px;margin-left:4px

Heck, they could even change the path to the images they include on the site to "img" or "i" instead of "images"

Or remove the "http:" from the urls they link to from the homepage. Though, I'm not sure if all UAs will handle this correctly. They should.

They can drop <html> and <body> too. Also, instead of <meta http-equiv="content-type" content="text/html; charset=UTF-8"> they could have <meta charset=utf-8> People often tell that Google squeezed every byte out of their markup, but it is far from the truth.

Those have been optional in every HTML DTD since 2.0 (the earliest I saw). It bugs me when everyone calls markup like this "invalid" when they actually mean it was browser authors who failed to follow the specs (in this case, SGML content model rules).

A friend of mine worked for Google when that was introduced and said it was purely a rendering speed optimization. Someone did some tests and found the page pops a little faster if you leave out those closing tags. I can't seem to find any articles on it but it seems more reasonable than trying to save a couple bytes, given the other markup that's been mentioned here.

Friend of mine did tests on this and found there is no significant performance difference in either direction. So dropping them is certainly worth it.

I have hard time understanding why browers' parsing algorithms should be standardized or why it's a good idea to do so. Shouldn't a language be defined declaratively using a grammar?

Reply on news.ycombinator.com