mozilla

Revision 36861 of Fixing common validation problems

  • Revision slug: Fixing_common_validation_problems
  • Revision title: Fixing common validation problems
  • Revision id: 36861
  • Created:
  • Creator: Dikrib
  • Is current revision? No
  • Comment Move over content from Using_Web_Standards_in_your_Web_Pages/Making_your_page_using_web_standards_-_how_to; 1068 words added

Revision Content

If you are not careful, you risk building your web pages on assumptions of browser behavior, that were never intentional, never documented and likely to not hold in the future. These assumptions are called quirks, and should be avoided in your web pages. Quirks may cause web pages to behave differently in different browsers, and even different versions of the same browser.

One way to help you make web pages, that work across multiple browsers is to use an HTML validator, that can help you identify problems and quickly correct them. An often used validator is the World Wide Web Consortium's HTML Validator. It's provided by the same people who are responsible for the HTML specification, and more importantly most of its error messages provide a link to an explanation of what the error means. Eventually, of course, you'll recognize what each error message means without having to look up the explanation, but when you're starting out these help files are invaluable.

Your goal is simple: to bring your page to a state where it doesn't generate any errors at all. For bonus points, you could try to eliminate any warnings as well.

As you fix your markup to remove one error, you may find that you generate more-- or that suddenly several other errors go away. For example, if you add a missing end-table tag (</table>) to a document, you might fix every "element not allowed here" error that followed. In any case, the goal of every author should be to have no errors at all of either kind.

DOCTYPE and Validation

Validators typically use a DOCTYPE to choose which standard to validate against. In browsers, a DOCTYPE is only used to switch between quirks mode and standards mode. Before you validate your document, it is important to have a correct DOCTYPE for mainly two reasons:

  • If browsers use quirks mode, validating your document will not help you make it behave the same in different browsers. Browsers deliberately act differently in this mode due to backwards compatibility.
  • If you validate your code against a different standard than the one used by browsers, validation will just lead you in the wrong direction.

The DOCTYPE must be placed in the top of your HTML document like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset=UTF-8>
    <title>Hello World!</title>
  </head>
  <body>
  </body>
</html>

This example uses the HTML5 doctype. There are several good reasons to validate against HTML5 rather than the older HTML4 or XHTML standards, even if your HTML document does not use any of the new features introduced in HTML5.

  • HTML5 is the standard modern browsers are trying to implement. Validating against HTML4 may put you in the wrong direction, as it may give you advice that is no longer correct in HTML5 and has never been correct in browser implementations.
  • Validating against XHTML will most likely lead you in the wrong direction, since your document is most likely not interpreted as XHTML.
  • Validation is not the best method to ensure backwards compatibility with older HTML4 browsers, as those browsers are typically less standards compliant.
  • Great care has been taken to make HTML5 backwards compatible with older browser implementations.

Once you've added this element to the top of your document, then you can use the Document Type option "(specified inline)" and the W3C validator will use the DTD you've declared in your document to validate the markup.

Common Problems

There are a few errors that authors will likely see many, many times as they validate pages. There are also a few things that a validator might not catch (software is generally as perfect as the humans who write it). Here are a few of the most common errors and pitfalls to avoid.

Forgetting Important Attributes

If you get an attribute-related error, it's very likely going to tell you that you forgot to include a required attribute. These include:

  • the alt attribute for the elements img and area

The alt attribute is important for accessibility reasons, as its inclusion assists users who are using text-only or audio browsers.

Improper Nesting of Elements

Over the years, authors have developed a number of tricks that get the effects they want with a minimum of typing, and which avoid certain display effects. Unfortunately, some of these are based on wholly invalid markup and will cause a validator to choke. They'll also lead to display and functionality problems in standards mode.

One example is wrapping an inline element like span around one or more block-level elements like div, which is not allowed. For example the following markup is structurally incorrect:

<span>
<div>A block level element in an inline element</div>
</span>

On a related note, some authors like to avoid the "white space" that the form element introduces inside table cells by doing something like this:

<table>
<form action="script.cgi" method="get">
<tr><td>(...form widgets here...)</td></tr>
</form>
</table>

That will trigger an error because you can't put FORM inside a table but outside a table cell. You could wrap the form element around the entire table, or put the form into the table cell and use CSS to set its margins to zero-- but in that case the entire form would have to be placed within that single table cell. If you're using a table to lay out your form, then you need to wrap it around the whole table, or around an entire section of the document if that's feasible.

Improper Comments

Although it may seem picky, it is important to be sure that you format your HTML comments correctly. The correct form of an HTML comment is:

<!-- comment -->

That's two dashes at either end, not three as some authors like to include. In general, you should avoid any sequence of dashes within a comment, and stick to the allowed pair of dashes to help mark the beginning and end of the comment. (See HTML 4.01, section 3.2.4 for more information.)

Ampersands

Because the ampersand character (&) is reserved for marking character entities, authors should never use raw ampersands in their HTML source-- and that includes ampersands inside URLs! Thus, any URL that needs an ampersand should be written like this:

http://www.example.com/path/doc.html?var1=val1&amp;var2=val2&amp;var3=val3

Each instance of &amp; will be translated by a Web browser into an ampersand, without triggering validation warnings.

Attribute Value Presence and Quotation

If you're validating against an XHTML DOCTYPE, then all of your attributes must have values, and all of these values must be enclosed in quotation marks. You must also close every element you open, so in those cases where there is no close tag, the end of the element should include a forward-slash. These are requirements of XHTML (and with XML-based languages in general), and so the validator will flag any instance where you do not follow these rules. One example of valid XHTML markup that will differ noticeably from historical HTML:

<input type="checkbox" checked="checked" name="prefSys" value="MacOS" />

Note the addition of a (quoted) value to checked and the slash at the end of the tag. Without these additions, this markup fragment would not be valid XHTML.

Warning: Please make sure that your are actually using XHTML and understand its limits before you validate your document against XHTML.

The font element is deprecated

The purpose of the deprecated font element was to specify typeface, color and size of the enclosed text. This is however much better done with CSS. The quickest way is to directly replace the font element with a span element and add the style as inline CSS:

<p><font color="blue" face="Helvetica">
A really <font size="+1">big</font> shoe.
</font></p>

... becomes:

<p><span style="color: blue; font-family: Helvetica, sans-serif;">
A really <span style="font-size: larger;">big</span> shoe.
</span></p>

... or even more concisely:

<p style="color: blue; font-family: Helvetica, sans-serif;">
A really <span style="font-size: larger;">big</span> shoe.</p>

This is appropriate usage for a local change to the font. However, this is not the best use of styles; the strength of CSS lies in the ability to gather text and other styling into logical groupings that can be applied across a document, without repeating the specific styling on every element that requires it.

More on conversion of <FONT>: W3C Quality Assurance tip for webmaster: Care With Font Size, Forget <font> and use CSS

The center element and align attribute are deprecated

The CSS1 text-align property specifies how text or inline elements (like an image) are aligned within an element.

<p style="text-align: center;"><img src="..." width="..."
height="..." alt="..."></p>
// will center the image inside the <p> element

CSS margin-left: auto; margin-right: auto; properties will center a block-level element within its containing block. Defining margin-left and margin-right is for block-level elements. When both margin-left and margin-right are auto, they are set to equal values, thus centering a block-level element within its parent.
CSS1 horizontal formating

Worth mentioning is the excellent tutorial:
Centring using CSS by David Dorward
Also Interactive demo on CSS horizontal alignment and horizontal formating by Gérard Talbot

The bgcolor attribute is deprecated

The bgcolor attribute can be replaced with CSS1 background-color property.

If you have

<td bgcolor="green" width="150">
... content here ...
</td>

... can replace it with:

<td style="background-color: green;" width="150">
... content here ...
</td>

How to upgrade markup code in specific cases: <embed>, <applet>, <marquee>, <bgsound>

What if I use <embed> for Flash or for a video?

Explaining in details how to do this would go beyond the scope of this article. Nevertheless, we recommend the following articles so that you can have a Flash movie or a video in your web page and, at the same time, have your page validate.

What if I use <applet>?

We recommend these resources:

Worth mentioning here: Java Upgrade Guide: Migrating From the Microsoft VM for Java to the Sun JRE http://java.sun.com/j2se/1.4.2/docs/...ide/index.html "after December, 2007, Microsoft will no longer support or provide a Java implementation with any of its products. (...) Those running applets in the Internet Explorer web browser will need to download and install an alternate VM."

What if I use <marquee>?

Marquee can be replaced with content string inside a <div> or <span> rotating over time with Javascript and DOM level 1. It must be said that this sort of effect is discouraged. Studies have shown that constantly moving objects or moving text disturb reading and weakens peripherical vision. DHTML marquee also greatly consumes user system resources (cpu, RAM) on tested browsers and will put modest systems under considerable stress. If after webpage assessment and consideration, you still want to include a marquee effect in your page, then you can use the following recommendable tutorials:
Cross-browser and web standard compliant Stock Ticker example by D. Rosenberg
Comprehensive web standard compliant alternative to <marquee> by D. Rosenberg
Firefox 2 and Firefox 3 support the non-standard <marquee> element. On the other hand, Firefox users can disable such support by customizing an userContent.css

What if I have <bgsound>?

Then use HTML 4.01 OBJECT, e.g.:
<OBJECT data="audiofile.wav" type="audio/wav" ...></OBJECT>
See this DevEdge article for information on rendering a sound OBJECT invisible within the page.
Web page background sound often slows down considerably web page loading; like the text effects above, music or sound accompanying a page is seldom appreciated. According to the survey page What we really hate on the web, 41.9% of survey respondents will avoid sites that automatically play music; 71.1% strongly dislike sites that automatically play music.
Why Playing Music on your Web Site is a Bad Idea by A. Gulez

Conclusion

Although it may seem like more work at first, validating your markup now will pay off handsomely in saved time and effort later. Not only will your documents stand a much better chance of being properly displayed in all current and future browsers, but it will be much easier to maintain your documents, or even to convert them from HTML to another markup language such as XML.

Although the ideal goal is to have pages that generate no validation errors and no warnings, your primary concern should be the elimination of actual errors. Once you've cleaned things up so that you no longer get errors, then you can turn to the task of styling the document and feel confident that the page will display in just about any known browser, as well as any decent browser to come.

Also On MDC

Related Links

Original Document Information

  • Author(s): Eric A. Meyer, Netscape Communications
  • Last Updated Date: Published 05 Mar 2001
  • Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.
  • Note: This reprinted article was originally part of the DevEdge site.

{{ languages( { "it": "it/Libert\u00e0!_Uguaglianza!_Validit\u00e0!", "es": "es/\u00a1Libertad,_Igualdad,_Validez!", "fr": "fr/Libert\u00e9_!_\u00c9galit\u00e9_!_Validit\u00e9_!" } ) }}

Revision Source

<p>If you are not careful, you risk building your web pages on assumptions of browser behavior, that were never intentional, never documented and likely to not hold in the future. These assumptions are called quirks, and should be avoided in your web pages. Quirks may cause web pages to behave differently in different browsers, and even different versions of the same browser.</p>
<p>One way to help you make web pages, that work across multiple browsers is to use an HTML validator, that can help you identify problems and quickly correct them. An often used validator is the <a class="external" href="http://validator.w3.org/">World Wide Web Consortium's HTML Validator</a>. It's provided by the same people who are responsible for the HTML specification, and more importantly most of its error messages provide a link to an explanation of what the error means. Eventually, of course, you'll recognize what each error message means without having to look up the explanation, but when you're starting out these help files are invaluable.</p>
<p>Your goal is simple: to bring your page to a state where it doesn't generate any errors at all. For bonus points, you could try to eliminate any warnings as well.</p>
<p>As you fix your markup to remove one error, you may find that you generate more-- or that suddenly several other errors go away. For example, if you add a missing end-table tag (<span class="nowiki">&lt;/table&gt;</span>) to a document, you might fix every "element not allowed here" error that followed. In any case, the goal of every author should be to have no errors at all of either kind.</p>
<h3 name="DOCTYPE_and_Validation">DOCTYPE and Validation</h3>
<p>Validators typically use a <code>DOCTYPE</code> to choose which standard to validate against. In browsers, a <code>DOCTYPE</code> is only used to switch between <a href="/en/Quirks_Mode_and_Standards_Mode" title="Quirks Mode and Standards Mode">quirks mode and standards mode</a>. Before you validate your document, it is important to have a correct <code>DOCTYPE</code> for mainly two reasons:</p>
<ul> <li>If browsers use quirks mode, validating your document will not help you make it behave the same in different browsers. Browsers deliberately act differently in this mode due to backwards compatibility.</li> <li>If you validate your code against a different standard than the one used by browsers, validation will just lead you in the wrong direction.</li>
</ul>
<p>The DOCTYPE must be placed in the top of your HTML document like this:</p>
<pre>&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;meta charset=UTF-8&gt;
    &lt;title&gt;Hello World!&lt;/title&gt;
  &lt;/head&gt;
  &lt;body&gt;
  &lt;/body&gt;
&lt;/html&gt;
</pre>
<p>This example uses the HTML5 doctype. There are several good reasons to validate against HTML5 rather than the older HTML4 or XHTML standards, even if your HTML document does not use any of the new features introduced in HTML5.</p>
<ul> <li>HTML5 is the standard modern browsers are trying to implement. Validating against HTML4 may put you in the wrong direction, as it may give you advice that is no longer correct in HTML5 and has never been correct in browser implementations.</li> <li>Validating against XHTML will most likely lead you in the wrong direction, since your document is <a href="/en/XHTML#MIME_type_versus_DOCTYPE" title="en/XHTML#MIME_type_versus_DOCTYPE">most likely not interpreted as XHTML</a>.</li> <li>Validation is not the best method to ensure backwards compatibility with older HTML4 browsers, as those browsers are typically less standards compliant.</li> <li>Great care has been taken to make HTML5 backwards compatible with older browser implementations.</li>
</ul>
<p>Once you've added this element to the top of your document, then you can use the Document Type option "(specified inline)" and the W3C validator will use the DTD you've declared in your document to validate the markup.</p>
<h3 name="Common_Problems">Common Problems</h3>
<p>There are a few errors that authors will likely see many, many times as they validate pages. There are also a few things that a validator might not catch (software is generally as perfect as the humans who write it). Here are a few of the most common errors and pitfalls to avoid.</p>
<h4 name="Forgetting_Important_Attributes">Forgetting Important Attributes</h4>
<p>If you get an attribute-related error, it's very likely going to tell you that you forgot to include a required attribute. These include:</p>
<ul> <li>the <code>alt</code> attribute for the elements <code>img</code> and <code>area</code></li>
</ul>
<p>The <code>alt</code> attribute is important for accessibility reasons, as its inclusion assists users who are using text-only or audio browsers.</p>
<h4 name="Improper_Nesting_of_Elements">Improper Nesting of Elements</h4>
<p>Over the years, authors have developed a number of tricks that get the effects they want with a minimum of typing, and which avoid certain display effects. Unfortunately, some of these are based on wholly invalid markup and will cause a validator to choke. They'll also lead to display and functionality problems in standards mode.</p>
<p>One example is wrapping an inline element like <code>span</code> around one or more block-level elements like <code>div</code>, which is not allowed. For example the following markup is structurally incorrect:</p>
<pre>&lt;span&gt;
&lt;div&gt;A block level element in an inline element&lt;/div&gt;
&lt;/span&gt;
</pre>
<p>On a related note, some authors like to avoid the "white space" that the <code>form</code> element introduces inside table cells by doing something like this:</p>
<pre>&lt;table&gt;
&lt;form action="script.cgi" method="get"&gt;
&lt;tr&gt;&lt;td&gt;(...form widgets here...)&lt;/td&gt;&lt;/tr&gt;
&lt;/form&gt;
&lt;/table&gt;
</pre>
<p>That will trigger an error because you can't put <code>FORM</code> inside a table but outside a table cell. You could wrap the <code>form</code> element around the entire table, or put the form into the table cell and use CSS to set its margins to zero-- but in that case the entire form would have to be placed within that single table cell. If you're using a table to lay out your form, then you need to wrap it around the whole table, or around an entire section of the document if that's feasible.</p>
<h4 name="Improper_Comments">Improper Comments</h4>
<p>Although it may seem picky, it is important to be sure that you format your HTML comments correctly. The correct form of an HTML comment is:</p>
<pre>&lt;!-- comment --&gt;</pre>
<p>That's <strong>two</strong> dashes at either end, not three as some authors like to include. In general, you should avoid any sequence of dashes within a comment, and stick to the allowed pair of dashes to help mark the beginning and end of the comment. (See <a class="external" href="http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.4">HTML 4.01, section 3.2.4</a> for more information.)</p>
<h4 name="Ampersands">Ampersands</h4>
<p>Because the ampersand character (<code>&amp;</code>) is reserved for marking character entities, authors should never use raw ampersands in their HTML source-- and that includes ampersands inside URLs! Thus, any URL that needs an ampersand should be written like this:</p>
<pre>http://www.example.com/path/doc.html?var1=val1&amp;amp;var2=val2&amp;amp;var3=val3
</pre>
<p>Each instance of <code>&amp;amp;</code> will be translated by a Web browser into an ampersand, without triggering validation warnings.</p>
<h4 name="Attribute_Value_Presence_and_Quotation">Attribute Value Presence and Quotation</h4>
<p>If you're validating against an XHTML DOCTYPE, then all of your attributes must have values, and all of these values must be enclosed in quotation marks. You must also close every element you open, so in those cases where there is no close tag, the end of the element should include a forward-slash. These are requirements of XHTML (and with XML-based languages in general), and so the validator will flag any instance where you do not follow these rules. One example of valid XHTML markup that will differ noticeably from historical HTML:</p>
<pre>&lt;input type="checkbox" checked="checked" name="prefSys" value="MacOS" /&gt;</pre>
<p>Note the addition of a (quoted) value to <code>checked</code> and the slash at the end of the tag. Without these additions, this markup fragment would not be valid XHTML.</p>
<p>Warning: Please <a href="/en/XHTML" title="en/XHTML">make sure that your are actually using XHTML</a> and understand its limits before you validate your document against XHTML.</p>
<h4 name="I_use_.3Cfont.3E._How_to_define_or_to_replace_.3Cfont.3E_with_CSS.3F">The <code>font</code> element is deprecated</h4>
<p>The purpose of the deprecated <code>font</code> element was to specify typeface, color and size of the enclosed text. This is however much better done with CSS. The quickest way is to directly replace the <code>font</code> element with a <code>span</code> element and add the style as inline CSS:</p>
<pre>&lt;p&gt;&lt;font color="blue" face="Helvetica"&gt;
A really &lt;font size="+1"&gt;big&lt;/font&gt; shoe.
&lt;/font&gt;&lt;/p&gt;</pre>
<p>... becomes:</p>
<pre>&lt;p&gt;&lt;span style="color: blue; font-family: Helvetica, sans-serif;"&gt;
A really &lt;span style="font-size: larger;"&gt;big&lt;/span&gt; shoe.
&lt;/span&gt;&lt;/p&gt;</pre>
<p>... or even more concisely:</p>
<pre>&lt;p style="color: blue; font-family: Helvetica, sans-serif;"&gt;
A really &lt;span style="font-size: larger;"&gt;big&lt;/span&gt; shoe.&lt;/p&gt;</pre>
<p>This is appropriate usage for a local change to the font. However, this is not the best use of styles; the strength of CSS lies in the ability to gather text and other styling into logical groupings that can be applied across a document, without repeating the specific styling on every element that requires it.</p>
<p>More on conversion of &lt;FONT&gt;: <a class="external" href="http://www.w3.org/QA/Tips/font-size#css">W3C Quality Assurance tip for webmaster: Care With Font Size, Forget &lt;font&gt; and use CSS</a></p>
<h4 name="I_use_.3Ccenter.3E_or_align.3D.22center.22._How_to_align_with_CSS.3F">The <code>center</code> element and <code>align</code> attribute are deprecated</h4>
<p>The <a class="external" href="http://www.w3.org/TR/REC-CSS1#text-align">CSS1 text-align property</a> specifies how text or inline elements (like an image) are aligned within an element.</p>
<pre>&lt;p style="text-align: center;"&gt;&lt;img src="..." width="..."
height="..." alt="..."&gt;&lt;/p&gt;
// will center the image inside the &lt;p&gt; element</pre>
<p>CSS <code>margin-left: auto; margin-right: auto;</code> properties will center a block-level element within its containing block. Defining margin-left and margin-right is for block-level elements. When both <code>margin-left</code> and <code>margin-right</code> are <code>auto</code>, they are set to equal values, thus centering a block-level element within its parent.<br> <a class="external" href="http://www.w3.org/TR/REC-CSS1#horizontal-formatting">CSS1 horizontal formating</a></p>
<p>Worth mentioning is the excellent tutorial:<br> <a class="external" href="http://dorward.me.uk/www/centre/">Centring using CSS</a> by David Dorward<br> Also <a class="external" href="http://www.gtalbot.org/NvuSection/NvuWebDesignTips/HorizontalAlignment.html">Interactive demo on CSS horizontal alignment and horizontal formating</a> by Gérard Talbot</p>
<h4 name="How_to_replace_bgcolor.3F_How_to_colorize_background_with_CSS.3F">The <code>bgcolor</code> attribute is deprecated</h4>
<p>The <code>bgcolor</code> attribute can be replaced with <a class="external" href="http://www.w3.org/TR/CSS1#background-color">CSS1 background-color property</a>.</p>
<p>If you have</p>
<pre>&lt;td bgcolor="green" width="150"&gt;
... content here ...
&lt;/td&gt;</pre>
<p>... can replace it with:</p>
<pre>&lt;td style="background-color: green;" width="150"&gt;
... content here ...
&lt;/td&gt;</pre>
<h4 name="How_to_upgrade_markup_code_in_specific_cases:_.3Cembed.3E.2C_.3Capplet.3E.2C_.3Cmarquee.3E.2C_.3Cbgsound.3E">How to upgrade markup code in specific cases: <code>&lt;embed&gt;</code>, <code>&lt;applet&gt;</code>, <code>&lt;marquee&gt;</code>, <code>&lt;bgsound&gt;</code></h4>
<h5 name="What_if_I_use_.3Cembed.3E_for_Flash_or_for_a_video.3F">What if I use <code>&lt;embed&gt;</code> for Flash or for a video?</h5>
<p>Explaining in details how to do this would go beyond the scope of this article. Nevertheless, we recommend the following articles so that you can have a Flash movie or a video in your web page and, at the same time, have your page validate.</p>
<ul> <li><a class="external" href="http://www.alistapart.com/articles/flashsatay">Embedding Flash While Supporting Standards</a> by Drew McLellan, November 2002</li> <li><a class="external" href="http://www.alistapart.com/articles/byebyeembed">Bye Bye Embed: Embedding a video</a> by Elizabeth Castro, July 2006</li> <li><a class="external" href="http://wiki.dreamhost.com/index.php/Object_Embedding">Embedding Object with valid code</a> by MediaWiki, March 2007</li> <li><a class="external" href="http://ln.hixie.ch/?start=1081798064&amp;count=1">Embedding flash without &lt;embed&gt;</a> by Ian "Hixie" Hickson, April 2004</li> <li><a class="external" href="http://alistapart.com/articles/flashembedcagematch">Flash Embedding Cage Match</a> by Bobby van der Sluis, February 2006</li>
</ul>
<h5 name="What_if_I_use_.3Capplet.3E.3F">What if I use <code>&lt;applet&gt;</code>?</h5>
<p>We recommend these resources:</p>
<ul> <li><a class="external" href="http://ww2.cs.fsu.edu/%7Esteele/XHTML/appletObject.html">Java applet using &lt;object&gt; tag</a> by Shayne Steele</li> <li><a class="external" href="http://www.w3.org/TR/html401/struct/objects.html#edef-APPLET">HTML 4.01 on Including an applet</a></li> <li><a class="external" href="http://www.w3.org/TR/html401/struct/objects.html#edef-OBJECT">HTML 4.01 on Including an object</a></li>
</ul>
<p><span class="comment">Worth mentioning here: Java Upgrade Guide: Migrating From the Microsoft VM for Java to the Sun JRE <a class=" external" href="http://java.sun.com/j2se/1.4.2/docs/guide/deployment/deployment-guide/upgrade-guide/index.html" rel="freelink">http://java.sun.com/j2se/1.4.2/docs/...ide/index.html</a> "after December, 2007, Microsoft will no longer support or provide a Java implementation with any of its products. (...) Those running applets in the Internet Explorer web browser will need to download and install an alternate VM."</span></p>
<h5 name="What_if_I_use_.3Cmarquee.3E.3F">What if I use <code>&lt;marquee&gt;</code>?</h5>
<p>Marquee can be replaced with content string inside a <code>&lt;div&gt;</code> or <code>&lt;span&gt;</code> rotating over time with Javascript and DOM level 1. It must be said that this sort of effect is discouraged. Studies have shown that <strong>constantly moving objects or moving text disturb reading and weakens peripherical vision</strong>. DHTML marquee also <strong>greatly consumes user system resources (cpu, RAM)</strong> on tested browsers and will put modest systems under considerable stress. If after webpage assessment and consideration, you still want to include a marquee effect in your page, then you can use the following recommendable tutorials:<br> <a class="external" href="http://devedge-temp.mozilla.org/toolbox/examples/2001/stock-ticker/" title="http://devedge-temp.mozilla.org/toolbox/examples/2001/stock-ticker/">Cross-browser and web standard compliant Stock Ticker example</a> by D. Rosenberg<br> <a class="external" href="http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/index_en.html">Comprehensive web standard compliant alternative to &lt;marquee&gt;</a> by D. Rosenberg<br> Firefox 2 and Firefox 3 support the non-standard <code>&lt;marquee&gt;</code> element. On the other hand, Firefox users can disable such support by <a class="external" href="http://www.mozilla.org/unix/customizing.html#userContent">customizing an userContent.css</a></p>
<h5 name="What_if_I_have_.3Cbgsound.3E.3F">What if I have <code>&lt;bgsound&gt;</code>?</h5>
<p>Then use HTML 4.01 <code>OBJECT</code>, e.g.:<br> <code>&lt;OBJECT data="audiofile.wav" type="audio/wav" ...&gt;&lt;/OBJECT&gt;</code><br> See <a class="external" href="http://devedge-temp.mozilla.org/library/manuals/2002/plugin/1.0/intro.html#1003240">this DevEdge article</a> for information on rendering a sound OBJECT invisible within the page.<br> Web page background sound often slows down considerably web page loading; like the text effects above, music or sound accompanying a page is seldom appreciated. According to the survey page <a class="external" href="http://www.lowendmac.com/musings/02/0528.html">What we really hate on the web</a>, 41.9% of survey respondents will avoid sites that automatically play music; 71.1% strongly dislike sites that automatically play music.<br> <a class="external" href="http://www.wowwebdesigns.com/power_guides/music_off.php">Why Playing Music on your Web Site is a Bad Idea</a> by A. Gulez</p>
<h3 name="Conclusion">Conclusion</h3>
<p>Although it may seem like more work at first, validating your markup now will pay off handsomely in saved time and effort later. Not only will your documents stand a much better chance of being properly displayed in all current and future browsers, but it will be much easier to maintain your documents, or even to convert them from HTML to another markup language such as XML.</p>
<p>Although the ideal goal is to have pages that generate no validation errors and no warnings, your primary concern should be the elimination of actual errors. Once you've cleaned things up so that you no longer get errors, then you can turn to the task of styling the document and feel confident that the page will display in just about any known browser, as well as any decent browser to come.</p>
<h3 name="Also_On_MDC">Also On MDC</h3>
<ul> <li><a href="/en/Case_Sensitivity_in_class_and_id_Names" title="en/Case_Sensitivity_in_class_and_id_Names">Case Sensitivity in <code>class</code> and <code>id</code> Names</a></li>
</ul>
<h3 name="Related_Links">Related Links</h3>
<ul> <li><a class="external" href="http://validator.w3.org/">The W3C's HTML Validator</a></li> <li><a class="external" href="http://www.w3.org/QA/2002/04/valid-dtd-list.html">W3C DTD List</a></li> <li><a class="external" href="http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.4">HTML 4.01, section 3.2.4</a></li> <li><a href="/en/Quirks_Mode_and_Standards_Mode" title="en/Quirks_Mode_and_Standards_Mode">Mozilla's Quirks Mode</a></li> <li><a class="external" href="http://www.oreillynet.com/pub/a/javascript/synd/2001/08/28/doctype.html">DOCTYPE Explained</a></li>
</ul>
<div class="originaldocinfo"> <h3 name="Original_Document_Information">Original Document Information</h3> <ul> <li>Author(s): Eric A. Meyer, Netscape Communications</li> <li>Last Updated Date: Published 05 Mar 2001</li> <li>Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.</li> <li>Note: This reprinted article was originally part of the DevEdge site.</li> </ul>
</div>
<p>{{ languages( { "it": "it/Libert\u00e0!_Uguaglianza!_Validit\u00e0!", "es": "es/\u00a1Libertad,_Igualdad,_Validez!", "fr": "fr/Libert\u00e9_!_\u00c9galit\u00e9_!_Validit\u00e9_!" } ) }}</p>
Revert to this revision