1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
<!--#set var="title" value="Why Validate?"
--><!--#set var="relroot" value="../"
--><!--#include virtual="../header.html" -->
<div class="doc">
<h2>Why Validate?</h2>
<p>
This document attempts to answer the questions many people have
regarding <em>why</em> they should bother with Validating their
web sites and tries to dispel a few common myths.
</p>
<h3 id="TableOfContents">Table of contents</h3>
<div id="toc">
<ol>
<li><a href="#history">History of this document</a></li>
<li><a href="#why_pros">Why Web professionals choose to validate</a>
<ol>
<li><a href="#debug">Validation as a debugging tool</a></li>
<li><a href="#futureproof">Validation as a future-proof quality check</a></li>
<li><a href="#maintenance">Validation eases maintenance</a></li>
<li><a href="#learning">Validation helps teach good practices</a></li>
<li><a href="#professionalism">Validation is a sign of professionalism</a></li>
</ol>
</li>
<li><a href="#faq">Frequently asked questions</a>
<ol>
<li><a href="#looksfine">“My site looks right and works fine - isn't that enough?”</a></li>
<li><a href="#bignames">“Lots of websites out there don't validate -including household-name companies”</a></li>
<li><a href="#boring">“Validation means boring websites, and stifles creativity”</a></li>
</ol>
</li>
</ol>
</div>
<h3 id="history">History of this document</h3>
<p>
The original version was written by
<a href="http://www.webthing.com/~nick/">Nick Kew</a> of
<a href="http://www.webthing.com/">WebÞing Ltd.</a> for their
<a href="http://valet.webthing.com/">Site Valet</a> service and he has
generously donated it for our use.
</p>
<p>The document has been updated over time, notably thanks to the many
Web authors who shared their own rationale and motivation for using
Web Quality checking tools.
</p>
<h3 id="why_pros">Why Web professionals choose to validate</h3>
<p>In early 2009 we <a href="http://www.w3.org/QA/2009/01/valid_sites_work_better.html"
title="Valid sites work better(?) - W3C Q&A Weblog">asked the Web community</a>
if they thought there still was a strong motivation for validation. Here are some
reasons they mentioned:</p>
<h4 id="debug">Validation as a debugging tool</h4>
<p>While contemporary Web browsers do an increasingly good job of parsing even the
worst HTML “tag soup”, some errors are not always caught gracefully. Very often,
different software on different platforms will not handle errors in a similar
fashion, making it extremely difficult to apply style or layout consistently.</p>
<p>Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater
chance of having one's page handled consistently across platforms and user-agents. Indeed, most
developers creating rich Web applications know that reliable scripting needs the document to be
parsed by User-Agents without any unexpected error, and will make sure that their markup and CSS is
validated before creating a rich interactive layer.</p>
<p>When surveyed, a large majority of Web professionals will state that validation errors
is the first thing they will check whenever they run into a Web styling or scripting bug.</p>
<h4 id="futureproof">Validation as a future-proof quality check</h4>
<p>Checking that a page “displays fine” in several contemporary browsers may be a
reasonable insurance that the page will “work” today, but it does not guarantee
that it will work tomorrow.</p>
<p>In the past, many authors who relied on the quirks of Netscape 1.1 suddenly
found their pages appeared totally blank in Netscape 2.0.
Whilst Internet Explorer initially set out to be bug-compatible
with Netscape, it too has moved towards standards compliance in
later releases.</p>
<p> Validation is one of the simplest ways to check whether
a page is built in accordance with Web standards, and provides one of the most reliable
guarantee that future Web platforms will handle it as designed.</p>
<h4 id="maintenance">Validation eases maintenance</h4>
<p>It is reasonable to consider that standards such as HTML and CSS are a form of
“coding style” which is globally agreed upon. Creating Web pages or applications
according to a widely accepted coding style makes them easier to maintain, even
if the maintenance and evolution is performed by someone else.</p>
<h4 id="learning">Validation helps teach good practices</h4>
<p>Many professionals have been authoring the Web with HTML and CSS for years and
know these technologies by heart. Beginners and students, on the other hands, will
find automated checking tools invaluable in spotting mistakes. Some teachers also
stress that automated validation tests are a good introduction to broader, more
complex quality concepts such as accessibility.</p>
<h4 id="professionalism">Validation is a sign of professionalism</h4>
<p>As of today, there is little or no certification for Web professionals, and only
few universities teach Web technologies, leaving most Web-smiths to learn by themselves,
with varied success. Seasoned, able professionals will take pride in creating Web content
using semantic and well-formed markup, separation of style and content, etc. Validation
can then be used as a quick check to determine whether the code is the clean work of a
seasoned HTML author, or quickly hacked-together tag soup.</p>
<h3 id="faq">Frequently asked questions</h3>
<p>Validation, as any process of debugging code, is sometimes difficult, and
the vast improvements in automatic error correction has made modern browser
cope very well with errors in HTML or CSS. This makes validation seem useless
or costly to many people, and the following questions (or statement) are
widespread:</p>
<h4 id="looksfine">“My site looks right and works fine - isn't that enough?”</h4>
<p>
The answer to this one is that markup languages are no more than
data formats. So a website doesn't look like anything at all!
It only takes on a visual appearance when it is presented by
your browser.
</p>
<p>
In practice, different browsers can and do display the same page
very differently. This is deliberate, and doesn't imply any kind
of browser bug. A term sometimes used for this is WYSINWOG -
What You See Is Not What Others Get (unless by coincidence).
It is indeed one of the principal strengths of the web, that
(for example) a visually impaired user can select very large print
or text-to-speech without a publisher having to go to the
trouble and expense of preparing a separate edition.
</p>
<h4 id="bignames">“Lots of websites out there don't validate -
including household-name companies.”</h4>
<p>
Do remember: household-name companies expect people to visit
<em>because of</em> the name and <em>in spite of</em>
dreadful websites. Can <em>you</em> afford that luxury?
</p>
<p>
Even if you can, do you want to risk being on the wrong side of a
lawsuit if your site proves inaccessible to - for instance - a
disabled person who cannot use a 'conventional' browser?
Accessibility is the law in many countries. Whilst validation
doesn't guarantee accessibility (there is no substitute for common
sense), it should be an important component of exercising "due
diligence". It is now just over a year since a court first
awarded damages to a blind user against the owners
of a website he found inaccessible (Maguire vs SOCOG, August 2000).
</p>
<h4 id="boring">“Validation means boring websites, and stifles creativity”</h4>
<p>
That might have been the case a decade ago, when validation was the tool
of choice of people more interested in harnessing the power of the markup languages than
creating beautiful designs for their content; when many designers were not taught basics
of Web technology and would create beautiful but fragile and unreliable web sites.
</p>
<p>This argument is completely moot today. In the past decade, most of the stunning, content
and design-rich Web sites were built with standard (X)HTML, CSS and scripting.</p>
</div>
<!--#include virtual="../footer.html" -->
</body>
</html>
|
