Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript
Megnut

Web Topics
All Articles
Browsers
ColdFusion
CSS
Database
Flash
Graphics
HTML/XHTML/DHTML
Scripting Languages
Tools
Weblogs

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab






DOCTYPE Explained
Pages: 1, 2

Cascading Style Sheets: The Definitive GuideCascading Style Sheets: The Definitive Guide
By Eric A. Meyer
May 2000
1-56592-622-6, Order Number: 6226
467 pages, $34.95

Here's another example. You may have found that setting font-size: medium results in different font sizes in Explorer versus Navigator. This occurs because of the way the Internet Explorer for Windows team interpreted the intent of the CSS specification. In order to stay consistent with the Windows version, Internet Explorer for the Macintosh emulated its behavior in the 4.x series. If you put IE5/Mac into bugwards compatibility mode, it will continue to treat font-size: medium as IE4.x/Win does. In strict mode however, it will act as Navigator does, which is actually the correct interpretation according to the W3C.



There may be other differences between the two modes, but they are not documented. This is because a thorough documentation of the differences could lead developers to rely on these differences, when they may in fact change or disappear in later versions of Internet Explorer for the Macintosh. In general, developers should either author to the standards, or else accept behavior which is incorrect and which may change in future versions of Internet Explorer for the Macintosh.

Looked at another way, almost all of Chapter 15 of the HTML 4.01 specification refers to deprecated elements. These are the elements which do not appear in the strict version of HTML 4, and which may or may not be recognized when a browser is in strict rendering mode. This does not mean that they will have no effect. In strict mode, a browser should accept the presentational suggestion embodied by the markup and treat it as an equivalent CSS rule, but one which any actual CSS rule can override. For example, assume that you use the boldface element. This is translated by the browser to be the following rule:

b {font-weight: bold;}

This virtual rule is treated as though it appears at the beginning of the document's styles, and it's given a specificity of zero. This means that any actual CSS rules which conflict with the virtual rule will override it. So if you add the following rule to your CSS:

b {font-weight: normal;}

then the boldfaced elements will not actually be boldfaced. If you choose not to define the boldface element in your CSS, then the boldfacing will still take effect. Thus, developers can start using strict mode without too much fear of losing the effects of their legacy markup.

Browser Support

In addition to Internet Explorer 5 for the Macintosh, DOCTYPE switching is also supported by Netscape 6 on the myriad platforms for which it is available.

Conclusion

When you get right down to it, the pros of DOCTYPE switching far outweigh the cons:

  • Pros:
    • Encourages closer adherence to standards.
    • Permits some control over how the browser behaves in handling the document.
    • Moves browsers towards standards compliance without breaking old pages.


  • Cons:
    • Does not fix older browsers (but then, nothing can do that).

Although the benefits of DOCTYPE switching may seem limited, this is merely a short-term problem. As browsers become more capable and free themselves of legacy problems, developers will have an increasing need to understand and use the specifications as they were written, not as browsers mangled them. By employing DOCTYPE switching, developers can get a jump-start on this process.

Eric A. Meyer is a member of the CSS&FP Working Group and the author of Cascading Style Sheets: The Definitive Guide.


Return to the JavaScript and CSS DevCenter.