homepage Welcome to WebmasterWorld Guest from 54.227.20.250
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

This 51 message thread spans 2 pages: < < 51 ( 1 [2]     
Google Home Page has 67 Validation Errors!
What gives?
pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 4:16 pm on Feb 6, 2007 (gmt 0)

How can a page like www.google.com which contains a total of 13,805 bytes of information have 67 html errors? I just don't understand that. I can see a few here and there, but not 67, especially in relation to the minimal amount of code.

How can we expect Webmasters to take code quality seriously if the leader in search doesn't?

Hey Google, www.msn.com validates XHTML 1.0 Strict. And, www.msn.com weighs in at a whopping 231,558 bytes.

A challenge? Up for it? Wanna start some buzz and clean up a part of the web at the same time?

 

g1smd

WebmasterWorld Senior Member g1smd us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 5:41 pm on Feb 8, 2007 (gmt 0)

>> There is a difference between writing broken code, which doesn't validate, and working code that doesn't validate. I think that we can all agree that the first is bad. <<

Yes! But until you actually run your page through [validator.w3.org...] and see exactly what type of errors you do have, you will never know about the fatal traps that you might have unwittingly put into your code.

>> You have to remember the bytes for the additional file request <<

However, with external CSS the style file is served once per visitor, not once per page view. So first page is slower and subsequent pages are faster... overall, a win.

BigDave

WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 6:20 pm on Feb 8, 2007 (gmt 0)

However, with external CSS the style file is served once per visitor, not once per page view.

Served, yes, requested, no. The css file is requested EVERY pageview and the page is not rendered until it is returned either returned or it returns that status that it is not changed. Depending how things are set up, there might have to be a whole new negotiation of the connection. If you want a fast service, for small pages served to slow dialups, and you have a small amount of style code, you put it in the header.

Small packet network traffic is expensive in overhead.

BigDave

WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 6:26 pm on Feb 8, 2007 (gmt 0)

Yes! But until you actually run your page through [validator.w3.org...] and see exactly what type of errors you do have, you will never know about the fatal traps that you might have unwittingly put into your code.

Not completely true. There are other ways to produce non-broken non-validating code.

You can also look at the "errors" and decide to only fix those that are fatal.

In Google's home page case, they know that it does not break browsers because it is served millions of times a day with no complaints that it broke a common browser. They also aren't that concerned with how it will rank in Google or other search engines, so any "broken" code that causes spider problems simply doesn't matter. It works everywhere that it is expected to work, so it is validated by use and is not broken.

youfoundjake

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 3244244 posted 12:32 am on Feb 9, 2007 (gmt 0)

On a side note: http://www.example.com/ does not validate either, but it only has 1 error, no doctype, and yes the domain is w w w . e x a m p l e . c o m
Mods have not unspecified the url. :)

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 8:33 pm on Feb 9, 2007 (gmt 0)

Why do so many seem to think that validation is just about providing a geek with a sense of acknowledgement?

Benefits of validating:
- You know your markup is formed the way it should. If things don't display right, at least it's not due to amateur coding.
- Time saving. Writing valid code is easier and faster than writing -- what did you call it again -- "working code that doesn't validate" due to the fact that certain instances of invalid code works in one browser, but not the other.
- Reduce code bloat. Yes, reduce it! The validator tells you about all those stupid attributes you keep repeating over and over. Yank them, and put a one-line replacement in your CSS file.
- Reduce redesign time. Whenever the site is up for a redesign the effort will be significantly reduced. Staying up-to-date with standards and browsers' rendering thereof is also significantly simplified.
- Ever up for usability requirements? If such requirements are enforced by law, you have no choice but to validate, as valid markup is an absolute must for passing usability and accessibility requirements.
- Cross-browser functionality and rendering maintained. It is much easier to achieve a cross-browser environment -- whether we're talking functionality, design, whatever -- if your pages validate. It's always better to rely on whatever few standards the browser makers have already agreed upon than hoping that their error handling procedures produce the same result.
- Yes, you get that geeky sense of acknowledgement ...

Drawbacks of validating:
- Validation is not for the amateur. It takes a professional mindset to be able to efficiently write valid code from scratch. Hey, you have to know the standard in order to conform to it.
- Increased page size. Unfortunately, depending on the type of page you are working with, the valid version may indeed be a few bytes bigger than the invalid. Then again, it is entirely possible for you to experience quite the opposite result.
- False sense of security. All too many think that just because their site validates, they do not need to test it in different browsers. This assumption is entirely wrong. While valid code eliminates certain rendering problems you may otherwise have experienced, old browsers lack the stability and dependability that new browsers offer. However, as more and more browsers become standards compliant (and that is the trend), the need for endless testing over and over again is slowly turned into more rudimentary testing.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 8:55 pm on Feb 9, 2007 (gmt 0)

So, I just created a validating version of the Google homepage ... Same look and all, but hundreds of bytes smaller.

So far:
Current homepage -- 4665 bytes
My modified page -- 4325 bytes

... and I'm not even done yet.

[edited by: DrDoc at 9:15 pm (utc) on Feb. 9, 2007]

BigDave

WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 10:45 pm on Feb 9, 2007 (gmt 0)

DrDoc,

When you say "validating" are you using it as a verb or a verbal noun?

If you mean running the page through a validation tool, I can certainly agree that it can be a useful tool when it comes to finding problems.

If you mean that having a page that validates as a goal, then I disagree.

A page that passes validation is no guarantee that the page will render correctly, it just means that you meet a spec.

I feel the same way about validating (verb) HTML as I do about checking the list of warnings that a compiler spews out. As a thinking person that knows the specs, what I intended when coding, and what shortcuts that I chose to take, I will then look at the output and decide what needs fixing and what I choose to leave as it is.

Sometimes when I code, I really do mean
if (y = x) {
instead of
if (y == x) {
even if the compiler thinks I need a warning.

And there are times when a <font> tag is more expedient for one-off situations than using CSS.

I would love for you to point out a browser that gags on the number "2" as an attribute value if it is not quoted. Each of those calls in an interpreter to translate every \" inside my quoted strings add up. Why slow down your server any more than necessary on a heavily loaded system? Not to mention that it is extra work, just to pass validation.

Passing validation should not, in itself, be a goal. The goal is working HTML code.

pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 10:56 pm on Feb 9, 2007 (gmt 0)

And there are times when a <font> tag is more expedient for one-off situations than using CSS.

Oh, that's sacrilege! The <font> tag is an absolute no-no in any design. At least from my perspective. The <font> element has been deprecated for years. That's like browsing the web with IE4, NN4, etc. ;)

pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 11:04 pm on Feb 9, 2007 (gmt 0)

A page that passes validation is no guarantee that the page will render correctly, it just means that you meet a spec.

DrDoc's response...

You know your markup is formed the way it should. If things don't display right, at least it's not due to amateur coding.

BigDave...

Passing validation should not, in itself, be a goal. The goal is working HTML code.

I kind of look at it the opposite way, validation is a goal (and a lofty one with some sites). Once validation has been achieved, now comes the testing. As DrDoc stated above, validating your code to a standard at least gives you the comfort in knowing that it is not your code that is breaking the page if and when that happens.

I know that ever since I took the W3C pill, there have been few if any major issues to contend with. ;)

BigDave

WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 11:26 pm on Feb 9, 2007 (gmt 0)

That's like browsing the web with IE4, NN4, etc.

I keep a copy of netscape 3.1 around, and use it on a semi-regular basis, including making sure that newer features on some of my sites degrade to a website that is still usable.

The thing about <font> being depreciated is that the ONLY place that it was depreciated was in the spec. It isn't depreciated in the browsers, and it isn't depreciated on the web. There were several things that were depreciated that were virtually never used, and that's fine, but depreciating something that is in common usage and will remain in documents in daily use for decades to come, was just plain stupid.

<font> was not broken, it worked just fine and continues to work just fine. It isn't like when C changed from using "=-" to "-=" (yes, I'm that old) because of the problem of assigning a negative number. There was a reason to change how the compiler worked because it broke the "white space doesn't matter" ideal behind the language.

If it ain't broke, and it is commonly used, don't depreciate.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 11:39 pm on Feb 9, 2007 (gmt 0)

A page that passes validation is no guarantee that the page will render correctly, it just means that you meet a spec.

Neither is any amount of testing any guarantee that the page will render correctly. However, a page that validates is more likely to render correctly.

As I already stated:

It's always better to rely on whatever few standards the browser makers have already agreed upon than hoping that their error handling procedures produce the same result.

BigDave

WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 12:37 am on Feb 10, 2007 (gmt 0)

But you are mistaken when you call them "error handling procedures" in all cases when a page does not validate.

There are errors that are handled, such as having one slash rather than two after the http: or forgetting the colon. There are missing tag closures or ones that are imprope4rly nested. Those are errors that need to be handled. That is where using the validator as a tool can be a good thing, as long as you understand what you are fixing.

But there are things that are not an error. They are not an error because the history of the web itself does not consider it an error. It would be an error on the part of a programmer to violate that history by treating it as an error.

If a browser was written strictly to the specs, it would be considered a broken browser. It would also be a wateful and stupid way to write the code. You write the code to deal with every possible tag from any HTML spec, from the first infomal document up to the present. Then you only add the conditionals to the few that tags that differ in the way they work between versions. If you want to add something from HTML 3.0 to an HTML 2.0 doc, it would take some badly designed rendering code to even notice.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3244244 posted 2:09 am on Feb 10, 2007 (gmt 0)

BigDave, I hear you :) And yes, you are making some important points. But that doesn't mean that the comments about validation aren't important too. The way I see the validation process is that it always helps to improve the resulting markup, it makes testing easier, and improves understanding from the developer standpoint of how the markup is functioning beneath the surface.

Yes, there are errors which are more important than others. The biggest issues include: actual typos (missing quotes or brackets for example) - this kind of error can very often be critical in that it can seriously mess with your page rendering and indexation (and subsequent ranking). Another big error is improper nesting: although browsers handle it reasonably well, it adds a great deal of complication into the parsing of the page - see this article for example:

  • Tag Soup: How UAs handle <x> <y> </x> </y> [ln.hixie.ch] (from a Google employee, no less)

    We can theoretically test how common browser handle improper nesting, but we can't test how Googlebot does, or how the page will work in future browsers. It's an unnecessary risk. Browsers handle valid and/or well-formed markup in a very similar way. When the markup is badly-formed, then methods vary wildly between user agents on how the broken markup is handled.

    I'm very easy on what actual standard is followed, however - I would agree that well-formed documents conforming to a reasonable extent to a loose standard such as HTML 4.01 Transitional (in quirks mode even) is acceptable as a robust and working framework. There's no place for extremism, and I don't think that's what is being proposed by anyone here.

    It is hard for big sites to stay 100% valid (especially to a strict standard) with legacy code, third-party code, user-generated content, etc. I'm not even against font tags - although using font face is problematic, using size isn't. I'm not even worried if the doctype is absent, as long as the markup is verified, consistent, error-free and well-formed.

    Back to the actual case in hand. Google can justify using a table or even a font or two if there is a specific need, but I get the impression that it is much more a case of inertia than pure intention. The sheer complexity and the number of iterations of that particular page is stupendous, and any modification would engage them in a very complex testing process. The font elements are there probably because they always were.

  • BigDave

    WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



     
    Msg#: 3244244 posted 2:37 am on Feb 10, 2007 (gmt 0)

    But that doesn't mean that the comments about validation aren't important too.

    I agree, as long as they thoughtful about the act of validating and they aren't about the religion of validation.

    but we can't test how Googlebot does

    From a programmer's perspective, I can tell you with almost complete certainty how Googlebot handles it. In 98% of the cases, it doesn't care, because it treats the vast majority of tags like comments.

    Goggle only cares about a few tags, and the most sensible way to deal with the rest of them is simpl ignore everything between "<" and ">". Title, a, h# are all important. Div, span, p, center, are just noise to be ignored. If the broken nesting has to do with ignored tags, there should not be a problem.

    Back to the actual case in hand. Google can justify using a table or even a font or two if there is a specific need, but I get the impression that it is much more a case of inertia than pure intention.

    Agreed. It is a case of "if it ain't broke, don't fix it."

    [edited by: BigDave at 2:39 am (utc) on Feb. 10, 2007]

    pageoneresults

    WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



     
    Msg#: 3244244 posted 6:04 pm on Feb 10, 2007 (gmt 0)

    What if, and this is a big what if, Google were to validate their core pages? What kind of message would that send to the Webmaster Community? What kind of buzz would it generate for Google from the tech side?

    BigDave

    WebmasterWorld Senior Member bigdave us a WebmasterWorld Top Contributor of All Time 10+ Year Member



     
    Msg#: 3244244 posted 6:40 pm on Feb 10, 2007 (gmt 0)

    About the only effect that I would expect is that these threads would disappear. Some of you might take it to mean more, but since most webmasters don't know about validating their sites, much less that Google's pages don't validate, it is unlikely to make any difference in the grand scheme of things.

    Adam_Lasnik

    5+ Year Member



     
    Msg#: 3244244 posted 12:31 am on Feb 14, 2007 (gmt 0)

    I think validation tools can be useful, but are far from the end-all-be-all of site quality evaluations or Google rankings.

    More specifically, I can tell you what Google cares about in this context for our own site and the sites our Googlebot looks at (beyond the obvious importance/relevance concerns for a given query):

    1) Is it readable?
    *All Flash* sites are not readable by our Googlebot, nor are they readable by various browsers or people, for instance.

    2) Is it following our Webmaster Guidelines?

    Flippance aside, I would be interested if anyone has any evidence where non W3C validation has actually resulted in ranking problems.

    Validation errors from W3C, in and of themselves -- unless they are so material as to hamper our hardy Googlebot's reading of the site -- are extremely unlikely to harm a site's presence in our index. Looking at an extreme:

    <titleCritical Airport Parking Regulations <body>The red zone is for immediate loading and unloading of passengers only. There is no stopping in a white zone.

    ...as you can guess, we're probably going to have a hard time discerning the title of this page. But you don't need a validation tool, I'd hope, to notice that ;-).

    Therefore, when reviewing your own site or others' sites, I'd use validation tools as but one of *many* tools in your arsenal. Note that I certainly don't mean to denigrate the values of W3C validation; rather, I'm saying that in the context of Google crawling and indexing, this stuff shouldn't be a critical consideration.

    g1smd

    WebmasterWorld Senior Member g1smd us a WebmasterWorld Top Contributor of All Time 10+ Year Member



     
    Msg#: 3244244 posted 8:25 am on Feb 15, 2007 (gmt 0)

    There are several million pages with just those types of errors, so many people don't notice those...

    I like to run a page through a validator just as a sanity check. It often finds code typos that i have missed.

    macman23

    5+ Year Member



     
    Msg#: 3244244 posted 5:44 am on Feb 17, 2007 (gmt 0)

    Thanks Adam,

    One more variable checked off the list... ;-)

    KenB

    WebmasterWorld Senior Member 10+ Year Member



     
    Msg#: 3244244 posted 2:55 pm on Feb 17, 2007 (gmt 0)

    <quote>If you put <b> into an html 4 or xhtml document, it will not validate. But it will work on every browser that anyone uses and it will work on any browser for the foreseeable future.

    On the other hand, I used a popular theme with a CMS that is xhtml compliant and all the pages validated perfectly. It looked great on firefox, mozilla and opera. In IE it produced a page, that was incredibly difficult to read.</quote>

    99%+ of XHTML websites should actually be using HTML4.01 instead. MSIE does not support XHTML and never will. In fact XHTML is an evolutionary dead end and work is currently being done on what will eventually become HTML5.

    This issue has been discussed on many forums across the web including here at Webmaster World. See:
    [webmasterworld.com...]
    Also do a Google search for "Sending XHTML as text/html Considered Harmful" by Ian Hickson.

    <quote.Give me thoroughly tested over validated any day.</quote>
    One can not claim having thoroughly tested a site/page without validating the HTML and CSS. As others have pointed out, validating the code helps root out stray syntax and nesting errors that can produce unexpected results in various browsers or browser configurations. Validating the code doesn't replace browser testing any more than browser testing replaces validating code. They BOTH are a very important part of the process. As others have pointed out, producing valid code greatly simplifies the browser testing process.

    Some sections of my primary site has some very challenging layout and design considerations. Without making sure my HTML and CSS validates (with no errors/warnings) there is no way I could be certain specific browser rendering issues weren't the result of bad code as opposed to the way the browser implemented HTML and CSS specifications.

    trinorthlighting

    WebmasterWorld Senior Member 5+ Year Member



     
    Msg#: 3244244 posted 3:28 pm on Feb 17, 2007 (gmt 0)

    Dr Doc,

    300 bytes eh? Whats that times a few million queries a day? Geez, that could save a big load on googles servers...

    Come on google, you want to be seen as the standard on the web so set the standard..... Lead by example, right?

    This 51 message thread spans 2 pages: < < 51 ( 1 [2]
    Global Options:
     top home search open messages active posts  
     

    Home / Forums Index / Google / Google SEO News and Discussion
    rss feed

    All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
    Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
    WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
    © Webmaster World 1996-2014 all rights reserved