Live data from Hacker News

Mathematically optimal markup with HTML5

shinyplasticbag.posterous.com

11–20 of 28 posts

Re: Mathematically optimal markup with HTML5

#11
post #9
post #3

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…

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.

Re: Mathematically optimal markup with HTML5

#12
post #2

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

Go view the source of Google.com No or tags for one.

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).

Re: Mathematically optimal markup with HTML5

#13
post #3

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…

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.

Re: Mathematically optimal markup with HTML5

#14
post #9

Earlier quoted context omitted.

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'?)

Re: Mathematically optimal markup with HTML5

#16
post #15

I love how the author uses omitted- 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 , 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.

Re: Mathematically optimal markup with HTML5

#17
post #3

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…

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. :)

Re: Mathematically optimal markup with HTML5

#18
post #2

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

Go view the source of Google.com No or tags for one.

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.
Post reply on HN