Inperfect google

Zacariaz · Post by **Zacariaz** » Thu Oct 04, 2007 8:04 pm

just for the kicks of it, i took the source of www.google.com, and cleaned it up so it was readable, just to see how they did thing...

I was somewhat surprised. You should think that a company as big as google, which main atraction is their website, would make certain everything is in order...
That is most certainly not the case.

1. They havent even specifyed a doctype which is need by the browser, otherwise i wont know which standard to use.
2. I must assume that the code was writen by a script as the whole thing was in one line.
3. Imbedded css and far to many unneeded inline stylings.
4. lots of improper code that "might" work.
5. theres much more but my english vocabulary extents only so far.

Bottom line, how can this be happening? We have all seen the site, it is VERY simple and it would take very little time and effort to make things right. Google certainly have the recourses to do it properly.
Im confused.

Keep this in mind if you are ever gonna write a browser for your OS or something simular, google would probably not be best site to test it on...

Anyway, i intent to write an email to google, im just that kinda guy, but so far i have been unable to obtain an email address.

pcmattman · Post by **pcmattman** » Thu Oct 04, 2007 8:43 pm

There's a good reason: speed.

Zacariaz · Post by **Zacariaz** » Thu Oct 04, 2007 8:50 pm

pcmattman wrote:There's a good reason: speed.

Could you say that again? And if you honestly believe you are correct could you then explain it to me?

Very little work has to be done, and as i see it, speed is not a factor at all, nomatter how you define "speed".

pcmattman · Post by **pcmattman** » Thu Oct 04, 2007 9:05 pm

1. They havent even specifyed a doctype which is need by the browser, otherwise i wont know which standard to use.

They should really have a doctype, I'll give you that.

2. I must assume that the code was writen by a script as the whole thing was in one line.

Is there anything wrong with a script writing out a page? Saves editing time later as well.

3. Imbedded css and far to many unneeded inline stylings.

Embedded CSS is faster because the browser doesn't have to send another request for the CSS file. The inline styles may be required for compatibility some obscure browser or older browsers.

4. lots of improper code that "might" work.

Example?

Zacariaz · Post by **Zacariaz** » Thu Oct 04, 2007 10:25 pm

pcmattman wrote:
1. They havent even specifyed a doctype which is need by the browser, otherwise i wont know which standard to use.
They should really have a doctype, I'll give you that.

2. I must assume that the code was writen by a script as the whole thing was in one line.
Is there anything wrong with a script writing out a page? Saves editing time later as well.

Sorry i formulated that the wrong way. No, it is quite allright to use a script to generate the code, often there is really no way around it, but in this case it is just overkill and with unfortunant results. fx.
<tag thingy="37">
<tag thingy=37>
is obvious different, however tags of both form are found in the source, and that just plain weird.

pcmattman wrote:
3. Imbedded css and far to many unneeded inline stylings.
Embedded CSS is faster because the browser doesn't have to send another request for the CSS file. The inline styles may be required for compatibility some obscure browser or older browsers.

You are probably right regarding this embedding, but really, it shouldnt be nesacery to consider this, and regarding the inline stylings ill have to disagree, there are smarter way to these, probably non existing, problems.

pcmattman wrote:
4. lots of improper code that "might" work.
Example?

Nah, i dont want to go through the code again, but it is a fantastic example of "messy" and "inproper" code, the kinda code a newbie might come up with.
They use obsolete tags like <nobr> and use in large amount to structure things. They also use tables which you wouldnt expect.

Anyway, it shouldnt be very hard to convert it all to validating xhtml 1.0, even i could do it, the question is why google havent done it.
Remember that its probably the most visited site... ever...

pcmattman · Post by **pcmattman** » Thu Oct 04, 2007 10:28 pm

I'd say that it's not been cleaned up because "If it aint broke, don't fix it."

From a business perspective, there is no real reason to spend half an hour cleaning up the code. That half an hour could be used elsewhere on something more important.

Zacariaz · Post by **Zacariaz** » Thu Oct 04, 2007 10:35 pm

oh but this is only their simple page, as you know google is no longer just a search engine.
If they dont pull their act together sooner or later it will cause trouble. Maybe it allready does for some, who would know? there is no way to report it.

JamesM · Post by **JamesM** » Fri Oct 05, 2007 1:57 am

Do you expect divs and CSS to work on small-screen and embedded browsers?

Do you think one person wrote the entirety of the code for that page? No. And I guess they don't have coding standards covering tag format, which is why it's mismatched.

Zacariaz · Post by **Zacariaz** » Fri Oct 05, 2007 2:21 am

im not trying to prove anything here. It workes in my browser so couldnt care less.

But it be done so much better and it should, and it would take so little.

i simply dont understand it...

JamesM · Post by **JamesM** » Fri Oct 05, 2007 2:56 am

Read my post - It's all about browser compatability. Do you think they'd use deprecated tags like <nobr> if there wasn't a good reason? The point is that the majority of browsers out there (most are on embedded devices) do not support the latest standards, and on those that do many recieve suboptimal performance. Using tables means the complex CSS2 box model doesn't have to be adhered to. This is also the reason you don't see much Web2.0 crap on googles main pages, only on gmail etc.

Zacariaz · Post by **Zacariaz** » Fri Oct 05, 2007 3:03 am

yes of course browser compatability, but that is exactly why we have the standards.
admitet, xhtml 1.0 strict might not be the best way of doing thing for a site as whidely used as google, but there are older standard too.

And even google cant be expected to support 10 year old browsers.

JamesM · Post by **JamesM** » Fri Oct 05, 2007 3:06 am

I'm not talking about 10 year old browsers. I'm talking about modern embedded browsers running on a 50MHz ARM chip...

And as long as people are using 10 year old browsers, google will support them. It's a profit-making company, not a standards-enforcement agency.

Zacariaz · Post by **Zacariaz** » Fri Oct 05, 2007 3:17 am

You give good argument, but let give you (i think) a good counter argument.

What is one of the very first things you do when developing a browser?
I know what i would do, and it wouldnt be: just make it all up my self and hope that the rest of the world complies.

JamesM · Post by **JamesM** » Fri Oct 05, 2007 3:26 am

Low-power embedded chips just don't have the processing capacity to deal with CSS2. It all sounds great until someone hands you an ARM assembler, a test machine and an ARM assembly language manual!

Zacariaz · Post by **Zacariaz** » Fri Oct 05, 2007 3:34 am

JamesM wrote:Low-power embedded chips just don't have the processing capacity to deal with CSS2. It all sounds great until someone hands you an ARM assembler, a test machine and an ARM assembly language manual!

Who said that there would be any need for CSS2?

I actually have thought about investigating ARM as it seems to be the only hardware that meet my requirement regarding size, power consumption and prise, but i am uncertain as to where the limitations lie, not in how fast the cpu is, i believe i can affort something faster than 50mhz