valid_sites_work_better.html 47 KB

Raw Blame History Permalink

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <style type="text/css" media="all">
    @import "/QA/2006/01/blogstyle.css";
    </style>
    <meta name="keywords" content='authoring, html, standard, valid, validator' />
    <meta name="description" content="I learned to write standard-compliant Web pages when the likely alternative was “the browser will likely crash on your tag soup”. In an age of graceful error recovery, does it still matter to produce valid code? Share your stories here." />
    <meta name="revision" content="$Id: valid_sites_work_better.html,v 1.67 2011/12/05 17:18:25 mirror Exp $" />
   <link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.w3.org/QA/atom.xml" />
   <link rel="alternate" type="application/rss+xml" title="RSS 1.0" href="http://www.w3.org/QA/news.rss" />
   <title>Valid sites work better(?) - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2009/01/javascript_required_for_basic.html" title="JavaScript required for basic textual info? TRY AGAIN" />
   <link rel="next" href="http://www.w3.org/QA/2009/02/social_networking_workshop_rep.html" title="Social Networking Workshop Report" />

   <!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="http://www.w3.org/QA/2009/01/valid_sites_work_better.html"
    trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/257"
    dc:title="Valid sites work better(?)"
    dc:identifier="http://www.w3.org/QA/2009/01/valid_sites_work_better.html"
    dc:subject="Opinions &amp; Editorial"
    dc:description="I learned to write standard-compliant Web pages when the likely alternative was “the browser will likely crash on your tag soup”. In an age of graceful error recovery, does it still matter to produce valid code? Share your stories here."
    dc:creator="olivier Théreaux"
    dc:date="2009-01-29T21:26:11+00:00" />
</rdf:RDF>
-->

    <!-- <script type="text/javascript" src="http://www.w3.org/QA/mt.js"></script>-->

</head>
<body class="layout-one-column">
      <div id="banner">
      <h1 id="title">
	<a href="http://www.w3.org/"><img height="48" alt="W3C" id="logo" src="http://www.w3.org/Icons/WWW/w3c_home_nb" /></a>
W3C Blog
</h1>
    </div>

    <ul class="navbar" id="menu">
        <li><strong><a href="/QA/" title="W3C Blog Home">[ W3C Blog ]</a></strong></li>
        <li><a href="/QA/Library/" title="Documents and Publications on Web and Quality">Documents</a></li>
        <li><a href="/QA/Tools/" accesskey="3" title="Validators and other Tools">Tools</a></li>
        <li><a href="/2007/12/qa-blog-help/index#feedback">Feedback</a></li>
    </ul>
<div id="searchbox">
<form method="get" action="http://www.google.com/custom" enctype="application/x-www-form-urlencoded">
<p id="formbox"><input type="text" size="15" class="textfield" name="q" accesskey="E" maxlength="255" /> <input type="submit" class="submitfield" value="Search" id="goButton" name="sa" accesskey="G" /> <input type="hidden" name="cof" value="T:black;LW:72;ALC:#ff3300;L:http://www.w3.org/Icons/w3c_home;LC:#000099;LH:48;BGC:white;AH:left;VLC:#660066;GL:0;AWFID:0b9847e42caf283e;" /><input type="hidden" id="searchW3C" name="sitesearch" checked="checked" value="www.w3.org/QA" /><input type="hidden" name="domains" value="www.w3.org/QA" /></p>
</form>
</div>


    <div id="main"><!-- This DIV encapsulates everything in this page - necessary for the positioning -->

                     <p class="content-nav">
                        <a href="http://www.w3.org/QA/2009/01/javascript_required_for_basic.html">&laquo; JavaScript required for basic textual info? TRY AGAIN</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2009/02/social_networking_workshop_rep.html">Social Networking Workshop Report &raquo;</a>
                     </p>

                        <h2 class="entry-header">Valid sites work better(?)</h2>
                           <div class="entry-body">
                              <p>I learned HTML at a time when some people were still building several versions of their site. I'm not talking about the web, mobile and iphone versions – more like the netscape and IE3 versions. That was a time when writing “standard” HTML was still a fairly novel idea, but a powerful one. It made sense: the alternative was “write standard code or risk having browsers crash miserably on your web page”.</p>

<p>That was more than a decade ago. Browsers, meanwhile, have made incredible progress at gracefully rendering even the most broken web page. And that is a good thing.</p>

<p>Does this make validation and quality checking of Web pages moot? Of course not. There are many more incentives to build great standard-compliant websites: ease of maintenance, show of professionalism, or, in the words of <a href="http://twitter.com/zeldman/status/1137456194">Zeldman</a>, <q cite="http://twitter.com/zeldman/status/1137456194">Client who saves $5,000 buying cut-rate non-semantic HTML will later spend $25,000 on SEO consultant to compensate</q>.</p>

<p>It makes me curious, however, to know what are the real-life arguments in favor of valid, standard code today. Do you have an untold story of validation getting you rid of an awful rendering glitch? Real-life accounts of a search engine bump achieved by fixing the syntax of you HTML <code>&lt;head&gt;</code>? A typo in a CSS stylesheet that hours of glancing at code didn't show, but the validator did? A forgotten <code>alt</code> that would have lowered your search rank for an important keyword, or cost a big fee for non-accessibility?</p>

<p>Use the comments below to share and discuss your experience - we'll update our outdated “<a href="http://validator.w3.org/docs/why.html" title="Why Validate?">Why Validate?</a>” doc with the best examples.</p>
                           </div>
                           <div id="more" class="entry-more">

                           </div>
                       <p class="postinfo">Filed by <a href="http://www.w3.org/People/olivier/">olivier Théreaux</a> on January 29, 2009  9:26 PM in <a href="http://www.w3.org/QA/archive/technology/css/">CSS</a>, <a href="http://www.w3.org/QA/archive/technology/html/">HTML</a>, <a href="http://www.w3.org/QA/archive/web_spotting/opinions_editorial/">Opinions &amp;amp; Editorial</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2009/01/valid_sites_work_better.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2009/01/valid_sites_work_better.html#comments">Comments (34)</a>
                                 | <a href="http://www.w3.org/QA/2009/01/valid_sites_work_better.html#trackback">TrackBacks (0)</a>
</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-172767">
<p class="comment-meta" id="c172767">
<span class="comment-meta-author"><strong>Shelley </strong></span>
<span class="comment-meta-date"><a href="#c172767">#</a> 2009-01-29</span>
</p>
<div class="comment-bulk">
<p>Why do I ensure my pages are valid? Because I serve my pages as application/xhtml+xml and a kitten is drop kicked every time the Yellow Screen of Death displays. </p>

</div>
</div>


<div class="comment" id="comment-172768">
<p class="comment-meta" id="c172768">
<span class="comment-meta-author"><strong>Patrick H. Lauke </strong></span>
<span class="comment-meta-date"><a href="#c172768">#</a> 2009-01-29</span>
</p>
<div class="comment-bulk">
<p>not a "i validated my pages and came top on google" story, but i can't even count the times anymore when people at work have asked me in desperation why their pages just seem broken or why their css just doesn't seem to do what it's supposed to, and the root cause of the problem turned out to be invalid html. as a rule now i don't troubleshoot any css / layout issues anymore unless i know that at least the markup that's being styled, as well as the css of course, is valid. saves hour in troubleshooting or working around different browsers' error-handling and compensation approaches that kick in when presented with broken code.</p>

<p>actually, to expand on the markup part: it's not so much making sure that it's valid, but rather that it's well-formed (or, to use old wcag 2 parlance, that it can be "parsed unambiguously")...but certainly having pages that also validate is a sign of good QA, unless there's a good reason for not validating (use of non-standard, but otherwise harmless, attributes as scripting hooks, or a shoddy CMS/backend/aggregator that doesn't properly escape ampersands and such).</p>

</div>
</div>


<div class="comment" id="comment-172771">
<p class="comment-meta" id="c172771">
<span class="comment-meta-author"><strong>Karl </strong></span>
<span class="comment-meta-date"><a href="#c172771">#</a> 2009-01-30</span>
</p>
<div class="comment-bulk">
<p>I tried to avoid to use the Markup validator. I considered it a last chance tool. But to me more precise…</p>

<ol>
<li>write my file as xhtml 1.1 <em>and</em> give ".xhtml" for the extension. This helps to discover right away if the file is well-formed.</li>
<li>Work <em>only</em> in utf-8</li>
<li>Not using any named or numerical entities for special characters, except the reserved ones. </li>
<li>have a local Web server for development (before syncing on the prod server) where I have the Markup Validator and the LogValidator. The shorter the feedback loop is, the better chances to find and fix the mistakes.</li>
<li>When the Web page is created on the fly through a process of scripts and html chunks coming from many sources, create units of codes to check before the inclusion. </li>
</ol>

<p>Local installation of the validators is a bit painful… but you do not do it often. You can use them offline, on resources which have confidential content, not being victims of any network outages, and you can combine with a local install of the LogValidator.</p>

<p>… and with all of that you save kittens.</p>

</div>
</div>


<div class="comment" id="comment-172775">
<p class="comment-meta" id="c172775">
<span class="comment-meta-author"><strong>Jens Meiert </strong></span>
<span class="comment-meta-date"><a href="#c172775">#</a> 2009-01-30</span>
</p>
<div class="comment-bulk">
<p>There are two great things about validation: <em>Validating supports and accelerates learning</em>, so it contributes to awareness of respective specifications, and releasing formally <em>valid code is a sign of professionalism</em>.</p>

<p>Put another way, developers not validating most likely learn slower, and invalid code can <a href="http://meiert.com/en/blog/20080616/validation-unimportant/" rel="nofollow">in truly the most cases</a> be considered unprofessional.</p>

<p>However, invalid code doesn't have to mean inaccessible or unmaintainable code. <a href="http://twitter.com/j9t/status/1161128390" rel="nofollow">That's a myth.</a> You can inverse that statement too though: Valid code does not – by far not – mean accessible or maintainable code, or even efficient yet fast code. The guys stating that are wrong or having different motives, as the advantages and great things about validation are, see above.</p>

</div>
</div>


<div class="comment" id="comment-172776">
<p class="comment-meta" id="c172776">
<span class="comment-meta-author"><strong>olivier Théreaux <a class="commenter-profile" href="http://www.w3.org/People/olivier/"><img alt="Author Profile Page" src="http://www.w3.org/QA/sununga/mt-static/images/comment/mt_logo.png" width="16" height="16" /></a></strong></span>
<span class="comment-meta-date"><a href="#c172776">#</a> 2009-01-30</span>
</p>
<div class="comment-bulk">
<p>Jens, I'll take the liberty to quote <a href="http://meiert.com/en/blog/20080616/validation-unimportant/">another of your blog posts</a> here. </p>

<blockquote><p>Validation becomes unimportant once you’re ahead of the game, and <em>not a second earlier</em>. Even then, truly <em>mastering</em> HTML and CSS, it will usually be best to stick with valid markup and styling, but fighting latency might then mean a by all means legitimate reason to stretch a little bit.</p></blockquote>

</div>
</div>


<div class="comment" id="comment-172777">
<p class="comment-meta" id="c172777">
<span class="comment-meta-author"><strong>Nathanael Ritz </strong></span>
<span class="comment-meta-date"><a href="#c172777">#</a> 2009-01-30</span>
</p>
<div class="comment-bulk">
<p>Coding with XHTML 1.0 strict, a reset css file and making sure it's all valid is a great way to ensure that the website I build will look the same way on IE 6 and pretty much any browser published after that point.</p>

<p>As soon as I don't bother using valid code, certain browsers gracefully handle the problem... but usually one browser will end up doing something wacky (they call it quirks mode for a reason!).</p>

<p>I don't like wacky unless I styled it that way :)</p>

</div>
</div>


<div class="comment" id="comment-172779">
<p class="comment-meta" id="c172779">
<span class="comment-meta-author"><strong>Dani Iswara </strong></span>
<span class="comment-meta-date"><a href="#c172779">#</a> 2009-01-31</span>
</p>
<div class="comment-bulk">
<p>Even not a web designer nor developer, but validator is there to tell me if something go wrong with my web presentation.
Then I can fix the specific problem faster and it should be  standard-compliant. Easier for web maintenance and development.</p>

</div>
</div>


<div class="comment" id="comment-172781">
<p class="comment-meta" id="c172781">
<span class="comment-meta-author"><strong>Laura </strong></span>
<span class="comment-meta-date"><a href="#c172781">#</a> 2009-01-31</span>
</p>
<div class="comment-bulk">
<p>Validators create a teachable moment. A moment of great opportunity.  A time to educate. A time to get action. A time to get people to actually fix their pages. Flagging errors and giving warnings is a very good thing indeed.</p>

<p>The W3C HTML/XHTML validator is currently used as a web accessibility teaching tool. For instance, I have my students use it in the accessibility classes that I teach to flag missing alt attributes. One of their first lessons is to validate HTML on the W3C site to ensure that it is error-free and that they have indeed examined each image. It makes a BIG impression that text alternatives are mandatory not just for WCAG but as well for valid HTML4 and XHTML. It is an undeniable advertisement that it is needed. It is a <em>first</em> step in getting that vital message across. </p>

<p>The W3C CSS and (X)HTML validators are also used in lessons to help teach how to debug CSS. Many cases of "it works in one browser but not another" are caused by silly author errors. Typos and wrong syntax can cause different problems in different browsers. Small mistakes may be difficult for students to spot in their own code, but the validator excels at pinpointing  them immediately. If a person uses syntax in their CSS or (X)HTML, which is not correct, there is a far greater chance that style sheets won't work as expected. Any number of strange behaviors can be triggered in various browsers if there are syntax errors. Validation isn't a magic bullet that will automatically solve all problems. But validating pages helps eliminate many which leaves a more manageable subset to address.</p>

<p>The W3C validators do far more than the specifications themselves to educate and increase the quality of HTML documents on the web. They are indispensable for student learning. Thank you for providing theses vital tools.</p>

</div>
</div>


<div class="comment" id="comment-172790">
<p class="comment-meta" id="c172790">
<span class="comment-meta-author"><strong>charlie </strong></span>
<span class="comment-meta-date"><a href="#c172790">#</a> 2009-02-01</span>
</p>
<div class="comment-bulk">
<p>Are there actually real-life arguments in favor of non-valid code?</p>

</div>
</div>


<div class="comment" id="comment-172791">
<p class="comment-meta" id="c172791">
<span class="comment-meta-author"><strong>Amir </strong></span>
<span class="comment-meta-date"><a href="#c172791">#</a> 2009-02-01</span>
</p>
<div class="comment-bulk">
<p>Hi,
What is HTML's logo/icon?</p>

</div>
</div>


<div class="comment" id="comment-172872">
<p class="comment-meta" id="c172872">
<span class="comment-meta-author"><strong>Tim </strong></span>
<span class="comment-meta-date"><a href="#c172872">#</a> 2009-02-02</span>
</p>
<div class="comment-bulk">
<p>I have found that having both valid XHTML and CSS, while not necessarily helping you in the search engines, definitely doesn't hurt, and bad code, broken CSS or missing alt tags <i>will</i> hurt you in the search engines.
I can't think of a single instance where invalid code would help anyone.</p>

</div>
</div>


<div class="comment" id="comment-172914">
<p class="comment-meta" id="c172914">
<span class="comment-meta-author"><strong>ptamaro </strong></span>
<span class="comment-meta-date"><a href="#c172914">#</a> 2009-02-03</span>
</p>
<div class="comment-bulk">
<p>Using valid semantic markup helps make websites and web applications more accessible and easier to use. Valid markup is also a LOT easier to style (with consistent results), maintain, and test!</p>

</div>
</div>


<div class="comment" id="comment-173116">
<p class="comment-meta" id="c173116">
<span class="comment-meta-author"><strong>Stewart </strong></span>
<span class="comment-meta-date"><a href="#c173116">#</a> 2009-02-06</span>
</p>
<div class="comment-bulk">
<p>I disagree with "And that is a good thing" - IMO it just encourages more website developers to be lazy.  Moreover, not all browsers recover from errors in the same way, and so validation is a great help to cross-browser compatibility.</p>

<p>Tim - you shouldn't have any "alt tags" in your code, because there's no such thing.  They're alt attributes.  If you want to be understood clearly, correct use of terms is as important as correct HTML.</p>

</div>
</div>


<div class="comment" id="comment-173153">
<p class="comment-meta" id="c173153">
<span class="comment-meta-author"><strong>Luc </strong></span>
<span class="comment-meta-date"><a href="#c173153">#</a> 2009-02-10</span>
</p>
<div class="comment-bulk">
<p>I believe the more we use compliant code, the faster browser companies will start making the right decisions with their products.  We shouldn't have to fix our code for use with multiple browsers.  Browser companies should fix their applications to be compliant and valid across ALL versions.  Not just the new ones.</p>

</div>
</div>


<div class="comment" id="comment-173185">
<p class="comment-meta" id="c173185">
<span class="comment-meta-author"><strong>TheRealNeO Linux hax0r </strong></span>
<span class="comment-meta-date"><a href="#c173185">#</a> 2009-02-13</span>
</p>
<div class="comment-bulk">
<p>i think its a pile of crap to be very honest
easy solution is to use a script to listen for a browser then direct to an
appropriate page, i have been messing with wc3's auto validation
and things that they teach on w3cschools don’t even pass validation
VERY POOR </p>

<p>If you think im morning it is like 1:30am still trying to
Finnish my site up to w3c as its part of an assignment</p>

</div>
</div>


<div class="comment" id="comment-173201">
<p class="comment-meta" id="c173201">
<span class="comment-meta-author"><strong>Lee Johnson </strong></span>
<span class="comment-meta-date"><a href="#c173201">#</a> 2009-02-15</span>
</p>
<div class="comment-bulk">
<p>I have built four websites w/o any formal training, and all have passed w3c validation after learning how to correct the errors and warnings. I believe that this tool is very beneficial to those of us who may miss an important aspect which could lead to lower rankings. I like having the peace of mind, knowing that one aspect of website development is optimized instead of simply guessing. I did, however; hope that it would be weighted a bit more heavily when it comes to the SE algorithms.</p>

<p>Is it just on my screen, or did anyone else notice that the sentence above,("A typo in a CSS stylesheet that hours of glancing at code didn't show, but the validator did? A forgotten alt that would have lowered your search rank for an important keyword, or cost a big fee for non-accessibility?") runs off of the page??? It appears rather ironic!</p>

<p>Anyway, keep up the good work, I believe validation is a valuable asset.</p>

</div>
</div>


<div class="comment" id="comment-173220">
<p class="comment-meta" id="c173220">
<span class="comment-meta-author"><strong>olivier Thereaux (W3C) </strong></span>
<span class="comment-meta-date"><a href="#c173220">#</a> 2009-02-16</span>
</p>
<div class="comment-bulk">
<p>Thank you all <em>so much</em> for all the great, thought provoking feedback on this post. We are getting really close to having critical mass to rewrite the outdated “why validate” document!</p>

<p>I'll take the opportunity to follow-up on some of the comments, and try to summarize some of the ideas.</p>

<p>I see quite a few of you are using validation as a “maintenance” or debug tool. This is interesting, and I think we could try and stress both the fact that validating can be a time-saving reflex whenever a site display/interactions shows bugs in some platforms, as well as advocate for valid, well formed and rich code as an insurance against bad surprises.</p>

<p>Accessibility too seems to be a very important role. We are touching a controversial but fascinating area here. Some may remember the hard-fought consensus in WCAG2 about the need for valid markup. What I read in @Laura's comment is an interesting reversal of that discussion: educating (future) professionals about valid markup as a good practice can be a gentle introduction to the wider scope of accessibility. </p>

<p>@charlie asks, tongue in cheek perhaps “Are there actually real-life arguments in favor of non-valid code?”. I think “laziness” is the quick answer I can make here – longer answers may digress into pop psy ;) – but it is very important that we know what motivates people to think “I don't care”. If we advocate for Web quality with the wrong arguments, some people will refute the arguments and get entrenched in a “my tag soup works just fine, why should I waste my time?” standpoint. This also joins @Stewart's comment. I honestly think that laziness is not inherently bad. Laziness is what causes us to not bother about what is not important, and focus on elegant solutions for the rest. </p>

<p>Finally, since many like “TheRealNeO Linux hax0r” get confused, do note that w3schools and w3c are not related. w3schools is an often useful, sometimes mistaken resource made by people with no ties whatsoever with w3c. If their site is in error, please complain to them, not the W3C :).</p>

</div>
</div>


<div class="comment" id="comment-173260">
<p class="comment-meta" id="c173260">
<span class="comment-meta-author"><strong>Kat B </strong></span>
<span class="comment-meta-date"><a href="#c173260">#</a> 2009-02-20</span>
</p>
<div class="comment-bulk">
<p>Why I think valid code is important? Because I'm not just publishing <em>style</em>, I'm publishing <em>data</em>. Markup is about data, and I want my data to be open not to just human eyes, but all sorts of agents. The semantic web is coming, eventually, and I don't want to revisit the work I do now. I already work so hard to share my data and have people interested in my data, I'm all happy to have help from external sources. It would be akin to fixing up old pages that have been so badly written that Google can't index them. Like microformats: they are an intermediate step on the way to the semantic web. That's why valid code is important.</p>

</div>
</div>


<div class="comment" id="comment-173272">
<p class="comment-meta" id="c173272">
<span class="comment-meta-author"><strong>Nathanael Ritz </strong></span>
<span class="comment-meta-date"><a href="#c173272">#</a> 2009-02-20</span>
</p>
<div class="comment-bulk">
<p>With the recent news about <a href="http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx" rel="nofollow">IE 8 supporting standards by default</a>, we are going to be entering an age where the predominate browser types will be standard loving.</p>

<p>This means that when you code to standards and validate, more and more, the appearance of your site is going to look the same from one standards loving browser to the next. However, until HTML 5 hits critical mass, these standards browsers still render <a href="http://ln.hixie.ch/?start=1037910467&amp;count=1" rel="nofollow">invalid code in different ways</a>. This means your website might look fine in the one browser you are testing in, but that other popular browser you didn't code for ends up breaking the appearance of your masthead and navigation bar, for example.</p>

<p>Quirks mode or DOCTYPE switched, different browsers render invalid code in different ways. But standards loving browsers will more often than not, render your valid code in a much more predictable way.</p>

</div>
</div>


<div class="comment" id="comment-173519">
<p class="comment-meta" id="c173519">
<span class="comment-meta-author"><strong>Nicolae Crefelean </strong></span>
<span class="comment-meta-date"><a href="#c173519">#</a> 2009-02-24</span>
</p>
<div class="comment-bulk">
<p>True, w3schools are a different organization and they have outdated documentation. While they have much more user-friendlier guides to writing code - compared to W3C -, they still have to work on representing such a sensitive area of development, where everyone can use validation tools to check their pages.</p>

<p>Now about standards and browsers it is my personal opinion that respecting standards should be the most important aspect of any web development project because it's much easier and less time consuming to make browsers work with valid code than blowing your mind rendering pages made by people who don't care about/know the web standards. After all, a browser should - in theory - consume more resources to display a non-valid document because it needs a little more time to interpret the code, while standard pages are simply displayed by the rules. Take Yahoo! Mail or Google Mail for example. They really ignore the web standards and, because of that, their web interfaces are a bit slower than other pages - maybe equally large as these pages.</p>

<p>Actually, following the standards could be in the end the best way for everyone because rules make things simpler. Writing code randomly makes it confusing for early developers as well, because they just don't know what is and what's not correct, unless they learn standards and base their work on them. In the end, aiming towards a valid WWW is something the will ultimately affect servers as well, because clients busy rendering "crap" will stress the servers for a longer period of time for all content to load. So considering the whole equation it is cheaper to go with the standards than otherwise.</p>

</div>
</div>


<div class="comment" id="comment-173599">
<p class="comment-meta" id="c173599">
<span class="comment-meta-author"><strong>Sergey Shepelev </strong></span>
<span class="comment-meta-date"><a href="#c173599">#</a> 2009-02-27</span>
</p>
<div class="comment-bulk">
<p>One very simple point.</p>

<p><strong>who needs long doctype?</strong> validator
Before any HTML5, placing what you would call "incorrect"  in the beggining, would turn good standards HTML 4.01 Strict for IE6 and every other browser. This makes unneeded all other validator stuff like content-type, public/private ns links in doctype which were only useful for validator itself.</p>

<p><strong>browser is</strong> validator
We live in a real world, as editor creates page, he obviously MUST check how it looks in all popular browsers. Conforming to standards give a perfectly high chance that page will still look like that in the future, but still he must check it now.</p>

<p>Search engines raise rank of "valid" pages? No.
Because page doesn't have to be some kind of mathematically proven valid. Purpose of page is to represent the information. If the information is shown correctly, then page is valid for me, for every other user. If page has bad markup, obviously browser must try its best to recover and show most he can. Well it would be better if webmaster could get a notification that his page renders incorrectly. But validator is about conforming some strict rules, while browsers are not.</p>

<p>So making page "valid for validator" is pointless, it's a stupid machine. Make pages valid for users, they are only ones who we make pages for, they are only ones who could thank you for pages.</p>

</div>
</div>


<div class="comment" id="comment-174840">
<p class="comment-meta" id="c174840">
<span class="comment-meta-author"><strong>Allan </strong></span>
<span class="comment-meta-date"><a href="#c174840">#</a> 2009-03-08</span>
</p>
<div class="comment-bulk">
<p>The single best reason for valid markup in my experience will always be the fact it loads faster. Errors in your markups can seriously penalize load times on pretty much all browsers though it's more noticable on larger pages than small ones.</p>

</div>
</div>


<div class="comment" id="comment-175259">
<p class="comment-meta" id="c175259">
<span class="comment-meta-author"><strong>olivier Théreaux <a class="commenter-profile" href="http://www.w3.org/People/olivier/"><img alt="Author Profile Page" src="http://www.w3.org/QA/sununga/mt-static/images/comment/mt_logo.png" width="16" height="16" /></a></strong></span>
<span class="comment-meta-date"><a href="#c175259">#</a> 2009-03-09</span>
</p>
<div class="comment-bulk">
<p>@Allan, do you have stats on that one? Something in me would like to believe that well-formed markup is faster to parse and render than tag soup, but I'd rather see actual numbers than believe with my eyes closed. </p>

<p>If there is a speed gain, is it mostly related to parsing? Or to rendering? I suspect that the latter would make a much bigger difference, since the end user would feel rendering delay (or re-rendering of the page, or rendering after a delay) more acutely.</p>

<p>If the difference is significant, it would be very interesting to compare speed gained in parsing well-formed and valid markup to the time gained by retrieving shorter, but invalid, pages.</p>

</div>
</div>


<div class="comment" id="comment-175279">
<p class="comment-meta" id="c175279">
<span class="comment-meta-author"><strong>karl </strong></span>
<span class="comment-meta-date"><a href="#c175279">#</a> 2009-03-09</span>
</p>
<div class="comment-bulk">
<p>Olivier, </p>

<p>after discussions with some browsers implementers, the processing time for a Web page is from the quickest to slowest </p>

<ol>
<li>parsing, </li>
<li>scripts, </li>
<li>rendering</li>
</ol>

<p>John Resig has an article <a href="http://ejohn.org/blog/javascript-performance-stack/" rel="nofollow">about performances</a> and there is also <a href="http://ejohn.org/blog/browser-page-load-performance/" rel="nofollow">Browser Page Load Performance</a></p>

<p>Microsoft has also an article on issues <a href="http://blogs.msdn.com/ie/archive/2009/01/23/common-issues-in-assessing-browser-performance.aspx" rel="nofollow">assessing browser performance</a>.</p>

</div>
</div>


<div class="comment" id="comment-175282">
<p class="comment-meta" id="c175282">
<span class="comment-meta-author"><strong>olivier Théreaux <a class="commenter-profile" href="http://www.w3.org/People/olivier/"><img alt="Author Profile Page" src="http://www.w3.org/QA/sununga/mt-static/images/comment/mt_logo.png" width="16" height="16" /></a></strong></span>
<span class="comment-meta-date"><a href="#c175282">#</a> 2009-03-09</span>
</p>
<div class="comment-bulk">
<p>@karl, many thanks for the pointers!</p>

<p>I started adding the contributions from these comments into the "why validate" document on the validator. Work in progress here: <a href="http://qa-dev.w3.org/wmvs/HEAD/docs/why">http://qa-dev.w3.org/wmvs/HEAD/docs/why</a></p>

</div>
</div>


<div class="comment" id="comment-179098">
<p class="comment-meta" id="c179098">
<span class="comment-meta-author"><strong>Nicolae Crefelean </strong></span>
<span class="comment-meta-date"><a href="#c179098">#</a> 2009-03-20</span>
</p>
<div class="comment-bulk">
<p>Sergey Shepelev, you do have a point with the real world application. It's true that it makes sense to make the pages look good for the users, but you missed a few points regarding validation. While it seems absurd to write code for the "validators" it is actually about the browsers. While parsing the HTML content, the browsers switch the rendering engine to Quirks Mode if the find the document not to be valid.</p>

<p>Obviously, the Quirks Mode takes a bit longer to process because the clients must see a normal page even if the HTML is "broken". But the problem is not with rendering time on the client. For visitors, the rendering mode is transparent because they don't see anywhere if they are viewing a website in Standards Compliance Mode or Quirks Mode. They just wait a fraction longer - maybe unnoticeable. </p>

<p>So the problem is not on the clients but on the server. Because clients take a bit longer to process web data, they also load the content at a slower pace - along with their rendering "speed". Sum that up and the server will have many clients with longer sessions, which means the server gets stressed more than it could. This is why, in my opinion, writing valid code is very important.</p>

<p>The question was: "Valid sites work better?"
The answer is: "They do work better, but never forget to view them in different browsers to adjust whatever doesn't look as it should."</p>

</div>
</div>


<div class="comment" id="comment-180216">
<p class="comment-meta" id="c180216">
<span class="comment-meta-author"><strong>Sergey Shepelev </strong></span>
<span class="comment-meta-date"><a href="#c180216">#</a> 2009-03-25</span>
</p>
<div class="comment-bulk">
<p>Nicolae Crefelean, thanks for answer. Even more, i think user must not see normal page if HTML is really broken. If you open broken .rtf in text editor, it will be just mess and it's normal. Because nobody produces wrong RTF. Producers of really wrong, unrenderable HTML must be punished and fix their errors.</p>

<p>But, i completely hate HTML "close tags" rule. Well it's rather to say that HTML syntax at all is antihumanic and thus, they must use proper software to generate renderable HTML. And writing schemas addresses in DOCTYPE is completely pointless - browsers don't fetch it. It only makes validator unhappy.</p>

<p>That said, i can imagine so nice future if HTML was generated by software (and thus contained no syntax errors as RTF/ODT/etc) and browsers loudly failed on really unrenderable HTML. Perhaps, i must try to create a proper editor.</p>

<p>Problem on server is just so funny and minded. Session time doesn't consume proper (asynchronous) server resources. Single commodity box can have 45K keep-alive sessions at almost zero CPU usage.</p>

<p>It's sad to agree on "never forget to check in different browsers". Would be nice if same HTML looked same everywhere.</p>

</div>
</div>


<div class="comment" id="comment-180764">
<p class="comment-meta" id="c180764">
<span class="comment-meta-author"><strong>Sean Fraser </strong></span>
<span class="comment-meta-date"><a href="#c180764">#</a> 2009-04-04</span>
</p>
<div class="comment-bulk">
<p>I have found the sea change in clients <em>adopting</em> Web Standards, e.g., semantically written HTML/CSS code which passes validation and meets Accessibility, ironic.</p>

<p>Three years ago, clients would reject any suggestion for semantics and validation. However, after Search Marketing experts agreed that semantically written HTML/CSS code which passes validation and meets Accessibility, i.e., Web Standards, benefits search engines results positions - clients want valid sites.</p>

<p>Return-on-investment by Web Standards.</p>

</div>
</div>


<div class="comment" id="comment-182309">
<p class="comment-meta" id="c182309">
<span class="comment-meta-author"><strong>мeкy </strong></span>
<span class="comment-meta-date"><a href="#c182309">#</a> 2009-06-07</span>
</p>
<div class="comment-bulk">
<p>Вообще, откровенно говоря, комментарии тут гораздо занимательней самих постов. (Не в обиду автору, конечно :))</p>

</div>
</div>


<div class="comment" id="comment-182391">
<p class="comment-meta" id="c182391">
<span class="comment-meta-author"><strong>Brian </strong></span>
<span class="comment-meta-date"><a href="#c182391">#</a> 2009-06-16</span>
</p>
<div class="comment-bulk">
<p>I would love to have a browser that, when encountering the doctype, could optionally perform a validation on a page and if not valid refuse to display the page, offering the option then to ignore the required validation and display the page anyway.
As a career software developer, I shudder to think what life would have been like if the FORTRAN compiler said in effect "Eh, that syntax is pretty close...let's give you a number that <em>might</em> be what you want". <br />
I think it's time for browsers to be cruelly resistant to non standards compliant pages.  Of course...with the standards being open to interpretation that's a entirely new argument to be had.</p>

<p>I feel that without browsers that are as strict as a compiler there will be too much art in the coding of a Web page.  Save the art for the style and appearance of a page, yes, but the implementation of that artistic choice should be as rigorous as C code.</p>

<p>My two cents...I'd be happy to discuss.</p>

</div>
</div>


<div class="comment" id="comment-182978">
<p class="comment-meta" id="c182978">
<span class="comment-meta-author"><strong>LoveyK </strong></span>
<span class="comment-meta-date"><a href="#c182978">#</a> 2009-08-19</span>
</p>
<div class="comment-bulk">
<p>Ahoy</p>

<p>I am disabled with multiple chronic illnesses which impair my eyesight, hearing, speech and motor skills. <i>(But I look good when I'm very still and quiet)</i>
</p>

<p>I became involved with W3C in 1998 with my first attempt at building a simple Accessible webpage. Tim Berner-Lee's words inspired me. (And still do.)</p>

<p>By following W3C guidelines I found I could write html with only a text editor and explore my creativity by "seeing with my minds eye". I didn't need the popular WYSIWYG's. The W3C validator assured me my inexperience and (perhaps dubious) self-taught methods were not an issue and I was achieving my goal; Accessibility plus Cross-Browser Interoperability (be that it as it may).</p>

<p>I continue to faithfully use only a text editor and the Validator.</p>

<p>I am on a fixed (and quite meager) income. Someday Santa will bring me Adobe Flash and more importantly a new computer to replace my 5 year old refurbished eMac (hee hee) and I can do some really exciting things! Regardless, I know my webpages are compliant and render properly (as browsers will permit). The W3C Validator will always be my most important tool.</p>

<p>I received a grant in 1998 to build my first website for a local Art Foundation to serve as it's virtual gallery. The Foundation's building was too small to exhibit their most valuable and historic works.
Naturally it was imperative the website be attractive, easily to navigate and globally interoperable. Within weeks of its upload the other major Art Institutes in my city shut down their websites and posted "Under Construction" notices (as was popular in the late '90's). Much to my surprise and sorrow, eleven sites, known nationally, <i>today still do not pass validation.</i> <b>Where have they been?</b></p>

<p>The Art website is still on-line. (I often call it mine since my name is still in the source code.) Someone else is charged with the upkeep and in the last 4 years many areas are no longer compliant and the source contains proprietary code (and there are the <i>mysterious</i> dead links). They removed all the Valid Markup badges rather than investigate and correct simple errors, many are due to proprietary code. (The "Lazy" factor?) Yet I'm pretty proud of my first attempt and that the Foundation has not desired to change its design. Sadly, subsequent websites I was commissioned are no longer on-line due to the businesses closing. (Of course I have copies)</p>

<p>You may not be able to understand how difficult for someone like myself to stay in synch with new W3C guidelines, upgrades and innovations in web design.  There are entire years I have not been able to work on the computer due to illness. Everything has become more exciting but definately complicated in the past decade. Software for Accessibility is inaccessible to me due to cost, OS and more often interface. Many things are Windows only. For instance, I cannot use MAGpie because of my handicaps. I must code text-captions tediously, word by word, millisecond by millisecond. But I have been able to keep abreast of most changes simply by validating. For myself, especially, the validator has also become an essential and invaluable learning tool. And I definately  perform cross platform/browser/seo checks because sometimes I am so far behind.</p>

<p></p>

<p>For someone like myself, limited and cut off physically from the world, the WWW opened a door for me I thought closed. It is my greatest escape and I am beyond thankful for the opportunity. I became productive and contributing citizen again and am only limited by my imagination. To me this is a gift. Care and attention to detail must be taken. Procedures set in place through the efforts of hundreds of people and thousands of man-hours demand respect. There is responsibility and accountability in all we do. Our webpages speak volumes of how we think and how we think about others.</p>

<p>To sum it up (finally) the W3C Validator does more than validate markup. It validates ... me!</p>

<p>~CAVU~</p>

<p>-LK</p>

<p><i>A little to sappy and philosophical?  Yeah, I know ... someone else always has a far better sob story!!</i></p>

</div>
</div>


<div class="comment" id="comment-184855">
<p class="comment-meta" id="c184855">
<span class="comment-meta-author"><strong>Alan Dave M. MIllana </strong></span>
<span class="comment-meta-date"><a href="#c184855">#</a> 2009-11-10</span>
</p>
<div class="comment-bulk">
<p><b>Thank you So much!!!</b>Great!!</p>

</div>
</div>


<div class="comment" id="comment-184951">
<p class="comment-meta" id="c184951">
<span class="comment-meta-author"><strong>Andre </strong></span>
<span class="comment-meta-date"><a href="#c184951">#</a> 2009-11-16</span>
</p>
<div class="comment-bulk">
<p>I have been following the story all over the Internet are already start in 1999 with her and I are here, but unfortunately I have failed to make it further and then I went on the 2003 stopped.</p>

<p>The idea of making a standard "I like that".</p>

<p>I am here to inform me regularly about it.</p>

<p>If you look at what has done in the field of computer and what is today the Internet is possible, it really can only marvel.</p>

<p>Many thanks to all who made this possible</p>

<p>So if it is ok, i will place a Link to my Site, so if not, please remove it :-)</p>

</div>
</div>


<div class="comment" id="comment-198086">
<p class="comment-meta" id="c198086">
<span class="comment-meta-author"><strong>victoria </strong></span>
<span class="comment-meta-date"><a href="#c198086">#</a> 2010-08-06</span>
</p>
<div class="comment-bulk">
<p>One simple reason for writing valid code was not mentioned: why to ignore orthography of markup, when we don't do the same to written human language (maybe on IM chats we do, but not in official documents)?</p>

</div>
</div>


  <div class="comments-open" id="comments-open">
<h3 class="comments-open-header">Leave a comment</h3>

<div class="comments-open-moderated">
   <p>
   Note: this blog is intended to foster <strong>polite
   on-topic discussions</strong>. Comments failing these
   requirements and spam will not get published. Please,
   enter your real name and email address. Every
   individual comment is reviewed by the W3C staff.
   This may take some time, thank you for your patience.
   </p>
   <p>
   You can use the following HTML markup (a href, b, i,
   br/, p, strong, em, ul, ol, li, blockquote, pre)
   and/or <a href="http://daringfireball.net/projects/markdown/syntax">Markdown syntax</a>.</p>
</div>

<div id="comments-open-data">
<form method="post" action="http://www.w3.org/QA/sununga/beach.pl" id="comments-form">
<h4>Your comment</h4>
<div id="comments-open-text">
  <textarea id="comment-text" name="text" rows="20" cols="100"></textarea><br />
<label for="comment-text">Write your comment text here. Remember, keep the discussion on topic and courteous.</label>
</div>

<h4>About you</h4>
<div id="comment-form-name">
  <input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="6298" />
<input type="hidden" name="__lang" value="en" />
<label for="comment-author">Your Name</label>
<input id="comment-author" name="author" size="30" value="" />
</div>
<div id="comment-form-email">
<label for="comment-email">Your Email Address</label>
<input id="comment-email" name="email" size="30" value="" />
</div>

<div id="comments-open-footer">
<input type="submit" accesskey="s" name="post" id="comment-submit" value="Submit" />

</div>
</form>
</div>
</div>


<p id="gentime">This page was last generated on $Date: 2011/12/05 17:18:25 $</p>

      </div><!-- End of "main" DIV. -->

<address>

This blog is written by W3C staff and working group participants,<br />
&nbsp;and maintained by <a href="/People/CMercier/">Coralie Mercier</a>.<br />
Authorized parties may <a href="/QA/new">log in</a> to create a new entry.<br/>
<span id="poweredby">Powered by Movable Type, magpierss and a lot of Web Technology</span>
    </address>


    <p class="copyright">
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 1994-2011
      <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a>&reg;
      (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
      <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
      <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved.
      W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
      <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
      and <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a>
      rules apply. Your interactions with this site are in accordance
      with our <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Public">public</a> and
      <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Members">Member</a> privacy
      statements.
    </p>

  </body>
</html>