vladmir
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BeL9ln
Цитата: если мы напишем:
<!doctype html public "-//W3C//DTD HTML 4.0 Strict//EN">
то IE 6.0 установится в режим совместимости со стандартами (в частности CSS-1), то есть он будет вести себя как браузеры Opera, Mozilla и др. |
Мозилла при таком доктайпе переключается в режим обратной совместимости т.к. доктайп без полного абсолютного адреса для браузера равнозначен отсутствию доктайпа.
Цитата:| в режиме совместимости со стандартами, таблица не растянется по всей высоте, хотя четко указано что height="100%". |
А в спецификацию посмотри - есть там height="100%" ?
Вот почитай для расширения кругозора:
====:====+--+--+--+--+--+====:====
====:====+--+--+--+--+--+====:====
Jennifer Niederst, Web Design in a Nutshell, published September 2001
9.2.1. The Document Type Declaration
In order to be valid (i.e., to conform precisely to the HTML standard), an HTML document needs to begin with a document type declaration that identifies the version of HTML that is used in the document. There are three distinct versions of HTML 4.01 (Strict, Transitional, and Frameset), each defined by a distinct document type definition (DTD). The DTD documents live on the W3C server at a stable URL.
The document's DTD is specified at the beginning of the document using the SGML declaration <!DOCTYPE> (document type). The remainder of the declaration contains two methods for pointing to DTD information: one a publicly recognized document, the other a specific URL in case the browsing device does not recognize the public identifier.
Strict
If you are following the Strict version of HTML 4.01 (the version that omits all deprecated and browser-specific tags), use this document type definition:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/HTML4.01/strict.dtd">
Transitional
If your document includes deprecated tags, point to the Transitional DTD using this document type definition:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/HTML4.01/loose.dtd">
Frameset
If your document uses frames, then identify the Frameset DTD. The Frameset DTD is the same as the Transitional version (it includes deprecated yet supported tags), with the addition of frame-specific tags.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/HTML4.01/frameset.dtd">
==
DOCTYPE and Standards-Compliant Browsers
Until recently, it was recommended that HTML documents begin with a DOCTYPE declaration, but it wasn't put to much practical use. That has changed, and now you can use DOCTYPE to make the latest browser versions live up to their full potential.
Netscape 6, Internet Explorer 6 (Windows), and Internet Explorer 5 (Mac) switch into a strict, standards-compliant mode when they detect a DOCTYPE specifying the Strict HTML 4.01 DTD. By placing this declaration at the beginning of your document, you can write your documents and style sheets according to the standards and have confidence that they will work the way they should in these latest browsers. This is a great way to get started using standards-compliant code right away.
If the DOCTYPE declaration is missing or set to Transitional, these browsers revert to their legacy behavior of allowing the nonstandard code, intricate hacks, and common workarounds that are common in current web authoring practices. This allows new browsers to display existing documents properly.
====:====+--+--+--+--+--+====:====
====:====+--+--+--+--+--+====:====
Jeffrey Zeldman, Designing With Web Standards , Pub Date : June 05, 2003
Chapter Eleven. Working with Browsers Part I: DOCTYPE Switching and Standards Mode
How do today's browsers "know" when you've created a forward-compatible site? How can they display your standards-based site correctly when they must also do a decent job of supporting antiquated sites built with outdated methods?
The answer is that most modern browsers use our old friend the DOCTYPE, whose acquaintance we made in Chapter 6, "XHTML: Restructuring the Web to toggle between Standards mode (where your site works as W3C specs say it should) and backward-compatible Quirks mode (so named because old-school sites are authored to the quirks of variously incompatible browsers). If you want to control how your site looks and behaves, this chapter is for you.
To keep things interesting, Standards mode in Gecko browsers like Mozilla and Netscape works slightly differently from Standards mode in Internet Explorer, and these slight differences can have a profound and unexpected influence on your layout. To smooth over potential problems (and to make things even more interesting), later Gecko browsers such as Mozilla 1.01+ and Netscape 7 add a third mode that works more like IE's Standards mode. (Making life still more exciting, Opera 7 has implemented DOCTYPE switching as well, although how it works is anyone's guess as this book goes to press.)
Gecko browsers call this third, IE-like mode "Almost Standards." The name is not meant to insult IE's Standards mode—at least, we don't think it's meant to do that—but to indicate that in the view of Gecko's standards experts, the visual behavior most of us expect from our browsers differs from the letter of the law laid down by CSS specifications.
This chapter explains how the various modes work and provides a simple method of ensuring that your site looks the way you want it to despite differences in the way good browsers interpret CSS and other specs. If you've converted a transitional (tables plus CSS) site to XHTML, discovered that after doing so some browsers treat your layout differently, and wondered why the browsers changed your layout and what you can do to change it back, this chapter has your name all over it.
"The Saga of DOCTYPE Switching" that follows explains why most browsers needed a toggle to alternate between Standards and Quirks modes, and how they came to choose the humble DOCTYPE as the switch. If you're the kind of person who likes to know where things come from and why they are as they are, read on. If you prefer to bypass the background data and get right to the tips and techniques, kindly skip the next couple of pages and proceed directly to "Controlling Browser Performance: The DOCTYPE Switch."
===
The Saga of DOCTYPE Switching
In the late 1990s, as leading browser makers recognized that complete and accurate support for web standards was important to their customers who designed and built websites, they asked themselves how they could fashion new browsers that supported standards correctly without ruining old, noncompliant sites in the process.
After all, existing versions of Netscape and Explorer had persuaded legions of designers to learn their particular quirks, including proprietary extensions to HTML, partial and incorrect CSS implementations, and manufacturer-specific scripting languages. Microsoft and Netscape were willing to do a much better job of supporting standards, but not if it meant breaking billions of dollars worth of existing sites. For a browser maker, that would be suicide.
An example might help explain the browser makers' dilemma.
In the mid-1990s, when early versions of Internet Explorer began to partially support CSS1, they naturally got a few things wrong, such as the box model (explained in Chapter 12, "Working with Browsers Part II: Box Models, Bugs, and Workarounds"). First drafts are always rough, and Microsoft is to be commended for beginning to support CSS at the dawn of 1997.
But commendable or not, Microsoft's early misinterpretation of the CSS box model posed a problem. Tens of thousands of designers had already "learned" the incorrect box model used by IE4.x and IE5.x and had tailored their CSS to display appropriately in those versions of IE. If later versions of IE, let alone other manufacturers' browsers, supported the box model more accurately, existing designs would surely fall apart, to the displeasure of client, builder, and user alike. What to do?
A Switch to Turn Standards On or Off
Even before Netscape and Microsoft agreed to build browsers that supported standards more accurately and completely, an unsung hero had solved the problem of gently handling sites built with noncompliant methods. That hero was user interface technologist Todd Fahrner, a contributor to the W3C's CSS and HTML working groups and cofounder of The Web Standards project. You will find Fahrner's name scattered about the pages of this book, and you will also find it in this book's index if the indexers have done their job.
In early 1998, on an obscure W3C mailing list (all W3C mailing lists are fairly obscure, of course, but the adjective lends a certain mystique to our story), Fahrner proposed that browser makers incorporate a switching mechanism capable of toggling standards-compliant rendering on or off. He suggested that the presence or absence of a DOCTYPE be used as the on/off switch.
If a web page's markup began with a DOCTYPE, Fahrner reasoned, the odds were high that its author knew about and had made an attempt to comply with standards. Browsers should parse such a web page according to W3C specs. By contrast, a DOCTYPE-free page could not pass W3C validation tests (http://validator.w3.org/) and would most certainly have been built using old-school methods. Browsers should treat it accordingly; that is, they should display that web page the way older, noncompliant browsers handled such pages.
One problem remained: There were no standards-compatible browsers. The world would have to wait two years to see if DOCTYPE switching held the key to forward and backward compatibility. (But you don't even have to wait two minutes. Read the next paragraph.)
Throwing the Switch
In March 2000, Microsoft released IE5 Macintosh Edition, whose Tasman rendering engine, created by Microsoft engineer and W3C standards geek Tantek çelik, provided substantially accurate and mostly complete support for standards, including CSS1, XHTML, and the DOM. IE5/Macintosh included Text Zoom to enhance accessibility, and it was the first browser to use DOCTYPE switching to toggle between Quirks and Standards modes.
Busily creating their own innovations and preparing to release their own standards-compliant browser family, the engineers who were working on Gecko-based browsers knew two good things (DOCTYPE switching and Text Zoom) when they saw them. Gecko browsers including Netscape 6, Mozilla, and Chimera, released soon after IE5/Mac, included DOCTYPE switching and Text Zoom, along with the rigorous and detailed standards support made possible by the Gecko/Mozilla rendering engine (http://www.mozilla.org/newlayout/).
When IE6/Windows joined its standards-compliant peers, it likewise supported DOCTYPE switching and added a DOM property that could show whether or not Standards mode was switched on for a given web document (http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.asp).
No Toggle for Opera
Prior to version 7.0, the Opera Software's Opera browser did not play by these rules; it always attempted to render pages in standards-compliant mode, no matter how the pages might have been authored. Versions of the Opera browser prior to 7.0 also did not support the W3C DOM; therefore, compliant sites that use DOM-based scripting do not work correctly in older Opera browsers. Fortunately, Opera users are a self-selecting group that tends to download improved Opera versions as soon as they are released. And, as mentioned earlier, Opera 7.0 now has DOCTYPE switching, although the company has not yet documented how it works. (Does it work like IE's DOCTYPE switching? Like Mozilla/Netscape's? Or some third way? We will all have to wait and see.)
===
Controlling Browser Performance: The DOCTYPE Switch
As explained earlier, most modern browsers use the presence or absence of certain DOCTYPEs to toggle between rigorous standards compliance and fault-tolerant, backward-compatible display. Browser implementations and details differ, but the gist of DOCTYPE switching follows the outline Todd Fahrner sketched back in 1998, when standards-compliant browsers were barely a gleam in developers' eyes. Here's a simplified overview of how it works:
An XHTML DOCTYPE that includes a full URI (a complete web address) tells IE and Gecko browsers to render your page in Standards mode, treating your CSS and XHTML per W3C specs. Some complete HTML 4 DOCTYPES also trigger Standards mode, as discussed a few pages from now. In Standards mode, the browser assumes that you know what you're doing.
Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into Quirks mode, where they assume (probably correctly) that you've written old-fashioned, invalid markup and browser-specific, nonstandard code. In this setting, browsers attempt to parse your page in backward-compatible fashion, rendering your CSS as it might have looked in IE4/5 and reverting to a proprietary, browser–specific DOM.
To control which tack the browser takes, simply include or omit a complete DOCTYPE. It's that easy. Almost.
Three Modes for Sister Sara
For reasons we'll explain later in this chapter, newer Gecko browsers toggle between three modes: Quirks (as described earlier), Almost Standards (equivalent to Standards mode in IE), and Standards (slightly different from IE's Standards mode in one or two key particulars). Also, some DOCTYPEs that trigger Standards mode in early Gecko browsers instead trigger Almost Standards mode in later Gecko browsers.
To the uninitiated, this might appear deeply and painfully confusing, but a few pages from now, you will find it cruelly and brutally confusing. Nonetheless, there are legitimate reasons for it, and, just as importantly, there are also good, easy workarounds that help ensure correct display not only in browsers that use various methods of DOCTYPE switching, but also in browsers like Opera 5/6 that don't use DOCTYPE switching at all. Hang in there and read on. Together we will get through this.
Before we probe the fine points of browser differences, let's study what browsers have in common.
Complete and Incomplete DOCTYPEs
Browsers that use DOCTYPE switching look for complete DOCTYPEs. That is to say, they look for DOCTYPEs that include a complete web address such as http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd. The following DOCTYPE triggers Standards mode in any modern browser that employs DOCTYPE switching:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Yes, this is a Strict DOCTYPE, and yes, we've been promoting the use of XHTML 1.0 Transitional so far. We use Strict here because it makes our point without a heap of caveats, which we'll get to soon enough. Our point right now is that a complete DOCTYPE like the preceding one will trigger Standards mode.
Alas, many of us write—and many of our authoring programs insert by default—incomplete DOCTYPEs that trigger backward-compatible Quirks mode instead of the desired Standards mode. For instance, many authoring tools insert DOCTYPEs like the following, which they derive from the W3C's own site:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
How does this string of geeky text differ from the one that preceded it?
If you look closely at the last part of the previous DOCTYPE ("DTD/xhtml1-strict.dtd"), you'll see that it is a relative link rather than a complete URI. In fact, it is a relative link to a DTD document on W3C's website. Unless you've copied the W3C's DTD and placed it on your own server in the directory indicated—and nobody does that—the relative link points to nothing at all. Because the DTD resides on W3C's site but not yours, the URI is considered incomplete, and the browser displays your site in Quirks mode.
(Do current browsers actually try to locate and load the DTD? No, they simply recognize the incomplete DOCTYPE from their database and go into Quirks mode. Does this mean that pages at w3.org that use this relative URI DOCTYPE will also be rendered in Quirks mode? It seems like it would mean exactly that. Although the irony is delicious to contemplate, we don't know for sure, and in any case, it's not our problem or yours.)
Now let's look again at the complete version that will trigger the desired Standards mode:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Notice that it includes a complete URI at the end of the tag. You could copy and paste that URI into the address bar of any web browser, and if you did so, you would be able to read the XHTML 1.0 Strict DTD in all of its incomprehensibly geeky glory. Because the URI at the tail end of this DOCTYPE indicates a valid location on the web, DOCTYPE-switching browsers consider this DOCTYPE to be full and complete and render your page in Standards mode.
In an additional wrinkle, please note that Internet Explorer switches into Standards mode in the presence of any XHTML DOCTYPE, whether or not that DOCTYPE includes a full URI. However, an XHTML DOCTYPE that does not include a full URI is technically invalid. Thus, in the discussion that follows, we will encourage you to use a full URI in your DOCTYPE. (After all, why switch into Standards mode if your web page is not valid?)
Prolog Quirks in IE6/Windows
There's an exception to every rule. Even with a complete XHTML DOCTYPE, IE6/Windows will kick back into Quirks mode if you include the optional XML prolog. No, really. That is why we advised you to skip the prolog way back in Chapter 6. You see? We've got your back.
A Complete Listing of Complete XHTML DOCTYPEs
Accurate as of this writing, listed next are the complete XHTML DOCTYPEs that trigger Standards or Almost Standards modes in DOCTYPE-switching browsers. What is Almost Standards mode? Patience. We'll get to that soon.
XHTML 1.0 DTD
XHTML 1.0 Strict— Triggers full-on Standards mode in all browsers that support DOCTYPE switching. Has no effect in Opera pre-7.0 or in versions of IE/Windows before 6.0.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Transitional— Triggers full-on Standards mode in compliant IE browsers (IE6+/Windows, IE5+/Macintosh). Triggers full-on Standards mode in first-generation Gecko browsers (Mozilla 1.0, Netscape 6) and Almost Standards mode in updated Gecko browsers (Mozilla 1.01, Netscape 7+, Chimera 0.6+). Has no effect in Opera pre-7.0 or in versions of IE/Windows before 6.0.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1- transitional.dtd">
XHTML 1.0 Frameset— Triggers full-on Standards mode in compliant IE browsers (IE6+/Windows, IE5+/Macintosh). Triggers full-on Standards mode in first-generation Gecko browsers (Mozilla 1.0, Netscape 6) and Almost Standards mode in updated Gecko browsers (Mozilla 1.01, Netscape 7+, Chimera 0.6+). Has no effect in Opera pre-7.0 or in versions of IE/Windows before 6.0. DOCTYPE switching might affect the way frames are rendered, but if it does so, no browser maker seems to have documented these variants.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1 DTD
XHTML 1.1 (Strict by definition)— Triggers full-on Standards mode in all browsers that support DOCTYPE switching. Has no effect in Opera pre-7.0 or in versions of IE/Windows before 6.0.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Save Your Pretty Fingers
If you dislike trying to type stuff like this out of a book (and who can claim to enjoy it?), feel free to copy and paste from A List Apart's "Fix Your Site with the Right DOCTYPE" (http://www.alistapart.com/stories/doctype/).
Executive Summary: XHTML DOCTYPE Triggers in IE and Gecko
Let's review what we've learned so far:
Any complete XHTML 1 or 1.1 DOCTYPE triggers Standards mode in compliant versions of Internet Explorer (IE5+/Macintosh, IE6+/Windows) and in early Gecko browsers (Netscape 6, Mozilla 1.0).
A complete, Strict XHTML DOCTYPE has the same effect in all the preceding browsers and in later Gecko browsers (Mozilla 1.01+, Netscape 7, Chimera 0.6+).
A complete XHTML 1.0 Transitional or Frameset DOCTYPE triggers Almost Standards mode in later Gecko browsers.
Incomplete DOCTYPEs that have relative or missing URIs trigger Quirks mode in all browsers that support DOCTYPE switching. They also generate CSS validation errors, but they do not generate XHTML validation errors because of a bug in the W3C's XHTML validation service or a difference between its XHTML and CSS validation services, depending on whom you ask. Okay, forget we said anything except that incomplete DOCTYPEs trigger Quirks mode and CSS validation errors.
Many authoring tools insert incomplete DOCTYPEs by default, thus triggering Quirks mode and generating CSS validation errors.
This author and individual members of The Web Standards Project have contacted makers of popular authoring tools to alert them to the need to insert complete DOCTYPEs by default. We've also requested that W3C publish an easy-to-find listing of complete DOCTYPEs on its website at www.w3.org. Meanwhile, to ensure that your site triggers Standards mode, you might need to manually edit the DOCTYPE that your authoring tool generates when you create a new XHTML page.
DOCTYPE Switching: The Devil Is in the Details
DOCTYPE switching is not limited to XHTML. As mentioned earlier, some complete HTML DOCTYPEs also trigger Standards mode. For instance, IE toggles into Standards mode (and recent Gecko-based browsers toggle into Almost Standards mode) in the presence of a complete HTML 4.01 Strict DOCTYPE:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
But in both IE and Gecko-based browsers, a complete HTML 4.0 DOCTYPE triggers backward-compatible Quirks mode instead. What a difference a 0.1 makes. If these inconsistencies suggest that you are better off authoring your site in XHTML than HTML, hey, we've been saying that all along.
For details on additional DOCTYPES that trigger Standards, Quirks, and Almost Standards mode in recent Gecko browsers, see "Gecko's 'Almost Standards' Mode" at http://devedge.netscape.com/viewsource/2002/almost-standards/. If you find the level of detail overwhelming, stop reading the article and pretend you never saw it. As the next discussion will soon make clear, most of us need not worry about these complexities as long as we author in XHTML 1.0 Transitional or Strict and employ a few simple CSS workarounds described in the following section.
==+=
==+=
Chapter Six. XHTML: Restructuring the Web
...
Converting to XHTML: Simple Rules, Easy Guidelines
Converting from traditional HTML to XHTML 1.0 Transitional is quick and painless, as long as you observe a few simple rules and easy guidelines. (We really can't get enough of that phrase.) If you've written HTML, you can write XHTML. If you've never written HTML, you can still write XHTML. Let's zip through the (simple and easy) basics, shall we? Here are the rules of XHTML.
Open with the Proper DOCTYPE and Namespace
XHTML documents begin with elements that tell browsers how to interpret them and validation services how to test them for conformance. The first of these is the DOCTYPE (short for "document type") declaration. This handy little element informs the validation service which version of XHTML or HTML you're using. For reasons known only to a W3C committee member, the word DOCTYPE is always written in all caps.
Why a DOCTYPE?
XHTML allows designers/developers to author several different types of documents, each bound by different rules. The rules of each type are spelled out within the XHTML specifications in a long piece of text called a document type definition (DTD). Your DOCTYPE declaration informs validation services and modern browsers which DTD you followed in crafting your markup. In turn, this information tells those validation services and browsers how to handle your page.
DOCTYPE declarations are a key component of compliant web pages; your markup and CSS won't validate unless your XHTML source begins with a proper DOCTYPE. In addition, your choice of DOCTYPE affects the way most modern browsers display your site. The results might surprise you if you're not expecting them. In Chapter 11, "Working with Browsers Part I: DOCTYPE Switching and Standards Mode," we'll explain the impact of DOCTYPE in Internet Explorer and in Gecko-based browsers like Netscape, Mozilla, and Camino.
XHTML 1 offers three yummy choices of DTD and three possible DOCTYPE declarations:
Transitional— The comfortable, slightly frowsy DTD whose motto is "live and let live" (see the next section, "Which DOCTYPE Is Your Type?")
Strict— The whip-wielding, mysteriously aloof DTD that flogs you for using presentational markup elements or attributes
Frameset— The one with the '90s haircut; also the one that lets you use frames in your design—which comes to the same thing
Which DOCTYPE Is Your Type?
Of the three flavors listed in the previous section, XHTML 1.0 Transitional is the one that's closest to the HTML we all know and love. That is to say, it's the only one that forgives presentational markup structures and deprecated elements and attributes.
The target attribute to the HREF link is one such bit of deprecated business. If you want linked pages to open in new windows—or even if you don't want that but your client insists—Transitional is the only XHTML DTD that lets you do so with the target attribute:
<p>Visit <a href="http://www.whatever.org" target=
"_blank">whatever.org</a> in a new window.</p>
<p>Visit <a href="http://www.whatever.org/" target=
"bob">whatever.org</a> in a named new window.</p>
To open linked pages in new windows under XHTML 1.0 Strict, you would need to write JavaScript, and you'd also need to make sure the links work in a non-JavaScript-capable environment. Whether you should open linked pages in new windows is beside the point here. The point is that XHTML 1.0 Transitional lets you do so with a minimum of fuss.
XHTML 1.0 Transitional also tolerates background colors applied to table cells and other such stuff you really ought to do with CSS instead of in your markup. If your DOCTYPE declaration states that you've written XHTML 1.0 Strict but your page includes the deprecated bgcolor attribute, validation services will flag it as an error, and some compliant browsers will ignore it (that is, they will not display the background color). By contrast, if you declare that you're following the XHTML 1.0 Transitional DTD, bgcolor will not be marked as an error, and browsers will honor it instead of ignoring it.
In short (well, maybe it's too late for "in short"), XHTML 1.0 Transitional is the perfect DTD for designers who are making the transition to modern web standards. They don't call it Transitional for nothing.
It could be argued that XHTML 1.0 Strict is the best choice for transitioning designers and developers, as it could be argued that joining the Marine Corps is a great way to shed unwanted pounds. Leaping from sloppy old HTML 4 to rigorous XHTML 1.0 Strict will put hair on the chest of your understanding that markup is for structure, not visual effects, and it might be the right decision for you. But for this chapter's (and most readers') purposes, we'll use XHTML 1.0 Transitional. Its DOCTYPE declaration appears next:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The frameset DOCTYPE is used for those documents that have a <frameset> element in them; in fact, you must use this DOCTYPE with your <frameset> documents.
The DOCTYPE declaration must be typed into the top of every XHTML document, before any other code or markup. It precedes the <head> element, the <title> element, the meta elements, and the links to style sheet and JavaScript files. It also, quite naturally, comes before your content. In short, the DOCTYPE declaration precedes everything.
(Standards-savvy readers might wonder why we haven't mentioned an optional element that can come before the DOCTYPE declaration, namely the optional XML prolog. We'll get to it in a few paragraphs.)
Follow DOCTYPE with Namespace
The DOCTYPE declaration is immediately followed by an XHTML namespace declaration that enhances the old-fashioned <html> element:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
A namespace in XML is a collection of element types and attribute names associated with a specific DTD, and the namespace declaration allows you to identify your namespace by pointing to its online location, which in this case is www.w3.org/1999/xhtml. The two additional attributes, in reverse order of appearance, specify that your document is written in English, and that the version of XML you're using is also written in English.
With the DOCTYPE and namespace declarations in place, your XHTML Transitional 1.0 page would start out like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
Cut, Paste, and Go!
If you dislike trying to type markup and code out of books, feel free to view the source at zeldman.com, alistapart.com, or webstandards.org, and copy and paste to your heart's content.
Declare Your Content Type
To be correctly interpreted by browsers and to pass markup validation tests, all XHTML documents must declare the type of character encoding that was used in their creation, be it Unicode, ISO-8859-1 (also known as Latin-1), or what have you.
If you're unfamiliar with character encoding, or if ISO-8859-1 isn't ringing any bells, never fear: We'll discuss that stuff later in this chapter. (See the later section, "Character Encoding: The Dull, The Duller, and the Truly Dull.") For now, all you need to know is this: There are three ways to tell browsers what kind of character encoding you're using, but only one works reliably as of this writing, and it's not one the W3C especially recommends.
The XML Prolog (And How to Skip It)
Many XHTML pages begin with an optional XML prolog, also known as an XML declaration. When used, the XML prolog precedes the DOCTYPE and namespace declarations described earlier, and its mission in life is to specify the version of XML and declare the type of character encoding being used in the page.
The W3C recommends beginning any XML document, including XHTML documents, with an XML prolog. To specify ISO-8859-1 (Latin-1) encoding, for example, you would use the following XML prolog:
<?xml version="1.0" encoding="ISO-8859-1"?>
Nothing complicated is going on here. The tag tells the browser that XML version 1.0 is in use and that the character encoding is ISO-8859-1. About the only thing new or different about this tag is the question mark that opens and closes it.
Unfortunately, many browsers, even those from "nice" homes, can't handle their XML prolog. After imbibing this XML element, they stagger and stumble and soil themselves, bringing shame to their families and eventually losing their place in society.
Actually, the browsers go unpunished. It's your visitors who suffer when the site fails to work correctly. In some cases, your entire site might be invisible to the user. It might even crash the user's browser. In other cases, the site does not crash, but it displays incorrectly. (This is what happens when IE6/Windows encounters the prolog.)
Fortunately, there is a solution. In place of the troublesome prolog, you can specify character encoding by inserting a Content-Type element into the <head> of your document. To specify ISO-8859-1 encoding, type the following:
<meta http-equiv="Content-Type" content="text/html; charset=
ISO-8859-1" />
The beginning of your XHTML document would then look something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Transitional Industries: Working for Change</title>
<meta http-equiv="Content-Type" content="text/html; charset=
ISO-8859-1" />
</head>
If you're working on an international site that will include a plethora of non-ASCII characters, you might author in Unicode and insert the following Content-Type element into your markup:
<meta http-equiv="Content-Type" content="text/html;charset=
UTF-8" />
Again, feel free to view source at zeldman.com, alistapart.com, or webstandards.org and copy and paste.
You might also want to forget all the geeky details of the preceding discussion. Many designers know nothing about these issues aside from which tags to copy and paste into the tops of their templates, and they seem to live perfectly happy and productive lives.
Aside from one even geekier topic to be touched upon with merciful brevity a few pages from now, you have now waded through the brain-addling, pocket-protector-equipped portion of this chapter. Congratulations! The rest will be cake.
====:====+--+--+--+--+--+====:====
====:====+--+--+--+--+--+====:====
Thomas A. Powell, HTML & XHTML: The Complete Reference, Fourth Edition, 2003
Document Types
HTML follows the SGML notation for defining structured documents. From SGML, HTML inherits the requirement that all documents begin with a <!DOCTYPE> declaration. In the most basic sense, this line identifies the HTML "dialect" used in a document by referring to an external document type definition, or DTD. A DTD defines the actual elements, attributes, and element relationships that are valid in documents. The <!DOCTYPE> declaration allows validation software to identify the HTML DTD being followed in a document, and verify that the document is syntactically correct—in other words, that all tags used are part of a particular specification and are being used correctly. The process of validation is discussed in greater depth in Chapter 2.
Note Today browsers are aware of the <!DOCTYPE> and standards-compliant browsers will examine it to determine what rendering mode to enter. This process is often dubbed the "doctype switch" and is used by browsers to quickly determine if a standards-compliant parse of the page should be employed or if the browser should enter into "quirk" mode and assume that a less stringent form of HTML is being used. Because of this, HTML/XHTML document authors should always use the <!DOCTYPE> statement properly.
There are numerous HTML and XHTML DTDs that can be used, corresponding to the various standard versions of HTML in existence. In the past, even some proprietary forms of HTML had their own doctype statements. At the time of this edition's writing, the <!DOCTYPE> most likely in use is either the HTML 4.0 transitional form, as shown here:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
or the HTML 4.01 transitional specification indicated by
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
However, these forms are not quite specific enough and should actually specify the location of the DTD being used, as shown here:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
In the future, the stricter form of HTML—XHTML—probably will be more commonly used. It is indicated by
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
There are numerous document type identifiers that could be used at the start of the document, as shown in Table 1-1.
Table 1-1: Common HTML Doctype Declarations HTML Version
!DOCTYPE Declaration
2.0
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
3.2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
4.0 Transitional
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4.0 Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
4.0 Strict
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
4.01 Transitional
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4.01 Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
4.01 Strict
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
XHTML 1.0 Transitional
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
XHTML 2.0 (still in progress)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" " http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtd ">
Note On occasion, you might see other HTML document type indicators, notably one for the 3.0 standard that was never really adopted in the Web community.
While XHTML is almost certainly the future of HTML, the fact of the matter is there will be multiple forms of HTML in use on the Web for a long time. Document authors should be familiar with the many forms of HTML. A brief explanation of each version of HTML is provided in Table 1-2.
Table 1-2: Description of Common HTML Versions HTML Version
Description
2.0
Classic HTML dialect supported by browsers such as Mosaic. This form of HTML supports core HTML elements and features such as tables and forms but does not consider any of the browser innovations of advanced features such as style sheets, scripting, or frames.
3.0
The proposed replacement for HTML 2.0 that was never widely adopted, most likely due to the heavy use of browser-specific markup.
3.2
An HTML finalized by the W3C in early 1997 that standardized most of the HTML features introduced in browsers such as Netscape 3. This version of HTML supports many presentation elements, such as fonts, as well as early support for some scripting features.
4.0 Transitional
The 4.0 transitional form finalized by the W3C in December of 1997 preserves most of the presentation elements of HTML 3.2. It provides a basis for transition to CSS as well as a base set of elements and attributes for multiple language support, accessibility, and scripting.
4.0 Strict
The strict version of HTML 4.0 removes most of the presentation elements from the HTML specification, such as fonts, in favor of using Cascading Style Sheets (CSS) for page formatting.
4.0 Frameset
The frameset specification provides a rigorous syntax for framed documents that was lacking in previous versions of HTML.
4.01 Transitional/Strict/Frameset
A minor update to the 4.0 standard that corrects some of the errors in the original specification.
XHTML 1.0 Transitional
A reformulation of HTML as an XML application. The transitional form preserves many of the basic presentation features of HTML 4.0 transitional but applies the strict syntax rules of XML to HTML.
XHTML 1.0 Strict
A reformulation of HTML 4.0 strict using XML. This language is rule enforcing and leaves all presentation duties to technologies such as Cascading Style Sheets (CSS).
XHTML 1.1
A minor change to XHTML 1.0 that restructures the definition of XHTML 1.0 to modularize it for easy extension. It is not commonly used at the time of this writing and only offers minor gains over XHTML 1.0.
XHTML 2.0
A new implementation of XHTML circa 2003 that may not provide backward compatibility with XHTML 1.0 and traditional HTML. XHTML 2 will likely remove most or all presentational tags left in HTML and will introduce even more logical ideas to the language.
|
