Just what does the doctype do? 3

[tsdragon]

This may sound like a dumb question from someone who has been doing javascript for years, and been on this forum for years, but I've never really had the need to worry about it, and it didn't used to come up. I've just gotten curious because such a big deal had been made of late (I'm not saying for good or bad, I really don't know) about using a particular doctype. The editor I use automatically supplies one, and I've never questioned what good it is. I have a vague idea what it is for, but it's never really come up. So, the following questions for the doctype supporters:

1. Just what good does specifying a particular doctype do?

2. What are the pros and cons of specifying one particular doctype over another?

3. What happens if you specify a particular doctype and then use something that happens to violate that doctype's rules?

I'm sure the answers to this question will be a big help to the newcomers to this site too.

cLFlaVA, Vragabond, BillyRayPreacherSon, Foamcow, others: take this opportunity to make your case emphatically.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Vragabond]

1. A complete and valid doctype over none or incomplete or invalid, a lot. Doctype gives the browser directions on how to render the page, directions that are publicly available at the W3 Consortium website. Thus, any browser that reads and understands the doctype (all latest browsers) will render the page according to standards.

2. Again, if it is valid and complete over none or incomplete, a lot. See above. Between different valid ones, goes to one's preference of coding. I like xhtml 1.0 strict or xhtml 1.1 because it does not allow any slack. Everything open must be closed, everything must be quoted and everything must be well formatted. Every lower level doctype gives a little more breathing room in being sloppy: forgetting lower caps, forgetting closing tags, etc. I guess you could say that stricter doctypes force you to make your code more uniform and neater.

3. Usually, nothing much. Your page won't validate. However, that is the problem with the browsers cutting you some slack. Browsers can decide to completely ignore the rule that does not exist in the doctype you're using. XHTML 1.0 Strict has no border property for image. If you specify border="3", user agents does not have to render that border because it is not part of the specs. Today's browsers usually pick up the dirt behind you and render it anyway.

Conclusion: Doctypes are what we were all hoping for for years in web design and development. Clear standards and guidelines from an entity that does not make browsers but helps making web a little more standardized.

 

[tsdragon]

Hey, Vragabond, glad to see I'm not the only nightowl (at least it's night here in Virigia).

You just gave me another couple of questions:

4. What does it mean the page "won't validate"?

5. What effect does the doctype have on the browser you are using, or vice versa?

(I know I'm sounding dense here, but I not only want to make sure I get a clear and complete answer, I want to make sure that any newcomers to DHTML/CSS understand, so I'm going to keep up with the questions until I'm sure it's clear to anyone interested.)

BTW: once this thread is complete, you can either point people to it instead of constantly having to explain, or we can turn it into a FAQ to the same end.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[tsdragon]

Just thought of another question:

6. Why should I use a "strict" doctype that means my page "won't validate" (whatever that means), when I can use a "loose" doctype and get my page to do what I want it to do? Where's the benefit to me?



Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Xaqte]

Off subject... tsdragon, where in VA? I'm in NC and go thru VA alot!

 

[Vragabond]

4. Page won't validate as proper page for the doctype. One of the validators is available here:

http://validator.w3.org/

It is like saying your car takes unleaded gas when it actually runs on leaded one. Or if you want to have it in HTML. You are saying that you will write <br /> but you're actually writing <br>. As I said, browsers will cut you some slack and pretend they know what you mean. If they were strict, they would ignore the <br>

5. It has no effect in old browsers, such as IE5 and IE5.5. These browsers ignore the doctype and always render in quirks mode. I would assume the same with NN4 and IE4. Newer browsers act differently with or without doctype.
- Geckos (FireFox, Mozilla, Netscape 7) will render pages very similarly with or without doctype. If you look at the Page info in these browsers it will display whether it is rendered in quirks (no doctype) or standards compliant (doctype) mode. Difference however is minimal.
- Opera (at least versions 7.0 - 7.5) will render similar to IE without doctype -- mainly incorrect box model -- and very close to Geckos with doctype. Difference here is really tangible.
- IE6: without doctype it will render in quirks mode, similar to IE5.5 and IE5. With a doctype its rendering will be closer to Geckos, though far from perfect. Main thing is, its box model will be corrected to use the standard one.
- Others: don't know, because I have no means of testing. I know Safari displays very similar to Geckos, I don't know however how it behaves with or without doctype, because I always test with doctypes.

6. You shouldn't. As I said, choosing between different valid doctypes is a strictly personal preference. I like, agree and code within all the rules that XHTML 1.1 specifies. If you think your coding style or if you're inheriting a site that had no doctype, you should decide by examining the code which doctype is the most appropriate. As I said, the stricter they get, the neater and more organized your code must be. And that always helps people that need to read that code after you.

Addendum: I do not feel 11pm is really a late owl here in Washington, DC metro area Maryland where I am. Where you at, Tracy? Got some work for me?

 

[tsdragon]

Off subject is OK with me - it's MY subject.

I'm in Hopewell. It's about 20 miles south of Richmond, just off 295 (Rt 10 or Rt 36 (Ft Lee) exits). Where are you in DC/MD? I used to live in downtown DC, near Wash. Hospital Center, Howard University, and about 18 blocks due north of the Capitol. Used to work in Oxon Hill, MD.

I work for a small ISP/Vendor (see

http://www.cwtg.com

or

http://www.polaris-ulm.com).

Besides being an ISP, we market software for and manage "inspection tickets" for utility companies to comply with Federal regulations regarding marking of utilities when you plan to dig or do construction. Ever hear of "Miss Utility"? We currently have clients in 13 states. We do software in VB and web-based in ASP/HTML/JavaScript. I'll check with my boss to see if he wants to outsource anything, but I've only been there since December, and I'm still on "evaluation contract" until next month, so I don't want him to think I can't handle the workload.

BTW: My email is tracy at cwtg dot com if anyone wants to contact me. Feel free to. I hope to have my own website soon too. Since I work for an ISP, I can set it up myself once I register the domain name.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[tsdragon]

Back on topic:

Another question (am I getting annoying yet?):

7. Does the validation happen automatically (I notice there is a URL in the doctype) or do I have to do something to see if the page validates?

If not, then my coding style must be pretty strict, since I changed my doctype from "HTML 4.0 transtional" to "XHTML 1.0 strict" and everything still works the same. I try to be pretty good about case (especially since I'm used to coding in case-sensitive languages), quoting, and closing tags (although I've never used a "<br />"). Unfortunately, I also have to maintain a bunch of pages where the coder didn't even use </td> and </tr> tags in tables! The way they are coded, they work, and if you try to "clean up" the html by adding the closing tags, they don't look the same. I'll get him to come around eventually...


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[tsdragon]

I forgot to mention, that email address is my work email address, and I'm not sure how to access it here at home. You can also use tsdryden at mail dot ctg dot net. I have web access to that one, as well as accessing it at work.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Foamcow]

If not, then my coding style must be pretty strict, since I changed my doctype from "HTML 4.0 transtional" to "XHTML 1.0 strict" and everything still works the same. I try to be pretty good about case (especially since I'm used to coding in case-sensitive languages), quoting, and closing tags (although I've never used a "<br />"). Unfortunately, I also have to maintain a bunch of pages where the coder didn't even use </td> and </tr> tags in tables! The way they are coded, they work, and if you try to "clean up" the html by adding the closing tags, they don't look the same. I'll get him to come around eventually...

Try validating the page at

http://validator.w3.org/

See what it says. I'd be suprised if it validates first time.

As for not closing <td> and <tr> tags. That's just plain bad practice. Even for "old skool" HTML coding.
The reason it doesn't look the same if you close the tags is possibly because it looks wrong but that's what is required visually... and furthermore I bet you are looking at the page in Internet Explorer.

Foamcow Heavy Industries - Web design and ranting
Toccoa Games - Day of Defeat gaming community
Target Marketing Communications - Advertising, Direct Marketing and Public Relations
"I'm making time

 

[Vragabond]

7. Like I said, modern browsers will let you have mistakes and not punish you. So, if you state your code is XHTML 1.0 strict and it is not, display in the browser will be the same. I however suggest you run your website through the validator I mentioned and see if it has any complaints about your code. If it does not, you will be presented with a little button you could put on your website that says XHTML valid or something. Just like in the old days we had 'works best with xx browser' we now have a little graphic that says we conform to standards. But once again, as long as there is a valid doctype, your page will render in standards mode and most browsers will let you off with most non valid code. Probably if I tested extensively I might find features where the browser ignores the code because it is not valid. Anyway, the best way to test for validity is still the online validator at W3 Consortium website.

And the URL in the doctype. That is where everything is described. By just keeping your mind open, you can review the DTD file that URL points to. That file has all the elements and attributes and the way they interact between each other that that certain doctype supports.

For your legacy websites, if they do not have closed <tr> and <td> tags, you should use HTML 4.01 Transitional, which does not demand that. Not that your websites will render differently if you use other valid doctypes in most browsers but just for the sake you're not lying. It is an HTML 4.01 Transitional valid, but not XHTML 1.1 Valid.

I am living in Rockville, MD. I moved here from Vienna, Austria but am actually from a small European country of Slovenia. I have only received my work permit to work in the states a few weeks ago.

 

[ChrisHunt]

Taking a step back here, I want to go back to question (1) and put in some of the background. Technically, a doctype merely identifies the syntax that a document will follow, practically it has big implications...

Remember the browser wars? Each browser putting their own spin on HTML rendering, and us poor developers trying to keep our sites looking right on all of them. Remarkably, we were somehow able to do so. Even more remarkably, the browser makers agreed to bring their products into line with an agreed set of standards (however slowly/incompletely).

Now web standards were/are good news, but presented a problem - what about the millions of pages already written that depended on individual browsers' quirky behaviour to render correctly? Wouldn't the introduction of a new set of standards cause them all to break? The solution to this problem was "doctype switching". Any page with any valid doctype would be assumed to be recently written, by somebody who knew the new standards. Such pages could safely be rendered in "Standards Mode". A page without a doctype could be one from the bad old days, and should be rendered in the bad old way - so-called "Quirks Mode".

So, coming back to (1), specifying a doctype - any doctype - will vastly improve your chances of getting the same look across browsers, because all of them will be following the same rendering standards. Just how well different browsers comply with those standards is another matter...

(2) Once you have a doctype, there are minimal pros and cons of any of them over any others. Pick one that you like.

(3) Usually, nothing happens, but who knows? Browsers expect documents to be valid (in IE's case it expects documents to be valid HTML, as it pre-dates the introduction of XHTML). When a coding error occurs, browsers cope as well as they can (which is usually pretty well). Many cross-browser rendering issues occur because browser X copes with an error one way, whilst browser Y copes with it in another. The answer is not to make errors in the first place - or at least to eliminate them by validating your pages.

(4-7) Well dealt with above

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[tsdragon]

You're right about one thing - when I tried to validate the page with "XHTML 1.0 Strict", I got a HUGE number of errors. After reading thru the errors, I am convinced of one thing: I will never bother with that doctype again![/b] 90% or more of the errors it gave were for things that I consider totally stupid. For example:

1. Apparently you are no longer allowed to put text in the BODY of a document, unless you enclose it inside some other element. I find this TOTALLY RIDICULOUS!

2. Apparently the <br> tag is no longer allowed. It didn't like a single one of them that I used. And that doesn't even include the fact that I didn't "self-close" them (when did that ridiculous idea come about?).

3. Since when does a <meta ...> tag require closing?

4. When did they replace the attribute "language="JavaScript" with "type="text/javascript"?

5. Did you know that you cannot include the character string -- inside an html comment? That's a common practice to make multi-line comments look neat. That's got to be a parsing error!

6. When did the <b> tag become invalid??? Why should I code "<span style="font-weight: bold;"> when three simple characters will do the same thing??? What idiot came up with that rule?

7. Apparently the same idiot decided that using <u> instead of a span tag 10 times as long was a no-no too.

8. It appears that the same rule about not including plain text in the body of a document also applies to certain html elements like <button>. The validator complained that it was not enclosed in some block-level tag. I didn't want the button to be inside a block, I wanted it to be inline!

9. Again with the self-closing stupidity! Why does a <hr> tag have to be closed at all??? It doesn't enclose anything!!!

10. Even when I actually USED a <span> the validator complained that it was not enclosed in one of the block-level elements. What kind of stupidity are we dealing with here? Doesn't the BODY qualify as a block-level element? Why should almost EVERY darn element in the body of the document be enclosed in another, block-level, element? Where is the benefit of this? If you DO use an enclosing <div> or <p> like the validator requires, the default attributes of the <div> or <p> practically REQUIRE that you override most of them in order to get the appearance you require.

11. This one I simply CANNOT FATHOM. It gave me numerous messages saying there is no attribute "id", "name", "src", "style" or "frameborder" on an <iframe> tag! Then it finally told me that element <iframe> is undefined! Since when? I find the use of iframes indispensible in creating efficient, user-friendly, dynamic web pages. Unless they've added a "src" attribute to the div tag, I'm NOT going to give up on iframes!

My conclusion: The group who came up with the "XHTML 1.0 Strict" standards REALLY needs to GET A LIFE! Who in the Seven Rings of Hades made these guys the html-nazis, and who gave them the power to take away all the simple things about html and replace them with cumbersome, wordy, overly restrictive crud instead? Didn't COBOL become nearly extinct because it was so wordy and cumbersome? Now we're going back in the opposite direction. I guess the next generation of XTHML will be called "Post Increment Extended Hypertext Markup Language by One" (with NO ABBREVIATIONS ALLOWED!). I thought they were supposed to be make things EASIER for us, but they're doing EXACTLY THE OPPOSITE!

Final Note: XTHML 1.0 Strict is totally ridiculous. I can't see why anyone would even THINK of such a stupid set of rules, much less try to abide by them!




Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Vragabond]

Ok, if the XHMTL 1.0 Strict rules don't do it for you, that does not mean they are stupid or ridiculous. I personally am very fond of it and agree with everything it states. Let's review.

1. Body is just not a place for text. Text should generally be inside paragraph tags. Your code will be much more understandable and you will style it easier if you will follow this convention. Also, paragraph tags give you nice default option of new line breaks.

2. Just like in SGML in XHMTL every tag has to be closed. I find this practice extremely helpful. Whatever gets opened, must also be closed. While it is pretty natural to most people that table tags, divs and similar needs to be closed, so called empty elements (the ones that do not have any text between beginning and end tag) are a little trickier. But it does make sense that you need to close everything you open. That means that you do [tt]<br></br>[/tt] or [tt]<img></img>[/tt] or [tt]<input></input>[/tt]. To make things a little easier, XHMTL allows you to close the element with the shorthand property: [tt]<br />[/tt], [tt]<img />[/tt] or [tt]<input />[/tt]. Once you get around to using it, you feel kinda weird not doing it.

3. See #2.

4. [tt]language=""[/tt] is available in HTML 4.01 but it doesn't really make sense to use that. [tt]type="text/javascript"[/tt] is a standardized way of displaying type of content within blocks that define non-html content. You do the same with <link /> and you don't complain. If somebody would ask you to write <link language="css"> wouldn't you feel weird?

5. I don't really know what you mean.

6. That is false information. If you know how to read DTDs you can see here that <b> is still available.

7. W3 is right for excluding this one. Default representation of links is that they are underlined and this element causes a lot more confusion that does good. If you need something underlined, you can still use css for it. Besides, underlined text is presentation (and as such belongs to css) rather than structural.

8. Could you give an example of that? Form is a block element and buttons are usually within forms. Buttons need not be blocks, the rule states they need to reside within a block.

9. See #2.

10. Default div properties are (within most browsers) display: block; Which of these properties would you like to override? For more, see #1.

11. A little more educating in doctypes and html won't hurt. Iframes are just like the name tells, frames. And all doctypes have a special frameset doctype that is used for pages that contain frames. So, anytime you need frames, you do not use the strict doctype but frameset. Know that you can use strict on the pages that are in frames but not on the actual page that holds the frames (frameset) if you use iframes, that page is actually a regular page and a frameset. Use frameset doctype in this case.

Once again, I am stupid enough to always abide to XHMTL 1.0 Strict. I don't know why you feel compelled to call me stupid just because you do not want to use it. Here's a question. After you pump the gas at the station, do you close little gas cap door even though you screwed the cap which prevents gas from spilling over anyway. Isn't that a little redundant but you do it anyway? There are good reasons that make XHTML 1.0 Strict behave the way it does. But just like Chris and I have told you, which doctype you use is up to you, as long as it is a valid one. So if your coding style reflects HMTL 4.01 transitional, use that. My coding style matches everything XHMTL 1.0 Strict demands and I find all demands very reasonable.

 

[tsdragon]

Where in what I said do you find that I called you stupid for abiding by the rules. I said the people who made them up were idiots and the rules themselves are stupid, but I made no judgements upon the people who want to abide by them. I simply said I don't understand why they would want to. I don't understand why vegetarians have such strict dietary rules either, but I don't call them names.

Even after sleeping on this and reading your responses I still feel them same. Too much of the standard makes no sense to me whatsoever. The W3C is starting to sound like the Magistrate on that children's program "Sagwa" who spends all day making up new rules, just because he can.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Vragabond]

I apologize, it was late and I connected one of the 'stupids' with the people who use this syntax. Everything else stands though. W3C gives you options and does not force you to do anything you don't want to do. If you think closing empty tags is stupid, use HTML 4. Not me nor W3C will make fun of you for doing that. What I am saying is, I use XHTML 1.1 or 1.0 Strict all the time and do not feel my code is either bloated or too standardized. If you believe in diversity in people, you have to admit that W3C standards are ok. They let you do it one way or another. If you just want the benefits of the standards and having best possible cross-browser results, use a non strict doctype, which will do eveything you want: bring you up to standards and allow your style of coding. You have to understand that that is your perspective. There are a lot of developers out there that love XHTML Strict (I for one), a lot who love HTML 4 and a lot who love Transitional ones. Why is it you're mad at something nobody is forcing you to use and you decided it is not worth using. Some people may think it is and you really should respect that.

Live and let live. If you don't like it, doesn't necessarily mean everyone doesn't like it. If you think they're stupid, not all think they are. Etc. And while nobody is forcing you to use them, you shouldn't post your frustrations with them in a forum like this. Maybe a rant in your blogspot would be a better venue.

 

[manarth]

IMO, the standards are intended for 2 key things:
- to enforce a consistent syntax, preventing M$ and the like arbitarily creating new tags a-la-browserWars.
- to return HTML to structural markup, as opposed to presentational markup.

The <b> tag was replaced with <strong>, because bold is only visually presentational, whilst strong has symantic meaning.
Likewise, <i> becomes <em>.

The difference may not be noticeable between IE and Moz, but when you compare an Old Skool site with a symantically-coded site in a text-only browser (such as Lynx), you really appreciate the improvements.

Oh, well-structured valid code is easier for search engines to parse accurately, so you generally get better rankings.

Even better, well-structured symantic code can give you some cool tricks: such as the CSS Zen Garden stylesheet switching.

Not that I'm a raving standards supporter or anything

<marc>

 

[tsdragon]

OK, I'm somewhat placated now. I think the real problem is that I was so disappointed. I usually embrace newer standards as bringing something beneficial to a difficult situation. However I don't see this to be this case here. It seems to me that the authors of the newer standards have arbitrarily taken a simple standard and instead of giving us a common standard with better functionality, have made it MUCH more restrictive and cumbersome without giving me a significant benefit in return.

However, if you disagree that fine with me. If we all agreed on everything then most of us programmers would be out of business. (If there would only be one programming language that everyone used there wouldn't be a need for such a variety of programmers.)

Either way, I thank all participants in this discussion (and encourage further postings and opinions). It has been an education, and even with the dissension is probably a good place for newcomers to see just what this "doctype thing" is all about. They deserve to hear both sides of the issue.


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.