You’ve done all the right stuff, but your site doesn’t look or work as it should in the latest browsers.
You’ve written valid XHTML and CSS. You’ve used the W3C standard Document Object Model (DOM) to manipulate dynamic page elements. Yet, in browsers designed to support these very standards, your site is failing. A faulty DOCTYPE is likely to blame.
This little article will provide you with DOCTYPEs that work, and explain the practical, real–world effect of these seemingly abstract tags.
WHY A DOCTYPE?#section2
Per HTML and XHTML standards, a DOCTYPE (short for “document type declaration”) informs the validator which version of (X)HTML you’re using, and must appear at the very top of every web page. DOCTYPEs are a key component of compliant web pages: your markup and CSS won’t validate without them.
As mentioned in previous ALA articles (and in other interesting places), DOCTYPES are also essential to the proper rendering and functioning of web documents in compliant browsers like Mozilla, IE5/Mac, and IE6/Win.
A recent DOCTYPE that includes a full URI (a complete web address) tells these browsers to render your page in standards–compliant mode, treating your (X)HTML, CSS, and DOM as you expect them to be treated.
Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into “Quirks” mode, where the browser assumes you’ve written old-fashioned, invalid markup and code per the depressing industry norms of the late 1990s.
In this setting, the browser will attempt to parse your page in backward–compatible fashion, rendering your CSS as it might have looked in IE4, and reverting to a proprietary, browser–specific DOM. (IE reverts to the IE DOM; Mozilla and Netscape 6 revert to who knows what.)
Clearly, this is not what you want. But it is often what you’ll get, due to the preponderance of incorrect or incomplete DOCTYPE information this article hopes to correct.
(Note: The Opera browser does not play by these rules; it always attempts to render pages in standards–compliant mode. Go, Opera! On the other hand, Opera does not yet offer solid support for the W3C DOM. But they’re working on it.) {Ed: Since this article was first published, Opera has delivered the DOM-compliant Opera 7 browser.}
WHERE HAVE ALL THE DOCTYPES GONE?#section3
Since DOCTYPES are vital to the proper functioning of web standards in browsers, and since W3C is a leading creator of web standards, you might expect W3C’s website to provide a listing of proper DOCTYPEs, and you might also expect to be able to find this information quickly and easily in a single location. But as of this writing, you can’t. {Ed. Prompted in part by this article, the W3C now lists standard DOCTYPEs on its site. You will find the listing a few screens into the W3C tutorial, “My Web site is standard. And yours?”}
W3.org is not A List Apart, WebReference, or Webmonkey. It’s not intended to help web designers, developers, and content folks get up to speed on the latest technological recommendations and practices. That’s not its job.
W3C does publish a series of tutorials, though most web developers are unaware of it. Mainly, though, W3C’s site houses a collection of proposals, drafts, and Recommendations, written by geeks for geeks. And when I say geeks, I don’t mean ordinary web professionals like you and me. I mean geeks who make the rest of us look like Grandma on the first day She’s Got Mail.™
You can search for DOCTYPEs all day at w3.org without finding one page that lists them all. And when you do hunt down a DOCTYPE (generally in relation to a particular Recommendation or Working Draft), it’s often one that won’t work on your site.
Scattered throughout W3C’s site are DOCTYPEs with missing URIs, and DOCTYPEs with relative URIs that point to documents on W3C’s own site. Once removed from W3C’s site and used on your web pages, these URIs point to non–existent documents, thus fouling up your best efforts and the browser’s.
For instance, many sites sport this DOCTYPE, copied and pasted directly from w3.org:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
If you look at the last part of the DOCTYPE (“DTD/xhtml1-strict.dtd”), you’ll see that it is a relative link to a document on W3C’s site. Since that document is on W3C’s site but not yours, the URI is useless to the browser.
The DOCTYPE you’d actually want to use is:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">Notice that the latter DOCTYPE includes a complete URI at the end of the tag. Since the tag provides a valid location on the web, the browser knows where to find it, and will render your document in standards–compliant mode.
DOCTYPES THAT WORK#section4
So what DOCTYPEs should we use? Glad you asked. The following complete DOCTYPEs are the ones we need:
HTML 4.01 Strict, Transitional, Frameset#section5
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">XHTML 1.0 Strict, Transitional, Frameset#section6
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">XHTML 1.1 DTD#section7
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">NEXT STEPS#section8
How can you help improve support for standards on the web? Besides bookmarking this page (and copying and pasting these DOCTYPEs for your own use), if your web editor inserts DOCTYPEs, you might want to check them out and compare them to the list above.
Many well–intentioned software makers have cut and pasted incomplete DOCTYPEs from W3C into their software. Result: when you use these programs’ built–in functionality to insert DOCTYPEs in your pages, the browsers go into Quirks mode, undoing all your hard work.
It’s worth contacting the folks who make your favorite authoring package, showing them the proper DOCTYPEs, and politely requesting them to address this issue in an incremental upgrade. (In some cases, you may also be able to modify your editor yourself.)
COMING SOON#section9
We have every reason to believe that W3C’s site will soon sport a handy listing of accurate, usable DOCTYPES and other essential information in an easy–to–find location. In fact, Karl Dubost, Conformance Manager of W3C’s Quality Assurance team, contributed to the information in this little article.
Likewise, when The Web Standards Project relaunches (real soon), it will also provide this information. {Ed. note: The Web Standards Project relaunched in late 2002.}
But sites are being designed and built every day, and you need this information now—so there it is.
Happy authoring and rendering!
Great article! I’ve been searching the W3C and other sites for this information to no avail. Keep up the good work.
IE6 triggers quirks mode if there is an XML declaration present. It requires the XHTML doctype to be the very first line to trigger standards mode.
Copied directly from the article:
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>
Should that have the ‘>’ after //EN” ? Looks like a typo, correct version at http://www.w3.org/TR/xhtml1/#normative (only the > is different). Great article as always!
Some other good DOCTYPE resources:
http://www.oreillynet.com/pub/a/network/2000/04/14/doctype/
http://developer.apple.com/internet/html/doctype.html
http://www.meyerweb.com/eric/dom/dtype/dtype-grid.html
http://www.people.fas.harvard.edu/~dbaron/mozilla/quirklist (Good info about Mozilla quirks)
Straight from the source:
http://mozilla.org/docs/web-developer/quirks/ (I got a laugh out of some of the public identifiers 🙂
http://msdn.microsoft.com/workshop/author/css/overview/cssenhancements.asp
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/quirk.css (Mozilla’s quirks stylesheet! Gotta love the irony.)
> IE6 triggers quirks mode if there is an XML declaration present.
You’ve got to be kidding me. Is this seriously the case? Doesn’t the standard REQUIRE the XML declaration at the top, above the DOCTYPE tag? So, once again we’re thrown into the sitation of having to either write documents that comply with the standards or documents that work in popular browser, but we can’t have both at the same time. Sigh.
I was playing around with the DTDs. When I used the xHTML strict listed in the article, I get an error stating
“Fatal Error: unrecognized {{DOCTYPE}}; unable to check document” Am I doing something wrong or is this another problem I can blame GW. by the way my site validates as xHTML 1.1. have a nice day!
No, the XML declaration is optional, as long as you specifiy the page’s character encoding using a Meta tag, the page will be valid XHTML, even XHTML 1.1
Assuming that the rest of the code is already valid, of course.
good article – thanks, but I’m still unclear as to which doctype to use. The article lists the doctypes for Strict, Transitional, and Frameset, but what are these? – obviously the type of (X)HTML you’re using – but I’m only clear on what version number I’m using – not Strict, Transitional, or Frameset.
Can anybody enlighten me?
Frameset means that the page is a frameset—it doesn’t actually have any content, just frames of other pages.
Transitional is a normal page, but it means that you’re using deprecated (http://www.w3.org/TR/html4/conform.html#deprecated) elements and/or attributes.
Strict is the same as Transitional, but without the deprecated elements/attributes.
So someone clear up what the browser is actually doing when it wants a doctype. Is it actually going out to the URI you state in the doctype, fetching + parsing the information and changing the chartacteristics of it’s rendering because of this? or, is the browser just matching the doctype it sees on the top of your html document to a list of known doctypes it stores and does it that way.
It just seems peculiar that the W3C will allow every single webpage in existence that has a doctype pointed to it to use it’s resouces. Does anyone see the problem with that? (network latency, general download time)
What if, like Netscape did with I believe the RSS doctype, they just decide to move, and tweak it. We’d be quite up the river with no paddle. It also doesn’t make much sense to make web developers to post a doctype locally on a site and make them call the doctype from there. It makes something that should be soooo simple much too complex.
Viddying the doctype itself doesn’t really shed much light on what it actually does.
sort of odd that HTML 4.01 would have a doctype, since aren’t doctypes one of those XML things? 🙂
Nice article, I already knew where the DOCTYPEs were located in the site. But, it’s true; it’s a virtual Indiana Jones type quest just to find them.
Anyway, this article came MINUTES after I was just putting the final touches to a CMS (Content Management Site). At least it’s good to know that I did everything right.
Now, it’s Miller Time!
“So someone clear up what the browser is actually doing when it wants a doctype. Is it actually going out to the URI […]? or, is the browser just matching the doctype it sees on the top of your html document to a list of known doctypes […]”
Pretty unlikely that a browser actually cares whether the URI is valid or not, let alone what’s inside it.
“What if, like Netscape did with I believe the RSS doctype, they just decide to move, and tweak it.”
That’s why they won’t move it 😉
Is there a reason why everyone puts the DOCTYPE declaration on two lines (the URI on the second)? Or is it just because it’s supposed to be easier to read?
>> IE6 triggers quirks mode if there is an XML declaration present.
> You’ve got to be kidding me. Is this seriously the case?
Unfortunately, it is. I’ve confirmed it on my own. The only way to trigger “standards” mode in IE6 is to forego the use of the XML declaration.
> Doesn’t the standard REQUIRE the XML declaration at the top, above the DOCTYPE tag?
If you use both an XML declaration and a DOCTYPE, the XML declaration *must* be on the first line, followed by the DOCTYPE on the second line. But as riffola said, you can lose the XML declaration if you specify the document encoding type in a element. This may not be ideal, but it’s a valid workaround. Our salvation is that Microsoft will have released a new browser version by the time the next version of XML is released and we’re forced to use an XML declaration to comply.
> Is there a reason why everyone puts the DOCTYPE declaration on two lines (the URI on the second)? Or is it just because it’s supposed to be easier to read?
It’s easier to read. Like most anything in XML, the amount of white-space between different parts of an element (element names, attributes, etc.) is irrelevant so long as there is any amount. You can have a dozen spaces, five tabs, and 16 line breaks between each element part and the parser won’t care.
Thanks much for the clarity Greg. I’ve been searching for the answer to the xml-declaration-IE-quirks-mode bug for some time, and had no idea that it could be so obvious a solution.
Good article as well: concise, and informative.
> sort of odd that HTML 4.01 would have a doctype, since aren’t doctypes one of those XML things? 🙂
Nope…they’re one of those SGML things. Even HTML 3.2 has a DOCTYPE.
Another thing that’s been bugging me:
BBEdit likes to use DOCTYPES like this (for XHTML 1.0 Transitional, for example):
which, if you bother to go to the URL specified, contains a proper XHTML DTD (the same one, I’m fairly certain, as if you go to the URL specified in the article). This URL causes browsers to enter standards mode (good), and is valid according to the W3C (X)HTML validator (also good). However, when one attempts to run a page with this DOCTYPE through the W3C’s CSS validator, it chokes, proclaiming it an invalid DOCTYPE (which it clearly is not).
Annoying.
HTML4.01/3.2/2.0 DOCTYPES:
http://www.htmlhelp.com/tools/validator/doctype.html
Some VERY useful info on DOCTYPES and browser behaviour:
http://www.allmyfaqs.com/faq.pl?DOCTYPE
There´s one thing I don´t understand about this one:
Does the lang=”en” elements refer to the language used in the document? Do I have to write lang=”fr” if there´s french text on the page?
spam spam spam
Yes, lang=”en” says that the document is in English. If you have some inline French you can stick it in le blah.
Wonderful comments, and thanks for catching the typo, Matthew.
Several questions raised here are answered in documents linked from the article.
For instance, the optional xml prolog causes problems in many browsers, not just IE6. Though it’s part of the XHTML standard, it’s an OPTIONAL part, precisely because its use causes problems in old browsers as well as some new ones.
This is covered in more detail in the XHTML Guidelines section of the NYPL Style Guide: http://www.nypl.org/styleguide/xhtml/guidelines.html
The Style Guide is linked from the article, and the XHTML Guidelines section is linked from “Better Living Through XHTML” (which is linked from the article).
now that we can render in a more compliant way, does anyone know when we can expect to see a strictly rendering browser?
as a developer, i would personally like a developer version of a browser which takes no crap from me and chokes up and any non-compliant mark-up. really i’d like it to help me force the developers i work with into doing basic stuff like closing tags and proper nesting 😛
seriously though, has anyone heard of such a user-agent? i’ve played with amaya (from the w3c), but its results are sometimes bafling and i wonder how correct they are.
I’m sorry, but all this article does is complain about how so many Web sites don’t use proper doctypes, then goes and provides a list of doctypes, that were already available in many other places on the Web. Where’s the beef, Zeldman?
A perfect example:
IE reverts to the IE DOM; Mozilla and Netscape 6 revert to who knows what.
Umm, well, why don’t you ask them? This is called “Lazy author’s syndrome,” and is consistent with many articles you find online. It’s when the author is too lazy to either find out the complete information and provide a much more robust and helpful article, or to simply leave out the unhelpful snide remarks.
Where is the discussion about all those folks who are using incorrect doctypes on purpose? I know some big-name shops (such as IBM) where the DOCTYPE tag is purposely incomplete so they can get IE-specific features like changing scrollbar colors.
I’m disappointed by this article. It looks like a combination rant and cut-and-paste from other places on the Net, and is trying to pass for something semi-original. It’s not. It’s a hack job at it’s worst.
Two hours before this article went live, I was contacted by a standards-aware developer who wondered if I knew why his carefully authored site was displaying incorrectly in Mozilla 0.9.9. I did. The answer was in this article. Despite all his knowledge and care, this developer had used the wrong DOCTYPE because that’s what he found at the source (W3C).
The HTML editors I use contain incomplete DOCTYPEs that trigger Quirks mode in all standards-compliant browsers but Opera (which avoids DOCTYPE switching, per the article).
These HTML editors are market-leading products, developed over years, by people who care about proper web authoring. They contain the wrong DOCTYPEs because a straightforward listing of proper DOCTYPEs is currently impossible to find at the source (W3C).
W3C standards (and other standards) are essential to the growth of the web, but w3.org’s Information Architecture leaves something to be desired, as they will be the first to admit. And this is so for the reasons stated in the article (W3C is not a tutorial site, it’s a repository for a huge and growing collection of deeply geeky documents.)
David, you may have known where to find all the proper DOCTYPEs, but I didn’t until I did the research for this article, and neither do many working web designers and developers (as well as some leading software makers). This article is intended as a service to the working designer and developer — folks who don’t have time to hunt down this information in various scattershot locations, and will appreciate its being made available in one place.
Also, I think you’ve mistaken editorial focus for “laziness.” This little article is intended to do one thing: give readers the proper DOCTYPEs. They don’t need a multi-paragraph digression on what previous DOM Mozilla/Netscape 6 may revert to if the wrong DOCTYPE is used. All they need to know is that, with the right DOCTYPE, Mozilla/Netscape 6 will support the W3C DOM.
If you’re looking for a more extensive and more detailed examination of web standards in browsers, you’ll find many such articles in the PREVIOUS STORIES section of this magazine.
One way to play around with all the different DOCTYPES is to go to the W3C’s Validation page (http://validator.w3.org/) & paste in your URI. The page allows you to select different DOCTYPES in order to check the validity of the code you’ve written.
Also, if you check the “Show Source” box, the exact DOCTYPE syntax will appear in the result for cut & paste fun.
Great article – something that needed to be addressed. Thanks.
What do you now of DOCTYPEs breaking JS functions?
I am trying to create a JS persistent nav bar in the spirit of the GeoCities watermark and once I insert the XHTML Transitional DOCTYPE into my document, the script no longer works.
============
Example JS :
============
http://builder.cnet.com/webbuilding/0-7690-8-5934478-9.html?tag=st.bl.7310.dir1.7690-8-5934478-9
============
Thanks for the helpful article. It answered several questions I had. But I’ve got one more.
Does anyone know if there’s and advantage to copying the DOCTYPEs from W3C and posting them locally?
Do the browsers actually go look at the W3C DOCTYPEs? Or are the browsers just reading the URIs like they would a
tag? In which case posting the DOCTYPEs locally would render them useless.
1. Are you using embedded scripts? The example at the above URL uses a script tag with the comment-hiding trick. This will make a true XML parser ignore the entire script, as XML parsers cannot treat script and style tags as containing anything but XML. There are ways to make the comment-hiding hack work in both HTML and XML at the same time, but it’s not pretty. Try removing the comment hack or, best, using an external script instead.
2. The script contains an ETAGO sequence (http://www.example.com/test“onmouseover=”alert(); . Let’s see if that does anything it shouldn’t!
cheers!
One hting I’ve never been able to figure out is whether or not the line wrap and the tab white space on the second line is required. For coding sake, espeically on my dnamic sites I’d prefer to have it all on one line.
Also, another reader above asked if the browser actually goes to the url in question. I don’t think it does in certain cases (when you use the ones listed in the article) but does it if you put another address in there? That could be an issue one might need to consider on an intranet where the DTD might be on the other side of the firewall.
Am I the only one who is havig trouble validating XHTML 1.0 Transitional documents using the provided DTD? I get Error: DTD did not contain element declaration for document type name if I don’t change the “DOCTYPE HTML PUBLIC to “DOCTYPE html PUBLIC”
The Doctype given for XHTML 1.0 transitional creates errors in the W3C validation service. What gives? I used to get validation when using the Doctype that this article says is incorrect.
it seems to me that the notion to use the W3’s website as the host in the URI is wrongheaded for two reasons. one, doing so causes the visiting user agents to reference the DTD on the W3’s website and thus costing the W3 a great deal of bandwidth. two, updating DOCTYPES on your website quickly becomes a function of N where N is the number of webpages you wish to validate; perhaps a potentially large and daunting number.
i think a better solution would be not to change your DOCTYPEs at all, and instead upload a copy of the DTD to your website in a directory called “DTD”. (you may need to do this for every subdirectory that contains webpages you wish to validate properly.) that would seem to save on bandwidth for the W3C and save on work for you (isn’t it better to upload 3 files for 3 directories rather than modify some 20 odd files?).
one other note. the transitional dtd is not small — 32k — and using it to validate your website might be a bandwidth concern for visitors as well. (would it make any validating webpages produced for the 5k a pipe dream?) it might be best for some to leave your webpage in quirks mode after all…
I’m getting the same validation failures as J in the above post. It seems that with the doctype for XHTML 1.0 Strict at least ( I haven’t tested the others), it is critical to start with “
Yup J, capitalization does matter. XML and XHTML are caps sensitive. The element and the element are different animals as far as an XML parser is concerned. So when you set the DTD to “DOCTYPE HTML PUBLIC” you are setting the doctype to an element that is not included in your DTD.
It seems that there is a small error in the doctypes listed for xhtml strict? – after fixing our site with the proper doctype it stopped validating, the same problem listed by adamd. Changing the “HTML” to lowercase “html” seems to have fixed the problem.
Everyone’s posting about the lowercase problem at once. My public apologies for not minding the not at the top and messing things up with html in my last post.
Hey,Why doesn’t this work? Simply: when the valid xhtml page has no doctype, the JS works. When it has any sort of doctype, it doesn’t. See for yourself:
Anyone else out there have more resources on JavaScript in XHTML? I’ve been fumbling with this issue for like two months, and annoying the ZMan with my emails
briandigital.com/test/menuwithoutdoc.html
menuwithhalfdoc.html
menuwithdoc.html
Any ideas? For me (on Mac) it only renders *and* functions right in Opera5. A Windows using friend says it works on some of his browsers.
Please email if you find the answer, and I’ll come back and post anything that works (this isn’t the best place to discuss debugging my site, I know). Sorry if my plea annoys anyone. I’m sure at least Jefffery’s sick of me… 😉
OK after some quick tests (and reading everyone else who’s joined in the debate) the three XHTML 1.0 doctypes should read as:
Stick to the exact capitalization above to allow your pages to validate.
“now that we can render in a more compliant way, does anyone know when we can expect to see a strictly rendering browser?”
This is where XHTML, especially XHTML 2.0, is headed. When a web page is sent with the XHTML media type (application/xhtml+xml rather than text/html) the user agent passes it through an XML parser, and throws an error message if it isn’t well-formed XML.
Mozilla 0.9.2, Netscape 6.1 and Opera 6 all support the XHTML media type (unfortunately Microsoft presently do not). Note that whilst they check for well-formedness, they don’t compare the document to it’s DTD the way Amaya does (ensuring the document is “type-valid”). Even so, it should go a long way to helping tidy up the messy tag soup that presently populates the web.
Ouch. I’ve lowercased “html” in those XHTML DOCTYPEs per your comments and the lowercase “html” in ALA’s own XHTML DOCTYPE declaration.
Several experts reviewed the article for accuracy before it went live. Nobody caught this error.
Thanks for the essential input and a thousand apologies for the confusion.
does anyone has experience what exactly mozilla/n6 does different in its standard mode? i had a problem with a mainly table based layout in which mozilla seemed to use a line-height for table cells which contained a 1px high image only if a DOCTYPE was given (and do the cell break to became like 10-15px high). in quirks mode the cell stayed 1px high. mac ie seemed to do a similar thing.
for one thing, in standards mode, mozilla messes with table-based layouts until you add one or more additional css rules. this is discussed in detail in an earlier article, “better living through xhtml.” the relevant portion of the article is linked below:
http://www.alistapart.com/stories/betterliving/#browsers
I hit the hotkey to enlarge the text on ALA, and only *some* of the text changed size. Sure enough, right there in your stylesheet, the body slass is defined with pixel-sized fonts. Come on guys, how about a little nod to taking your own advice.
Also worth mentioning: in the present version of Mozilla, simply hit CTRL+I (or click View -> Page Info) to find out whether the page is being rendered in standards compliant mode or in backwards-compatibility mode. This feature will find it’s way into the next major release of Netscape before too long (post Netscape 6.2x)…
First of all, a very good article indead .
I must apologize for my writing of english which is far then good.
So , I have a problem when validating my page on the w3 validator but the same page validate well-formed XHTML 1.0 with the WDG validator, so what is wrong with ???
Any idea?
The Doctype on my page :
That’s what the W3 validator gives back :
Warning: DOCTYPE Override in effect! Any DOCTYPE Declaration in the document has been supressed and the DOCTYPE for «XHTML 1.0 Transitional» inserted instead.
The document will not be Valid until you alter the source file to reflect this new DOCTYPE.
Below are the results of checking this document for XML well-formedness and validity.
What does that mean? I really don’t know.
Please note that you have chosen one or more options that alter the content of the document before validation, or have not provided enough information to accurately validate the document.
Even if no errors are reported below, the document will not be valid until you manually make the changes we have performed automatically.
Specifically, if you used some of the options that override a property of the document (e.g. the DOCTYPE or Character Encoding), you must make the same change to the source document or the server setup before it can be valid.
You will also need to insert an appropriate DOCTYPE Declaration or Character Encoding (the “charset” parameter for the Content-Type HTTP header) if any of those are missing.
No errors found! *
This document would validate as the document type specified if you updated it to match the Options used.
Is this a problem of language because I use “FR” instead of “EN”, don’t know?
Can someone help me with that.
I have been having a problem with a table layout falling literally to pieces in Netscape 6 because of the lack of a DOCTYPE, then with a valid DOCTYPE.
If I use the valid DOCTYPE, it falls apart. If I use the above DOCTYPE, it all goes together perfectly.
I can’t remember where I first heard this (I believe it was from a friend who possibly read it at evolt.org), however recent testing (two days ago) shows this is still the case for Netscape 6.2.
Anyone know why?
http://pun.org/ seems to validate fine, but I have issues with some of my pages where I use URLs that have “&” characters in them. Is there a straightforward way of escaping those strings so they’ll still be usable from 4.x browsers?
–jrp
Blondinnet — I think the W3C validator failed to detect your character encoding because you missed out the
element around your element. Try the following:Document
Correction to the above! You should have the PUBLIC identifier “-//W3C//DTD XHTML 1.0 Transitional//EN”, and NOT “-//W3C//DTD XHTML 1.0 Transitional//FR”! (The EN refers to the language the DTD is written in, not the language your XHTML file is written in.)
In order to encode an ampersand in a URL, for example “http://mysite/?foo=1&bar=2”, you can either:
1) replace ‘&’ with ‘&’, i.e.
2) See if it works with a semicolon instead, i.e.
Blondinnet,
on the validation page you may choose a doctype or you may let the validator figure out the doctype from the webpage you wish to validate. from the output it seems as though you’d chosen a doctype on the page rather than let it figure it out. it’s probably better not to specify one.
suzanne,
i seem to remember a “loose” dtd for html4. according to this page ( http://www.w3.org/TR/html4/struct/global.html ), the transitional dtd was, in the past, called loose.dtd. i figure loose.dtd would be a copy of transitional.dtd for xhtml, but i suppose not?
jeffrey and waferbaby,
could i ask a favor of you guys? a preview button would be a nice feature, if only to see who’s posted in-between the time i begin to write and the time i click on the post button…
There is a bug in Mozilla and therfore N6 (see http://bugzilla.mozilla.org/show_bug.cgi?id=121960) that causes mozilla to incorrectly render table height is a doctype is specified. It is not slated to be fixed until Mozilla 1.2
I have deleted the line above refering to xml
the same thing here deleting line with namespace refering
xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”fr” lang=”fr”>
And it validate this time oups!
So the code I use is :
Thanks for the answers
Regarding the DOCTYPE fetching issue, I believe each browser keeps a very small library of known DOCTYPEs against which it compares the DOCTYPE listed in your documents. If the DOCTYPE in your document matches one in their library of “standard” DOCTYPES, the browser reverts to standards mode. If your document contains no DOCTYPE or contains a “non-standard” one, the browser will revert to quirks mode. If your DOCTYPE does not contain a valid URI to the associated DTD, it’s not going to be one of the DOCTYPEs in the browser’s library and your documents will thus be rendered in quirks mode.
Browsers do NOT need to retrieve external DOCTYPEs. Firstly, it would put tremendous strain on any servers containing centralized DTD files (such as the W3C’s servers at MIT). Secondly, it would increase the download time because it would have to acquire the DTD file from the external server. Then the browser would have to parse the DTD, compare the document against the newly acquired and parsed DTD, then decide in which mode the document should be rendered, and finally render the document.
So the browser makers cheat a little. They simply figure out ahead of time that documents with DOCTYPES of a certain type shoud be rendered in a certain mode. So when the time comes to render a document, it compares the document’s DOCTYPE against the few stored in its library, figures out the mode in which to render the document, and renders it. This forces developers to use a small number of acceptable “official” DOCTYPEs (though no W3C DTD is technically official), but it reduces tremendously the overhead required to render each document.
On a related note, here are a couple more DOCTYPEs you may find useful that weren’t listed in the article. I have tested these and confirmed them to be correct:
XHTML 1.1 Plus MathML 2.0:
XHTML 1.0 Basic:
One thing I forgot to mention in my above post is that current browsers include XML parsers but not validators. IE’s most recent parser revision, MSXML 4.0, will check an XML document for well-formedness but not validity. For this reason, it is unnecessary for the browser to retrieve any DOCTYPE. At this time, fetching an external DOCTYPE would simply create additional bandwidth overhead when loading any page with a DOCTYPE.
Further, XHTML documents aren’t currently checked for well-formedness by XML parsers because XHTML documents have a MIME type of “text/html”, which means they’re considered HTML documents by the browser, not true XML documents. Were XHTML to get its own MIME type–say, “text/xhtml+xml”–the browsers would be forced to parse the document and check it for well-formedness. Until this happens, XHTML documents will be checked for neither well-formedness or validity.
Hi,
don’t flame Jeffrey, I re-read the article and I didn’t see that one. It was part of my own fault. 🙂 and it was so obvious !!! in XHTML all elements are lowercase and so the root too… :))
Errare Humanum Est
At least now the article is fixed, and all people could do the right job!!!
+ Blondinet -> Your error is here
I don’t mean to derail the thread, but I would just like to mention how increadibly charming it is that the W3C Conformance Manager writes with lots of !’s and :)’s. You just made me smile for the first time today. Thank you.
In reference to Dave’s comment above about different separators I just wanted to note that for those of you using PHP it is not enabled by default. If you have access to your php.ini file (or have a nice host) look for these lines:
; List of separator(s) used by PHP to parse input URLs into variables.
; Default is “&”.
; NOTE: Every character in this directive is considered as separator!
;arg_separator.input = “;&”
Simply uncomment the last line and both of those characters will function as argument separators. If you’re feeling rambunctious next April Fools try putting a character like “=” or “e” in there ;-p.
Riffola:
>No, the XML declaration is optional, as long as you specifiy
>the page’s character encoding using a Meta tag, the page
>will be valid XHTML, even XHTML 1.1
But in the W3C spec (http://www.w3.org/TR/xhtml1/#docconf):
“XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16.”
I’m a bit confused. I (prefer to) write my xhtml code using the swedish accented caracters, åäö. In order to do this I use a meta tag to declare that the caracter set is western european:
So my question is: is “charset” in the meta tag the same as the “character encoding” in the w3c specification?
And if so, am I right to conclude that I’ll have to set the caracter set to UTF-8 and start escaping all accented characters, in order not to be forced to make the xml-declaration?
I also use ISO-8859-1, and tend to put the XML declaration in.
Which browsers have problems with this? Obviously it’ll kick IE6 into quirks mode (not the end of the world as the sites need to work in IE5/5.5 anyway so it’ll behave similarly), but other than that I’ve not seen any definite information or received any complaints from clients/users (of course, if someone can’t use the site at all they’re unlikely to be able to find out where to complain to).
The browser does *not* generally go to the URL referenced in the
system identifier. This is partly because any XHTML browser would
certainly already know what the public identifier
‘-//W3C//DTD XHTML 1.0 Strict//EN’ refers to and would not need to
download the DTD. But mostly it’s because current browsers don’t
actually give a stuff what you put in the system identifier. They
doesn’t dereference it and they don’t even currently look at
what it is for DOCTYPE switching – they only care that it’s
there at all.
This could become a bigger problem if true XHTML browsers are
released which will attempt to dereference the URL if they don’t
recognise the public identifier, and then a new version of XHTML
is released with an unrecognised public identifier. Then all
browsers would hit the W3 site at least once to download the DTD.
They would have to, because it contains entity definitions
(&foo; etc.) which a validating XML parser *has* to know before
it can interpret the page.
J: the line wrap is not required. All-on-one-line is fine and that’s
what I usually do; I don’t work in 80 columns any more.
~bc: you are using a Javascript-style comment (‘//’) in a stylesheet.
This is broken, but presumably without a DOCTYPE, browsers’ Quirks
Modes are ignoring it. Also you are trying to set a positioning
value from script without adding a unit. This is also wrong, but
allowed by IE in Quirks Mode. You want:
domStyle.left= cX+’px’;
Blondinnet: this warning appears when you have selected the
DOCTYPE from the validator’s own form. It is nothing to do
with youe document. Select ‘(detect automatically)’ from the
menu on the validation form and you will not get the warning.
jrp: replace ‘&’ with ‘&’. The browser will decode that as
a normal ampersand before submitting. This is very basic HTML
and will even work on the 4.x browsers. And the 3.x browsers.
And (etc.)
Tommy: ‘encoding’ is the generic-XML way of specifying the
character set. ‘meta-charset’ is the legacy HTML way of
specifying it. If you have no top-bit-set characters in the
code before the , you can get away with just using
in XHTML. You might as well use
encoding=”iso-8859-1″ as well – there is no reason you have
to use UTF-8. But the best way of specifying a web page’s
charset is to use an HTTP header in the same format as the
hack (which just makes the browser think it has received
an HTTP header):
Content-Type: text/html;charset=iso-8859-1
Unfortunately unless you have proper control over your own server you probably won’t be able to configure this. (In
Apache, you can use the AddDefaultCharset directive.)
It might be a while before the doctype table height problem is fixed. As you know, the bug is targeted for mozilla 1.2. That doesn’t seem like that far away, but it could be half a year until we see the fix. The Mozilla Roadmap ( http://www.mozilla.org/roadmap.html ) has a little change for post 1.0 milestones. The development cycle has moved into a quarter year cycle. Check out the link for more info.
Greg H: “Further, XHTML documents aren’t currently checked for well-formedness by XML parsers because XHTML documents have a MIME type of ‘text/html’, which means they’re considered HTML documents by the browser, not true XML documents. Were XHTML to get its own MIME type–say, ‘text/xhtml+xml’–the browsers would be forced to parse the document and check it for well-formedness. Until this happens, XHTML documents will be checked for neither well-formedness or validity.”
Actually, XHTML *does* have it’s own MIME type, which will eventually replace ‘text/html’; it is ‘application/xhtml+xml’. Indeed, I’ve added a Request For Enhancement to get Apache to recognise it:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7795
Perhaps when the Web Standards Project launches ‘Phase II’, they could request that iPlanet and Microsoft IIS support the new MIME type out of the box too?
I am in the process of designing my website. I got it to look perfectly how I want, and I even validated the XHTML and fixed all of the errors on the page. But when I add, the XHTML Doctype, the page screws up.
If anyone knows what could be the problem, please eMail me. taestell@hotmail.com
It’s true that browsers do not attempt to validate using the reference to the DTD in the DOCTYPE. Anyone who’s loaded a local page on a laptop that’s not connected to the Internet is proof that there’s no attempt by the browser to load the external URL (it would fail otherwise.)
Validation does occur with some XML parsers, however. If you are using either an XML schema or a DTD with a recent parser (Xerces, Xalan or the latest versions of the MS XML), the validation process does attempt to load the external URL. This can be a problem if you are trying to develop (or deploy) backend services such as XSL transforms or other manipulations of an XML data stream. Without a connection to the Internet, the validation step will fail. The solution to this problem is to copy the necessary files and refer to them locally.
One would hope that the browsers eventually validate the XHTML source code. When (and if) they do, keeping a local copy of the DTD will be an important performance consideration; the servers at W3C will be serving up a lot of DTD and are likely to be a bottleneck.
I noticed in several of these posting the phrase “well-formedness”. I not sure at that means. Is there any ALA artical on this subject?
” I noticed in several of these posting the phrase ‘well-formedness’. I not sure at that means. Is there any ALA artical on this subject?”
XHTML is an application of XML. A well-formed XML document is simply one that nests elements properly (i.e. not overlapping like
), doesn’t include illegal characters (e.g. Invalid element ), etc.
The level up from being well-formed is being type-valid. This means also conforming to a schema, such as a W3C DTD. A type-valid document is, by definition, also well-formed.
You might find this article of use: http://www.alistapart.com/stories/hellxml/
People who use Doctypes should be aware that many older browsers cannot understand them and insert them into the document as plain text.
On some sites, I’ve elected not to include doctypes for this reason. These are generally the same browsers that display Javascript/Stylesheets as text as well.
A good rule-of-thumb is that if you start all of your scripts with a
Dave H: “Actually, XHTML *does* have it’s own MIME type, which will eventually replace ‘text/html’; it is ‘application/xhtml+xml’.”
To tell you the truth, I haven’t read anything on the subject of an XHTML MIME type for several months (hence my mistake of saying “text/xhtml+xml” rather than the more appropriate “application/xhtml+xml”).
I’m glad someone is taking the initiative to get the MIME type supported. Forcing XHTML documents to be well-formed and valid before they can be displayed will an important step for the Web. Frankly, I think it’s a necessary one if the Semantic Web project is to be successful.
Which browsers have problems with DOCTYPE? I suspect they’re so old & broken, and rarely used, that it’s not worth catering for them at the expense of good coding & forward compatibility.
If you’re not careful you’ll still be using CENTER and FONT in five years’ time…
You’re right that all of the browsers that have trouble with doctypes are really old and really broken. And, for most people, they’re not even worth considering.
The most popular browser that I know of with the issue: Mosaic.
You’re right that all of the browsers that have trouble with doctypes are really old and really broken. And, for most people, they’re not even worth considering.
The most popular browser that I know of with the issue: Mosaic.
Really, it was more of a concern back when we wrote documents with HTML 3.2.
I’ve noticed that ALA doesn’t bother with the
I’ve noticed that ALA doesn’t bother with the-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
People who use Doctypes should be aware that many older browsers cannot understand them and insert them into the document as plain text.
Yes, but people who use older browsers should be tied to a drain-pipe and ritualistically hosed.
“people who use older browsers should be tied to a drain-pipe and ritualistically hosed”
Can’t quite see that becoming part of W3C guidelines, but it might make a catchy tagline for the WaSP phase II site.
Actually I’m now wondering if I can get “people who don’t use DOCTYPEs should be tied to a drain-pipe and ritualistically hosed” into DaveCorp’s internal web standards… ;o)
Last time I checked, Mosaic doesn’t support HTTP 1.1, only HTTP 1.0 (and yes, Mosaic still runs on current Macs). So about the only website it will still be able to read is its own homepage. Degrade gracefully for older browsers by all means, but let’s stop scaring ourselves into thinking that some browsers are still being used if they’re not. Analyse your logs, learn what the HTTP capabilities of different browsers are, and don’t worry about the shortcomings of browsers that either can’t reach your website or were never Y2K compliant.
I am happy that the discussion forums are back. I have learned a good bit by reading the discussions about this article. However, it is very difficult to follow the “thread” of conversation! I would recommend a modification that would allow posters to “reply” to a particular post. Many other public forums are set up this way. I hope this will be a consideration for future improvement.
Thanks for your comments. We appreciate them. Waferbaby (http://www.waferbaby.com/) has done an outstanding job developing new forum software in PHP that’s low bandwidth and XHTML/CSS compliant.
The old forum software was threaded. One reader after another complained that the threading made it impossible to read and respond as if in general conversation. Readers begged for a flat presentation, and this is what we’ve implemented in ALA Forum Gen III.
Of course, now that we’ve implemented it, all the people who PREFERED threading are telling us they miss it. 🙂
We do hear you. When a reader posts on a specific topic, and his or her question gets answered five posts later, the flat presentation makes it hard to follow that aspect of the dialog.
But what the flat presentation does provide is a more readable experience in an easier-to-use format, free of all the clicking and navigating that made using the previous forum software a chore.
In a future upgrade, we MAY be able to offer readers the choice of flat or threaded navigation, though I can’t promise that, and we’re still working out the kinks of this new version.
Thanks for your comments, and thanks for reading http://www.alistapart.com/ .
I would have to agree with greg (previous post). The new forum look is rather hard to follow. I like the contrast of the titles to the post though.
I was hesitant to post this, as we haven’t yet seen the new forums in their completed state, or at least that’s how it seems. Perhaps when all the older content gets ported ovah we shall be enlightened?
Of course we will,
– Nate
This was just funny. Should/could not the new posts be posted at the top of the list?
Also – I love the (e) – quite sexy,
– Nate
Nate wrote:
>Should/could not the new posts be posted at the top of the list?
There are advantages to displaying comments in the order they’re received. The chief advantage is of course that replies make sense when viewed in the order of posting, and make no sense whatsoever when they precede the comments to which they refer.
“Newest post first” is a fine convention for weblogs, but not for conversations. mean I what know you If.
The advantage of placing the POST A MESSAGE field at the bottom of the page is that it encourages you to read existing posts before sharing your thoughts.
Does anybody know where I can get a list of the tags and properties supported by each doctype? My problem is that I use deprecated tags, but I don’t know where to find the right ones for the version I’m using. Half my pages validate to HTML 4.01 strict, and the others validate to HTML 4.01 transitional, and none validate to xhtml.
Dave, W3C includes all the info you seek as part of each HTML specification.
http://www.w3.org/TR/html401/ is the gateway to more than you ever wanted to know about the HTML 4.01 spec.
Does this help?
Personally, for any questions regarding (x)html elements whatever, I prefer the DTD itself (as referenced in ) for its brevity and clearness. While it’s not really that hard to read a DTD, there’s a great introduction by David Eisenberg here at ALA: http://www.alistapart.com/stories/readspec/ (Section “Learn to read a document type definition”).
i didn’t quite know what i was going to do with myself when the ala forums first went away, until one day, i didn’t notice that i wasn’t noticing they weren’t there, and that was sad.
now – i’m noticing them again. and that makes me happy.
thank you.
Did some sniffing around, and according to this page ( http://www.opendoor.com/homedoor/homedoorbrowserlist.html ), Netscape before version 2, and IE versions 2.1 and earlier do not support HTTP 1.1. Since many servers now seem to run HTTP 1.1 only (including MacEdition’s hosting service), odds are that users of these browsers won’t be able to reach your content at all.
So in response to the earlier posters who wish bad things upon users of older browsers — don’t worry, there’s a limit to how old the browsers you see can be. What this also means is that the small numbers of hits for these Jurassic browsers recorded at the canned statistics sites like http://www.thecounter.com/stats/2002/March/browser.php are almost certainly misleading. But we knew that from their inability to record the early months of uptake of IE6.
Of course, we still have to deal with version 3 and 4 browsers sometimes.
Not really about DOCTYPES, I know, but germane to the discussion. Until we can be sure that the alleged browsers that choke on DOCTYPE declarations are also compatible with HTTP1.1, I think that DOCTYPES can be included without compatibility fears.
Threaded presentation has its advantages in theory – so does hypertext storytelling – but they seem far outweighed by the simplicity of a good old linear discussion.
I welcome the change – less clicking, more cross-pollenation of ideas, easier access to the content, less chance of skipping over important posts and no more hunting through inconsistent titling.
Just so ya know, even “modern” browsers that claim to support HTTP 1.1 don’t do so very well.
For example, even the current version of IE 6 doesn’t support chunking.
It’s kinda ironic that “1.1” browsers aren’t, in that a compelling reason that HTTP 1.1 was made at all was because there was a glut of “1.0” browsers that weren’t.
Herein lies a flaw in recommendations masquerading as standards. Without normative test suites, it’s all too easy for a browser to support “foo”, since no one goes to the trouble to exhaustively test the support.
Instead, we poor developers are left to frequently stub our toes on inconsistencies and downright bugs, even in “standards compliant” browsers.
Sometimes it shakes my faith in the eventual goal of the semantic web.
To steal a phrase, No. wonder. the. kids. love. flash.
The commenting system at Palm Infocenter might offer a simple compromise on the flat vs. threaded issue. Instead of full-out threading, they allow replies to be grouped under the main initial post that started that particular topic, and provide two modes of viewing: nested and flat.
In “nested mode” you can see the initial posts of each topic, with links to replies. And in “flat mode” all topics are shown fully expanded.
It’s not as easy to pick out the latest posts, but it’s much easier to follow discussions, and perhaps more importantly, the discussions you’re interested in.
Article in “nested mode”:
http://www.palminfocenter.com/view_Story.asp?ID=3307&MODE=NEST
Same article in “flat mode”:
http://www.palminfocenter.com/view_Story.asp?ID=3307&MODE=FLAT
– Porter
Jeremy makes a good point ( http://www.alistapart.com/stories/doctype/discuss/#ala-173 ), but it’s not the issue here. The concern noted above by an anonymous poster (http://www.alistapart.com/stories/doctype/discuss/#ala-149) that “People who use Doctypes should be aware that many older browsers cannot understand them and insert them into the document as plain text”, is the issue. Until someone actually can tell me which those very old browsers are, I hold to my suspicion that it is a non-issue. Never mind that some features of HTTP1.1 aren’t supported even in newer browsers, the point is that very old browsers (pre-version-2) can’t even see the content because they don’t support HTTP1.1 *at all*. As an example, download Netscape 1 or Mosaic 0.9 from evolt’s archive and point it at http://www.macedition.com/. Last time I tried this, I got a message that my browser didn’t support HTTP1.1. In theory HTTP1.1 responses are meant to be backwards-compatible with HTTP1.0-only clients (http://www.openresources.com/documents/open-sources/node105.html) but apparently it doesn’t always work like that for ancient browsers.
Anyway, this networking protocol stuff is way beyond my realm of competency, so I’ll shut up now.
What’s the difference between:
and
Have never seen the answer to that. Which should I use for pages in English?
>>> What’s the difference between charset=ISO-8859-1 and charset=utf-8?<<< All web pages are transmitted not as characters but as sequences of bytes. The encoding of the page says how the bytes are converted in to characters. ISO-8859-1 is an old-style 8-bit encoding. It uses the byte value 0x41 to represent U+0041 (capital A), and 0xC1 to represent U+00C1 (capital A acute, if memory serves). (The U+xxxx codes are Unicode's character codes.) This is simple, but limited to the repertoire of ISO-8859-1. UTF-8 also uses the value 0x41 to represent U+0041. But the Unicode character U+00C1 is represented by two bytes: 0xC0 0xC1. UTF-8 can also encode other characters, like U+2014 (em dash), which is represented by the sequence 0xE2 0x80 0x94. In fact UTF-8 can represent any Unicode character, at the expense of being a little more complex to decode than ISO 8859-1. That said, for pages in English that do not use typographic punctiation and avoid words like café and Ã¥ngström, there is actually no difference between the UTF-8 and the ISO-8859-1 byte sequences! Since UTF-8 is the default for XML it is probably simpler if you plump for that. —Damian
A “forum about the forum” will be created at ALA shortly. That will be the place to post comments about the new forum.
I appreciate the enthusiasm and helpfulness of the many comments about the forum, but they really are off-topic on this page. I ask you to wait and save such comments for the forthcoming “forum about the forum.” (Try saying that with a mouthful of peanut butter.)
Thanks for understanding.
I have found articles on creating custom DTD’s for the purpose of standardizing elements that are not recognized by certain browsers. I have not successfully completed this yet, and I was wondering if anyone else has had better luck? Here is an article:
http://www.htmlhelp.com/tools/validator/customdtd.html
Those of us that still have to work in tables for layout, keep in mind centering a table in IE 6 and using the links to the DTD can cause the content to center in the table. http://www.evolt.org/article/Does_IE_6_Center_Your_Table_Content/17/15341/ provides an overview. The best solution is to set the alignment in the tables in the CSS.
Thanks for the great article. I had just convinced folks I work for to move to the proper DTD and link a few weeks ago. This article helped support that it was the right move.
Just to tell you, I informed Microsoft about the IE6 going into quirks mode with an XML declaration in about June of 2001. Methinks IE6 might have been a tiny bit rushed to fit the Windows XP schedule.
Actually, I’m quite glad they didn’t fix it – means I can easily stop IE6 using the horrid and massivly buggy standards mode (see http://tom.me.uk/2002/2/ie6css.html).
Good article and a fine resource of DTDs Jeffrey – thanks (PS i’m enjoying your Book).
What about Namespace’s though? I have to admit I don’t really understand the concept. I have included them in all of my recent XHTML 1.0 pages but I’m not sure if I use the correct one or even why. Any comments?
I have to agree that the flat discussion group is very hard to follow (I bet Jacob N would have a few things to say about it!). It’s so hard to find a response to any messages one sends. I have found the only way is to enter a search string in “Find on this page” in IE. I can at least then find my own post.
Anyway all the best.
Simon
xhtml is an xml application. In xml, you can declare your own tags. Let’s say, you create some xml language that needs a