mozilla

Revision 150962 of Benefits of using web standards

  • Revision slug: Using_Web_Standards_in_your_Web_Pages/Benefits_of_using_web_standards
  • Revision title: Benefits of using web standards
  • Revision id: 150962
  • Created:
  • Creator: GT
  • Is current revision? No
  • Comment /* References on benefits of using web standards */ Updating Karl Core article's URL

Revision Content

The benefits of using web standards (W3C recommendations and language specifications regarding webpage authoring) are numerous, important, often underestimated and often misunderstood.

The benefits for valid markup code are

  • consistent cross-browser rendering
  • markup code is forward-compatible (future-proof)
  • webpage is more accessible
  • problems with a webpage are easier to identify, to debug and to fix when it uses valid markup code
  • webpages are faster to develop and easier to maintain

Valid markup code is important to achieve because of one particular reason which is often ignored: there is no error correction mechanism provided by the HTML 4.01 specification.

HTML 4.01, Section B.1 Notes on invalid documents states: "This {{mediawiki.external('HTML 4.01')}} specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document."

So when a browser encounters a particular error in the markup code, the browser has no specific, predefined mechanism (or response) provided by the HTML 4.01 specification: the error part will be rendered in various ways by different browsers. There is no correct or incorrect rendering when browsers encounter invalid markup code. Invalid markup code is outside the HTML 4.01 specification and is therefore rendered entirely thanks to non-standard browser interpretation. This phenomenon is particularly true for syntaxical errors such as:

  • missing end quote in attribute values: "There's also the missing quotes problem, e.g., leaving a close quote off a link href. Browsers employ complicated heuristics to try to match up unclosed quotes that depend on the number of quotes in the document, their positions, and other factors" from David Hyatt's blog
  • Incorrect nesting of elements

    Elements must close in the right order; elements must not overlap each other.

The following code example is invalid syntax because of incorrect nesting of elements:

<p>These are 2 <strong>strong words.</p></strong>

This type of markup error happens often to beginners and to unaware web authors; it is detected and reported by HTML validators. An HTML validator will report this typical error message:
"end tag for 'STRONG' omitted, but its declaration does not permit this. (...) you used something inside this tag that was not allowed, and the validator is complaining that the tag should be closed before such content can be allowed. (...)"

The following code example is valid syntax and correct nesting of elements:

<p>These are 2 <strong>strong words </strong>.</p>

More info:

incorrect nesting of elements explained at WDG

Tag Soup: How UAs handle <x> <y> </x> </y> by Ian Hickson

  • misused or misplaced elements:

Another frequently encountered markup error is to have a block-level element (e.g. <p>, <div>, <table>) nested inside an inline element (e.g. <span>, <strong>, <big>).

The following markup code example is invalid syntax because an inline element (<b>) wraps a block-level element (<p>):

<b><p>This is a bold paragraph.</p></b>

This type of markup error happens often to beginners and to unaware web authors; it is detected and reported by HTML validators. An HTML validator will report this typical error message: "document type does not allow element 'B' here (...) One possible cause for this message is that you have attempted to put a block-level element (such as '<p>' or '<table>') inside an inline element (such as '<a>', '<span>')."

The following code example is valid markup syntax because the inline element (<b>) is nested inside the block-level element (<p>):

<p><b>This is a bold paragraph.</b></p>

More info: Tag Soup: Blocks-in-inlines (for advanced people) by Ian Hickson

By avoiding invalid markup code, a web author reduces risks of causing overlapping elements, misaligned or misplaced elements or strange layout problems. In some cases, a browser may even crash when encountering malformed markup code.

First example of malformed markup code causing crash: The importance of human-readable markup (May 2003) by Mark Pilgrim

Second example example of malformed markup code causing crash: IE vertical-align:top vulnerability (October 2003) by Jehiah Czebotar

More reading on markup validation:

The benefits for clear separation of content from presentation aspects (font, color, padding, margin, border, etc.) thanks to CSS implementation are

  • smaller files and faster download (Note 1)
  • better layout control
  • better interoperability across platforms, devices and media (Note 2)
  • easier maintenance and increased opportunities

Note 1: Why use CSS to separate content from presentation? from MaxDesign
What is the separation of content and presentation? Why is it important? from maccaws.org
Note 2: HTML 4.01, Section 2.4.1 Separate structure and presentation:
"Experience has shown that separating the structure of a document from its presentational aspects reduces the cost of serving a wide range of platforms, media, etc., and facilitates document revisions."

Explaining in detail how to implement CSS in webpages would go beyond the scope of this article. For people wishing to implement CSS into their webpages, we recommend the following tutorials:

The benefits for using valid CSS code are

  • consistent cross-browser rendering
  • problems with a webpage, in particular a DHTML-driven webpage, are easier to identify, to debug and to fix when it uses valid CSS code

Reduced browser incompatibilities

In the last 5 years, browser vendors and web-aware software manufacturers have provided accessible bug reporting systems and have been consistently improving and correcting their HTML and CSS rendering engines when a webpage triggers standards compliant rendering mode. That is particularly true for Opera browser, Safari browser, Icab browser and Mozilla-based browsers. So with time, newer versions of browsers have lesser incompatibilities as they comply more closely to W3C specifications.

2 risks regarding editing with a WYSIWYG HTML editor

Many web author amateurs create their webpages with a WYSIWYG HTML editor, ie a graphical HTML editor like MS-Front Page, Nvu, DreamWeaver, KompoZer, etc. One risk involved with this kind of edition is that edition relies too much on the visual feedback of the editor. There are many web browsers and web-aware softwares that access webpages, not just 1. What the web author sees (while editing his webpage with such kind of software) may not be what his visitors will see because of different browsers (or different browser versions of the same browser name) involved, different configurations of the same browser, different media, different devices, different contexts in use. WYSIWYG webpage editors often lead web authors to the mistaken belief that what they see (while editing their webpage) is/should be good enough for everyone else. Unless a web author can test his webpages in multiple browsers, in multiple environments, media, with various devices, etc, the only realistic test and valuable, recommendable checking is to validate the markup code (and CSS code) of a webpage with a HTML validator (and a CSS validator). Markup validation is not browser dependent or browser specific; all graphical HTML editors are browser dependent and browser specific.

Another risk with WYSIWYG HTML editors is that these softwares have a tendency to add superfluous code (like many <br> and &nbsp;) in order to position or to fix elements within the webpage or within the viewport. So even though the markup code may be valid, the end result is a non-scalable, rigid (screen resolution dependent) webpage filled with spacer.gif, <br> and &nbsp; which bloat the markup code. This goes against the purpose of a clean, lean, streamlined markup code. In this context, spacer.gif, <br> and &nbsp; can be replaced most of the time by a wise usage of CSS properties like padding, margin or clear. It is beyond the scope of this article to elaborate on this issue but we wish to indicate that many <br> and &nbsp; is often the sign of bloated markup code and of a non-scalable webpage.

References on benefits of using web standards

Revision Source

<p>
</p><p>The benefits of using web standards (W3C recommendations and language specifications regarding webpage authoring) are numerous, important, often underestimated and often misunderstood.
</p>
<h3 name="The_benefits_for_valid_markup_code_are"> The benefits for valid markup code are </h3>
<ul><li> consistent cross-browser rendering
</li><li> markup code is forward-compatible (future-proof)
</li><li> webpage is more accessible
</li><li> problems with a webpage are easier to identify, to debug and to fix when it uses valid markup code
</li><li> webpages are faster to develop and easier to maintain
</li></ul>
<p>Valid markup code is important to achieve because of one particular reason which is often ignored: there is no error correction mechanism provided by the HTML 4.01 specification.
</p><p><a class="external" href="http://www.w3.org/TR/html4/appendix/notes.html#h-B.1">HTML 4.01, Section B.1 Notes on invalid documents</a> states:
"This {{mediawiki.external('HTML 4.01')}} specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document."
</p><p>So when a browser encounters a particular error in the markup code, the browser has no specific, predefined mechanism (or response) provided by the HTML 4.01 specification: the error part will be rendered in various ways by different browsers. <b>There is no correct or incorrect rendering when browsers encounter invalid markup code</b>. Invalid markup code is outside the HTML 4.01 specification and is therefore rendered entirely thanks to non-standard browser interpretation. This phenomenon is particularly true for syntaxical errors such as:
</p>
<ul><li> missing end quote in attribute values: "There's also the missing quotes problem, e.g., leaving a close quote off a link href. Browsers employ complicated heuristics to try to match up unclosed quotes that depend on the number of quotes in the document, their positions, and other factors" from <a class="external" href="http://weblogs.mozillazine.org/hyatt/archives/2004_01.html#004702">David Hyatt's blog</a>
</li><li> Incorrect nesting of elements <p id="incorrectnesting">Elements must close in the right order; elements <b>must not overlap</b> each other.</p>
</li></ul>
<div class="bad">
<p>The following code example is <b>invalid</b> syntax because of incorrect nesting of elements:
</p>
<pre>&lt;p&gt;These are 2 &lt;strong&gt;strong words.&lt;/p&gt;&lt;/strong&gt;
</pre>
<p>This type of markup error happens often to beginners and to unaware web authors; it is detected and reported by HTML validators. An HTML validator will report <a class="external" href="http://validator.w3.org/docs/errors.html#ve-73">this typical error message</a>:<br>
"end tag for 'STRONG' omitted, but its declaration does not permit this. (...) you used something inside this tag that was not allowed, and the validator is complaining that the tag should be closed before such content can be allowed. (...)"
</p>
</div>
<div class="good">
<p>The following code example is <b>valid</b> syntax and correct nesting of elements:
</p>
<pre>&lt;p&gt;These are 2 &lt;strong&gt;strong words &lt;/strong&gt;.&lt;/p&gt;
</pre>
</div>
<p>More info:
</p><p><a class="external" href="http://www.htmlhelp.org/tools/validator/problems.html.en#nesting">incorrect nesting of elements</a> explained at <abbr title="Web Design Group">WDG</abbr>
</p><p><a class="external" href="http://ln.hixie.ch/?start=1037910467&amp;count=1">Tag Soup: How UAs handle &lt;x&gt; &lt;y&gt; &lt;/x&gt; &lt;/y&gt;</a> by Ian Hickson
</p>
<ul><li> misused or misplaced elements: 
</li></ul>
<p>Another frequently encountered markup error is to have a block-level element (e.g. <code>&lt;p&gt;</code>, <code>&lt;div&gt;</code>, <code>&lt;table&gt;</code>) nested inside an inline element (e.g. <code>&lt;span&gt;</code>, <code>&lt;strong&gt;</code>, <code>&lt;big&gt;</code>).
</p>
<div class="bad" id="blocknestedininline">
<p>The following markup code example is <b>invalid</b> syntax because an inline element (<code>&lt;b&gt;</code>) wraps a block-level element (<code>&lt;p&gt;</code>):
</p>
<pre>&lt;b&gt;&lt;p&gt;This is a bold paragraph.&lt;/p&gt;&lt;/b&gt;
</pre>
<p>This type of markup error happens often to beginners and to unaware web authors; it is detected and reported by HTML validators. An HTML validator will report <a class="external" href="http://validator.w3.org/docs/errors.html#ve-65">this typical error message</a>:
"document type does not allow element 'B' here (...) One possible cause for this message is that you have attempted to put a block-level element (such as '<code>&lt;p&gt;</code>' or '<code>&lt;table&gt;</code>') inside an inline element (such as
'<code>&lt;a&gt;</code>', '<code>&lt;span&gt;</code>')."
</p>
</div>
<div class="good">
<p>The following code example is <b>valid</b> markup syntax because the inline element (<code>&lt;b&gt;</code>) is nested inside the block-level element (<code>&lt;p&gt;</code>):
</p>
<pre>&lt;p&gt;&lt;b&gt;This is a bold paragraph.&lt;/b&gt;&lt;/p&gt;
</pre>
</div>
<p>More info:
<a class="external" href="http://ln.hixie.ch/?start=1138169545&amp;count=1">Tag Soup: Blocks-in-inlines</a> (for advanced people) by Ian Hickson
</p><p>By avoiding invalid markup code, a web author reduces risks of causing overlapping elements, misaligned or misplaced elements or strange layout problems. In some cases, a <b>browser may even crash</b> when encountering malformed markup code.
</p><p>First example of malformed markup code causing crash:
<a class="external" href="http://diveintomark.org/archives/2003/05/03/the_importance_of_humanreadable_markup">The importance of human-readable markup (May 2003)</a> by Mark Pilgrim
</p><p>Second example example of malformed markup code causing crash:
<a class="external" href="http://jehiah.cz/archive/ie-vertical-align-top-vulnerability">IE vertical-align:top vulnerability (October 2003)</a> by Jehiah Czebotar
</p><p>More reading on markup validation:
</p>
<ul><li> <a class="external" href="http://webtips.dan.info/validators.html">Validators -- checking the correctness of your documents</a> by Daniel Tobias
</li><li> <a class="external" href="http://www.karlcore.com/articles/id/the-importance-of-standards-compliance-and-the-process-of-validation/">The Importance Of Standards Compliance and The Process of Validation</a> by Karl Core
</li><li> <a class="external" href="http://weblogs.mozillazine.org/hyatt/archives/2004_01.html#004702">Error Handling in Web Browsers</a> by David Hyatt (for more advanced users)
</li></ul>
<h3 name="The_benefits_for_clear_separation_of_content_from_presentation_aspects_.28font.2C_color.2C_padding.2C_margin.2C_border.2C_etc..29_thanks_to_CSS_implementation_are"> The benefits for clear separation of content from presentation aspects (font, color, padding, margin, border, etc.) thanks to CSS implementation are </h3>
<ul><li> smaller files and faster download (Note 1)
</li><li> better layout control
</li><li> better interoperability across platforms, devices and media (Note 2)
</li><li> easier maintenance and increased opportunities
</li></ul>
<p>Note 1: <a class="external" href="http://www.maxdesign.com.au/presentation/benefits/index07.htm">Why use CSS to separate content from presentation?</a> from MaxDesign<br>
<a class="external" href="http://www.maccaws.org/kit/primer/">What is the separation of content and presentation? Why is it important?</a> from maccaws.org<br>
Note 2: <a class="external" href="http://www.w3.org/TR/html4/intro/intro.html#h-2.4.1">HTML 4.01, Section 2.4.1 Separate structure and presentation</a>:<br>
"Experience has shown that separating the structure of a document from its presentational aspects reduces the cost of serving a wide range of platforms, media, etc., and facilitates document revisions."
</p><p>Explaining in detail how to implement CSS in webpages would go beyond the scope of this article. For people wishing to implement CSS into their webpages, we recommend the following tutorials:
</p>
<ul><li> <a href="en/CSS/Getting_Started">Getting Started: a 14 parts step-by-step guide on CSS</a> at Mozilla Developer Center
</li><li> <a class="external" href="http://www.htmlhelp.com/reference/css/quick-tutorial.html">CSS tutorials from <abbr title="Web Design Group">WDG</abbr></a> (for beginners)
</li><li> <a class="external" href="http://tutorials.alsacreations.com/">Creating websites with CSS and (X)HTML</a>: tutorials and lessons at alsacreations.com for beginners, intermediate and advanced users
</li><li> <a class="external" href="http://www.westciv.com/style_master/academy/css_tutorial/">Complete CSS Guide</a> at WestCiv
</li><li> <a class="external" href="http://www.htmldog.com/">CSS lessons and tutorials</a> at HTML Dog for beginners, intermediate and advanced users
</li><li> <a class="external" href="http://www.456bereastreet.com/lab/developing_with_web_standards/css/#css">Tips and resources on CSS</a> for intermediate and advanced users; from "Developing With Web Standards: Recommendations and best practices" by Roger Johansson
</li></ul>
<h3 name="The_benefits_for_using_valid_CSS_code_are"> The benefits for using valid CSS code are </h3>
<ul><li> consistent cross-browser rendering
</li><li> problems with a webpage, in particular a <abbr title="Dynamic Hyper Text Markup Language">DHTML</abbr>-driven webpage, are easier to identify, to debug and to fix when it uses valid CSS code
</li></ul>
<h3 name="Reduced_browser_incompatibilities"> Reduced browser incompatibilities </h3>
<p>In the last 5 years, browser vendors and web-aware software manufacturers have provided accessible bug reporting systems and have been consistently improving and correcting their HTML and CSS rendering engines when a webpage triggers standards compliant rendering mode. That is particularly true for Opera browser, Safari browser, Icab browser and Mozilla-based browsers. So with time, newer versions of browsers have lesser incompatibilities as they comply more closely to W3C specifications.
</p>
<h3 name="2_risks_regarding_editing_with_a_WYSIWYG_HTML_editor"> 2 risks regarding editing with a WYSIWYG HTML editor </h3>
<p>Many web author amateurs create their webpages with a <abbr title="What-You-See-Is-What-You-Get">WYSIWYG</abbr> HTML editor, ie a graphical HTML editor like MS-Front Page, <a class="external" href="http://www.nvu.com/index.php">Nvu</a>, DreamWeaver, <a class="external" href="http://kompozer.net/">KompoZer</a>, etc. One risk involved with this kind of edition is that edition relies too much on the visual feedback of the editor. There are many web browsers and web-aware softwares that access webpages, not just 1. What the web author sees (while editing his webpage with such kind of software) may not be what his visitors will see because of different browsers (or different browser versions of the same browser name) involved, different configurations of the same browser, different media, different devices, different contexts in use. <abbr title="What-You-See-Is-What-You-Get">WYSIWYG</abbr> webpage editors often lead web authors to the mistaken belief that what they see (while editing their webpage) is/should be good enough for everyone else. Unless a web author can test his webpages in multiple browsers, in multiple environments, media, with various devices, etc, <strong>the only realistic test and valuable, recommendable checking is to validate the markup code (and CSS code)</strong> of a webpage with a HTML validator (and a CSS validator). Markup validation is not browser dependent or browser specific; all graphical HTML editors are browser dependent and browser specific.
</p><p>Another risk with <abbr title="What-You-See-Is-What-You-Get">WYSIWYG</abbr> HTML editors is that these softwares have a tendency to add superfluous code (like many <code>&lt;br&gt;</code> and <code>&amp;nbsp;</code>) in order to position or to fix elements within the webpage or within the viewport. So even though the markup code may be valid, the end result is a non-scalable, rigid (screen resolution dependent) webpage filled with <code>spacer.gif</code>, <code>&lt;br&gt;</code> and <code>&amp;nbsp;</code> which bloat the markup code. This goes against the purpose of a clean, lean, streamlined markup code. In this context, <code>spacer.gif</code>, <code>&lt;br&gt;</code> and <code>&amp;nbsp;</code> can be replaced most of the time by a wise usage of CSS properties like padding, margin or clear. It is beyond the scope of this article to elaborate on this issue but we wish to indicate that many <code>&lt;br&gt;</code> and <code>&amp;nbsp;</code> is often the sign of bloated markup code and of a non-scalable webpage.
</p>
<h3 name="References_on_benefits_of_using_web_standards"> References on benefits of using web standards </h3>
<ul><li> <a class="external" href="http://www.maxdesign.com.au/presentation/benefits/index.htm">The benefits of Web Standards to your visitors, your clients and you!</a> an excellent slide show from MaxDesign
</li><li> <a class="external" href="http://www.webaccessstrategies.com/blog/id/making-the-business-case-for-web-standards/">Making the Business Case for Web Standards</a> a well written article by Karl Core
</li><li> <a class="external" href="http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you">Why we won't help you</a> by Mark Pilgrim
</li><li> <a class="external" href="http://www.dillo.org/help/bug_meter.html#standards">Why are standards so important?</a> from Dillo project
</li><li> <a class="external" href="http://www.adaptivepath.com/publications/essays/archives/000266.php">The Business Value of Web Standards</a> an excellent and well written article by Jeffrey Veen
</li><li> <a class="external" href="http://www.maccaws.org/kit/primer/">What Every Web Site Owner Should Know About Standards</a> from maccaws.org
</li></ul>
Revert to this revision