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.
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?
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 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.
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.
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.
<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>
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.
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?
27 comments
[ 3.0 ms ] story [ 65.8 ms ] threadNo </body> or </html> tags for one.
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.
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?
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'm not saying I'm against clean HTML. But the argument you give is probably invalid.
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.
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.
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
http://✂.ws/yX
Luckily, setting the include-optional-tags option gave me much more readable output.
[1]: http://code.google.com/p/html5lib/