Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Markup validation of http://www.google.com

validator.w3.org

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Markup validation of http://www.google.com

#21

Post by GiraffeNecktie »

noguchi wrote: post #12

So if it's OK for Google to skip on standards, it's OK for the rest of us too. right?

It's OK for anyone to do anything they want with standards, you can ignore them or follow them at your pleasure.

Whether or not you decide to ignore standards - there may or may not be consequences. And if there are consequences, you still might have perfectly valid reasons for accepting those risks.

For a long time, arguably even till now, Microsoft didn't pay enough attention to web standards. They made a business decision for whatever reasons which is their perogative. One of the consequences is that they've lost a lot of browser market share. Whether that matters to them or not I don't know.

I suspect that Google balanced the benefits and harms of strict adherence to HTML and CSS standards and found that, for that page at least, it would be much worse to be anal about standards and the impact to the user, if they didn't meet the standards, would be pretty much nil.

Makes sense to me.

Re: Markup validation of http://www.google.com

#22

Post by rimantas »

ceejayoz wrote: post #11

Virtually all of those are "use CSS instead" or "use & instead of &". External CSS on Google's home page would mean billions of extra HTTP requests. Adding the amp; would mean terabytes of data transfer to fix something that works just fine in all browsers.

  Adding the amp; would mean terabytes of data transfer to
  fix something that works just fine in all browsers.
If thats the case even more can be saved by optimizing the current version. Don't be blinded by the fact that it is Google: the code clearly shows that it is this way because nobody cares, not because it was thought out very throughly. Point in case:
Could be just:
Even more, it could be just
because there is already .lst in CSS section, why not to specify attributes there?

Re: Markup validation of http://www.google.com

#23

Post by matth »

rimantas wrote: post #19
drivebyacct2 wrote: post #8

Google is well aware and proud of that fact. They cut their bandwidth in half by not validating. I was playing with jQuery in the dev console in Chrome yesterday on the Google homepage and realized that I was writing valid jQuery, but that $("body") simply didn't exist.

They cut their bandwidth in half by not validating. Care to elaborate on this bullshit about cutting bandwidth in half? I just want to remind you that quoting attributes and leaving out some tags is perfectly valid in HTML5 and HTML4.01. Even in strict. Converting their markup to the valid one would not be difficult, and they could even save some bandwidth. For example: drop those stupid attributes for body tag. drop…

I have to imagine that Google.com is the most bandwidth optimized page EVER.

Big picture, the W3C spec is not what matters here. What matters is making the same HTML document render exactly across different browsers. So maybe they could drop according to W3C, but does that break the document in other browsers?

My guess is that Google doesn't care about the W3C spec in this specific regard. What matters is delivering the smallest document possible that can be rendered by as many browsers as possible.

*Grammar edit.

Re: Markup validation of http://www.google.com

#24

Post by rimantas »

ceejayoz wrote: post #20
rimantas wrote: post #15

Earlier quoted context omitted.

Google might have their reasons to ignore the standards—but I very much doubt of their validity. E.g. all those bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 attributes onbody element. You may claim that these are intended to support the older browsers which have no CSS support. Well, dissable CSS and take a look at google.com to see how much water does this argument hold. And even if there ar…

> And even if there are valid reasons for invalid markup, there is no reason to have DOCTYPE of the actuall standard if you are not going to follow it. Sure there is. They want browsers to render the page with the latest standards support, even if they have a few trivial violations of that standard.

So sad to see you upvoted, it just shows how little people do know about how HTML, browsers and doctypes interact.

Browsers don't look at doctype and then choose what to support and what not: they will always try their best. See for yourself: http://kod.as/lab/html5/html32.html —that's HTML5 code with but with HTML3.2 doctype. Try it in modern browser, canvas still works.

Let me repeat: browsers will always try to render all they can on the page, no matter if that feature was or not in the version of HTML page claims to be. The only thing doctype affects is rendering mode. Any unknown doctype will trigger browsers to render the page in standards compliant mode. This feature is the reason why HTML5 has a doctype declaration at all. If you use XHTML5 (i.e. use xml markup and server your document with MIME application/xml+xhtml) you can omit doctype, because MIME type then tells browser which rendering mode to use.

Re: Markup validation of http://www.google.com

#25

Post by rimantas »

matth wrote: post #23
rimantas wrote: post #19

Earlier quoted context omitted.

They cut their bandwidth in half by not validating. Care to elaborate on this bullshit about cutting bandwidth in half? I just want to remind you that quoting attributes and leaving out some tags is perfectly valid in HTML5 and HTML4.01. Even in strict. Converting their markup to the valid one would not be difficult, and they could even save some bandwidth. For example: drop those stupid attributes for body tag. drop…

I have to imagine that Google.com is the most bandwidth optimized page EVER. Big picture, the W3C spec is not what matters here. What matters is making the same HTML document render exactly across different browsers. So maybe they could drop according to W3C, but does that break the document in other browsers? My guess is that Google doesn't care about the W3C spec in this specific regard. What matters is delivering…

  I have to imagine that Google.com is the most bandwidth
  optimized page EVER.
Sure it is not, because I can see how it can be optimized even more — and that's just at a glance.

  So maybe they could drop  according to W3C, but does that
  break the document in other browsers?
No it doesn't.

  My guess is that Google doesn't care about the W3C spec in this specific
  regard.
Ok, it is their call. Anyone is allowed not to care, but why put doctype of existing standard then. Just put or and be done with that.

Re: Markup validation of http://www.google.com

#26

Post by ceejayoz »

rimantas wrote: post #24
ceejayoz wrote: post #20

Earlier quoted context omitted.

> And even if there are valid reasons for invalid markup, there is no reason to have DOCTYPE of the actuall standard if you are not going to follow it. Sure there is. They want browsers to render the page with the latest standards support, even if they have a few trivial violations of that standard.

So sad to see you upvoted, it just shows how little people do know about how HTML, browsers and doctypes interact. Browsers don't look at doctype and then choose what to support and what not: they will always try their best. See for yourself: http://kod.as/lab/html5/html32.html —that's HTML5 code with but with HTML3.2 doctype. Try it in modern browser, canvas still works. Let me repeat: browsers will always try to re…

strong, b, i, and small tags had their semantic meanings changed in HTML5. Thus, a HTML5 doctype gives some information to browsers and search engines on how those tags should be interpreted.

Re: Markup validation of http://www.google.com

#27

Post by rimantas »

ceejayoz wrote: post #26
rimantas wrote: post #24

Earlier quoted context omitted.

So sad to see you upvoted, it just shows how little people do know about how HTML, browsers and doctypes interact. Browsers don't look at doctype and then choose what to support and what not: they will always try their best. See for yourself: http://kod.as/lab/html5/html32.html —that's HTML5 code with but with HTML3.2 doctype. Try it in modern browser, canvas still works. Let me repeat: browsers will always try to re…

strong, b, i, and small tags had their semantic meanings changed in HTML5. Thus, a HTML5 doctype gives some information to browsers and search engines on how those tags should be interpreted.

So, will you elaborate, how browsers will act differently upon encountering b, i and small?

Re: Markup validation of http://www.google.com

#28

Post by ceejayoz »

rimantas wrote: post #27
ceejayoz wrote: post #26

Earlier quoted context omitted.

strong, b, i, and small tags had their semantic meanings changed in HTML5. Thus, a HTML5 doctype gives some information to browsers and search engines on how those tags should be interpreted.

So, will you elaborate, how browsers will act differently upon encountering b, i and small?

Screen readers may treat small as optional text, as it's intended as the inline equivalent of the aside block-level tag. b and i are likely going to wind up having ramifications for how screen reading browsers apply emphasis, as they now have semantic instead of presentational meaning.
Post reply on HN