Use XHTML or HTML 4.01 Doctype?

**AutisticCuckoo** · Apr 19, 2005, 13:06

Aahhh, and I thought you'd come up with a way to make an all-Flash site accessible to people without the Flash plug-in. I'm so disappointed.

**worchyld** · Apr 20, 2005, 01:02

I don't get this argument that because my documents being sent as text/html aren't really xhtml at all.

I've read the text-like article that complains that if its not sent as "application/xhtml+xml" then its not xhtml at all.

Then there's the argument that I hear about "well if you're not using a strict doctype, then its not truely xhtml"....

But...
1) The documents I write are validated by the W3C Validator as XHTML
2) The documents I write are in transitional, and validate properly.
3) I make a concious effort to reduce the number of tags, code and optimise as much as possible, and I ensure that the navigation, functionality, usability and all-round quality is ensured.
4) The documents aren't just "validating" - they are also fast to load, have good quality written code and do the job that its intended to do.
5) I've read that IE6/7 doesn't like "application/xhtml+xml" anyway...

If its doing its job, its validating, if its functional, usable, fast-to-load and has a benefit to the website - then *what* is the problem?

If there is a problem, can somebody please explain how to correct it with quick examples, and a doctype case-study.

Thank you.

**AutisticCuckoo** · Apr 20, 2005, 02:37

Originally Posted by worchyld

I don't get this argument that because my documents being sent as text/html aren't really xhtml at all.

It's true. Anything served as text/html must be parsed and interpreted as HTML by user agents.

Originally Posted by worchyld

I've read the text-like article that complains that if its not sent as "application/xhtml+xml" then its not xhtml at all.

Well, you could serve it with other XML media types as well, e.g. application/xml or <shudder/> text/xml. The important thing to remember is to use the proper XML namespace (xmlns attribute) on your <html> tag. Otherwise it's treated as general XML, with no built-in semantics and no default style sheet (i.e. you have to specify p {display:block; margin:1em 0} etc.).

Originally Posted by worchyld

Then there's the argument that I hear about "well if you're not using a strict doctype, then its not truely xhtml"....

That is false. XHTML 1.0 comes in three flavours, and all are XHTML (i.e. XML) when served with the proper media type.

There are some major benefits from using a Strict DTD, but those apply regardless of whether you use HTML 4.01 Strict or XHTML 1.0 Strict, and regardless of whether you serve the XHTML as application/xhtml+xml or as text/html.

Originally Posted by worchyld

But...
1) The documents I write are validated by the W3C Validator as XHTML

That means your markup conforms to the grammar of XHTML. Good for you, but it doesn't mean much as long as user agents see it as HTML.

Originally Posted by worchyld

2) The documents I write are in transitional, and validate properly.

I'm sure they do. Again, that has nothing to do with things. An XHTML document is not required to be valid, only well-formed.

Originally Posted by worchyld

3) I make a concious effort to reduce the number of tags, code and optimise as much as possible, and I ensure that the navigation, functionality, usability and all-round quality is ensured.

Attaboy! But you can do that with HTML, too. Besides, the 'quality' might improve if you use a Strict DTD (or it might not, depending on how much deprecated markup you use).

Originally Posted by worchyld

4) The documents aren't just "validating" - they are also fast to load, have good quality written code and do the job that its intended to do.

Yep. That's because browsers treat them as HTML. If they were treated as XHTML, you might notice a slight performance degradation, since AFAIK no browser implements incremental rendering of XML. (There is nothing preventing that, but I suppose most parsers want to ascertain well-formedness before doing anything else.)

Originally Posted by worchyld

5) I've read that IE6/7 doesn't like "application/xhtml+xml" anyway...

You could say that. It panics and asks you if you want to download the file.

Originally Posted by worchyld

If its doing its job, its validating, if its functional, usable, fast-to-load and has a benefit to the website - then *what* is the problem?

It's not certain that there is a problem. You're just not using XHTML, that's all.

If your documents are written in a way that requires them to be interpreted as HTML, then I'd say that there is a problem. That sort of markup is harmful to the web, IMHO, because they devalue XHTML.

A few examples of things that don't work in real XHTML:

'Hiding' scripts or style rules inside comments:

HTML Code:

<style type="text/css">
<!--
  #mydiv {color:#f00}
-->
</style>

Uppercase tag names, attributes, or CSS element selectors:

HTML Code:

<STYLE TYPE="text/css">
  H1 {font-size:150%}
</STYLE>

Unquoted attribute values:

HTML Code:

<div class=foo>...</div>

Modifying the document in mid-parse:

HTML Code:

<p>...</p>
<script type="text/javascript">
  document.write("<p>Hello, " + username + "!<\/p>");
</script>

Using .innerHTML:

HTML Code:

divRef.innerHTML = "<p>New content!<\/p>";

A few things that will only work in real XHTML

Referencing style sheets through an XML PI:

HTML Code:

<?xml-stylesheet type="text/css" href="/css/style.css"?>

Using self-closing tags for elements that are not declared as EMPTY in the DTD:

HTML Code:

<script type="text/javascript" src="script.js"/>

Using CDATA sections:

HTML Code:

<pre><code><![CDATA[<h1>Markup Example</h1>
<p>This is <em>markup</em> written literally.</p>]]></code></pre>

**worchyld** · Apr 20, 2005, 02:45

Does this mean there is no real benefit to xhtml? I thought that xhtml was meant to aid usability, functionality, navigation, standards, and ultimatley impinges on search engine optimisation (because search engines are increasingly becoming savvy to these things)....

We we all lead up the garden path?

Anyway....

Thank you for explaining it so clearly.

I've been doing projects in the past with xhtml validation, but now I see that isn't really xhtml at all... Especally since I've been trying so hard to get to a certain standard... now, my belief in the standard is rocked...

I guess its back to square one.... But at least my documents will be proper xhtml, or html, or whatever it is these days....

Thanks again.

**LSW** · Apr 20, 2005, 03:24

Sounds framiliar, Tommy sent me for a dizzy a year or so ago too.

The roblem is not quite as you define it.

Originally Posted by worchyld

Does this mean there is no real benefit to xhtml? I thought that xhtml was meant to aid usability, functionality, navigation, standards, and ultimatley impinges on search engine optimisation (because search engines are increasingly becoming savvy to these things)....

We we all lead up the garden path?

Not really, the idea of XHTML and the standards and all are good and solid IMHO, the problem is not the XHTML, the problem is the browsers not supporting it! Most do OK, except as usual IE which the majority of people still insist on using for some reason or another.

XHTML is threatened by lack of interest because in my opinion the W3C screwed up with making XHTML 1.0 and all that transitional stuff. I think we should have jumped straight to XHTML 1.1 or 2.0. But that did not happen so people like you now and me a year ago think we are doing XHTML when we were not. Especially those of us teachig ourselves, I avoided the W3C for years as I understood little. Tommy forced it on me

Now I see why I can use HTML 4.01 Strict...... but am so use to using closed empty elements and such that I really do not feel like changing, so keep writing XHTML, but serving it correctly where I can and wrong where I can't.

They should never have allowed Transtional anywhere, HTML or XHTML ...... they should have called for strict and left it at that. (IMHO)

**KuraFire** · Apr 20, 2005, 03:28

Originally Posted by mmj

To produce a valid HTML file is very hard, for non-trivial documents. That is, it is hard to produce a large, complex valid HTML document.

Uhm, no.

Even HTML Strict will allow you to omit closing tags, the html, head and body elements, and more such things. It's actually very easy to produce valid HTML 4.01 Strict. But valid XHTML, now there's a challenge.

Sure, it's even much easier to write HTML which is complete and utter crap and won't validate one bit, but it's definitely not difficult to produce valid HTML.

Originally Posted by mmj

Apart from being based on SGML, which is much more complex than XML, HTML is basically the same as XHTML 1.0. It has virtually the same elements, entities and attributes. Producing a valid HTML document from scratch will be exactly as complex as producing a valid XHTML document from scratch, providing it is well-formed.

THIS is a very dangerous misconception that people on the HTML-fence have.

To make things very clear:

Valid HTML 4.01 Strict documents can still have no closing tags, no HTML, no HEAD and no BODY tags!

Hence, producing a valid XHTML document is indefinitely more challenging than producing a valid HTML document. They can be equally difficult, when you write your HTML out in full, but HTML Strict does not require you to do that at all, whereas XHTML does.

Originally Posted by mmj

There is a common misconception that HTML allows for sloppy code whereas XHTML does not. I believe this misconception was formed because people are less likely to validate an HTML document than they are an XHTML document. People believe, for some reason, that it is "ok" to code in HTML that is invalid. HTML does NOT allow sloppy code. Only "tag soup", which is not HTML and not XHTML, allows for sloppy code.

The one having the misconception here is you, I'm afraid. HTML does allow for sloppy code. Strict conformance to HTML can still produce very sloppy markup, but strict conformance to XHTML requires at least well-formed markup where all required elements are present and where all closing tags are added. Sure, you can still create completely unsemantic chaos with Strict (validating) XHTML, but if it validates you at least don't have tag soup, which you may well have with HTML.

The HTML Validator will not tell you about missing closing tags in Strict mode. This means your code can be sloppy and you won't even know it. This simply isn't the case with XHTML.

**mmj** · Apr 20, 2005, 03:37

Originally Posted by worchyld

Then there's the argument that I hear about "well if you're not using a strict doctype, then its not truely xhtml"....

That is a false statement, so feel free to correct anybody who says that

The "Strict", "Transitional" and "Frameset" variants of XHTML 1.0 are actually continuations of the same Strict, Transitional and Frameset variants of HTML 4.01. Because XHTML 1.0 is a reformulation of HTML 4.01 in XML, it has the same three variants as HTML 4.01 did.

The "Transitional" variant of HTML 4.01 (and therefore XHTML 1.0 as well) was created in order to ease the transition from HTML 3.2 and earlier versions of HTML, which used markup for presentational information. The Transitional variant allows you to use features of HTML 3.2 such as the font, center, applet, and iframes element, or the bgcolor, color, noshade, target or nowrap attributes.

When creating a new document in HTML 4.01 or XHTML, however, it is recommended that you use the Strict variant and use stylesheets for the presentational information.

It is quite acceptable to use XHTML 1.0 Transitional for your Web page, particularly if you are in the process of upgrading your existing website from HTML 3.2 or Tag Soup. XHTML 1.0 Transitional is unique in that it is the only variant of XHTML that will ever allow legacy presentational markup (and forever will be).

**KuraFire** · Apr 20, 2005, 03:40

Originally Posted by BluDragon

Ok, that was just an example taken from another page on my site. MEANT FOR DEMONSTRATION PURPOSES ONLY!

Guess I should start adding disclaimers.

P.S. I've always used "application/xhtml+xml" with no problems from IE.

Joe

You've never sent a Content-Type header with Apache (or PHP/ASP/whichever) then, because IE simply cannot handle true XHTML.

Using a <meta> element to specify application/xhtml+xml does only one thing: your HTML document, with HTML Content-Type, should be saved as a .xhtml page, but no browsers I know actually do that, and so there is absolutely nothing that happens when you use a meta element for that.

**KuraFire** · Apr 20, 2005, 03:50

Originally Posted by dannyh

when "real" xhtml is served as such (application/xhtml+xml or whatever the correct syntax is exactly) what advantages does that give? How does the client and/or user benifit?

If your page is light in size, meaning not a lot of KB, all conforming browsers (all mainstream browsers except for IE) will render your page faster. Additionally, your pages are ensured of being well-formed, because if they're not they'll give you a nasty Yellow Screen of Death

More complex or notable advantages are currently not great in number: you can combine MathML in your pages, for instance, but there are very very few people that have a need for that at all. Think mathematical professors that need to write out equations and formulas and don't want to use images for it.
Beyond that, there are only advantages if you come up with ideas of your own to include alternative content like MathML in your pages.

However, there are advantages to using XHTML itself, even when you serve it as text/html (or at least as text/html to all browsers that don't support application/xhtml+xml). For that, read the Case for XHTML.

**KuraFire** · Apr 20, 2005, 03:55

Originally Posted by worchyld

Does this mean there is no real benefit to xhtml? I thought that xhtml was meant to aid usability, functionality, navigation, standards, and ultimatley impinges on search engine optimisation (because search engines are increasingly becoming savvy to these things)....

We we all lead up the garden path?

Not really, there has just been a lot of confusion along the way and now people are mixing up XHTML with semantic purity.

If you want to aid usability, functionality, navigation, standards and search engine optimization, use semantically rich and meaningful markup. Whether you use XHTML or HTML is irrelevant for your own site, at that point.

The only thing that really makes a difference when you choose XHTML instead of HTML is the way you present yourself to other webdevelopers. Writing proper, semantically rich and valid XHTML effectively means you're being a very good evangelist for web standards all around. If you use semantically rich and valid HTML, on the other hand, then most people that look at your source will not learn a thing about web standards at all.

**mmj** · Apr 20, 2005, 04:05

Originally Posted by KuraFire

Uhm, no.

Even HTML Strict will allow you to omit closing tags, the html, head and body elements, and more such things. It's actually very easy to produce valid HTML 4.01 Strict. But valid XHTML, now there's a challenge.

Sure, it's even much easier to write HTML which is complete and utter crap and won't validate one bit, but it's definitely not difficult to produce valid HTML.

I'm afraid I'll have to disagree with you. I believe it is no easier to produce valid HTML 4.01 Strict than it is to produce valid XHTML 1.0 Strict.

It is not simply the case that HTML 'allows' empty elements to be unclosed. HTML requires empty elements to be unclosed. Closing an empty element in HTML is invalid. The situation with XHTML is different. Not harder, nor easier. There is still a syntax that must be adhered to, it is just a different syntax.

HTML 4.01 Strict will not allow you to omit the head or body element - it just specifies that the start and end tags for these elements are optional. So if you leave them out, they are implied. To be able to leave out beginning or end tags of elements, you have to know which elements have optional tags and which do not.

You cannot just omit the start or end tags of any element in HTML. If you omit the end tag of the title element, for example, you'll end up with an invalid document. If you are going to omit the start or end tags of any element, you have to memorise which elements do and do not have optional tags. There's a lot of elements in HTML. On the other hand, the same is very easy to memorise for XHTML, because the rule is exactly the same for all elements - that is, start and end tags are required on all elements.

**worchyld** · Apr 20, 2005, 04:36

Is it still okay to create pages as xhtml as I am currently doing (or as many designers/developers are doing) with the following doctype, or do I have to make them strict?

Code:

<!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">

Do I have to start using the application/html+xml thing for it to be truely considered to be XHTML, or do I need to wait until XHTML1.1 / 2 comes out?

Bottom line -- is it okay to keep coding as it is, even if isn't truely XHTML?

**mmj** · Apr 20, 2005, 04:44

Originally Posted by worchyld

Is it still okay to create pages as xhtml as I am currently doing (or as many designers/developers are doing) with the following doctype, or do I have to make them strict?

If you know CSS (or another stylesheet language) then I'd personally recommend Strict. If nothing else, using stylesheets will better prepare you for future versions of XHTML. There's nothing technically wrong with XHTML 1.0 Transitional and it's quite valid. It's just that it is recommended that stylesheets be used for presentation now and in the future. But the choice is yours. If you are not familiar with CSS and for whatever time or economic reasons it isn't worth learning, then it may be better in your situation to use Transitional - stick with the devil you know.

Do I have to start using the application/html+xml thing for it to be truely considered to be XHTML

No, XHTML 1.0 may be served as text/html and still be considered XHTML - as defined in Appendix C of the XHTML 1.0 spec.

, or do I need to wait until XHTML1.1 / 2 comes out?

In my opinion (note, it's just an opinion) you will need to wait until all browsers support XHTML to use application/xhtml+xml. I am quite satisfied with the fact others will choose to use it with conforming browsers, or they may even avoid XHTML altogether and stick with HTML 4.01. This is personal choice as far as I am concerned. I think whether the code is valid and used correctly is a lot more important that which flavour or variant is used.

**Ryan Wray** · Apr 20, 2005, 05:15

Originally Posted by KuraFire

If your page is light in size, meaning not a lot of KB, all conforming browsers (all mainstream browsers except for IE) will render your page faster.

Do you mind explaining why that is? I was under the impression that it would infact take longer to render, considering most browsers don't support incremental display of xhtml. I know Mozilla browsers don't, read here: http://www.mozilla.org/docs/web-deve...aq.html#accept. According to that very FAQ question:

Originally Posted by Mozilla

Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

And then, when you look at Google's pages most of the time there isn't a DOCTYPE to be seen! Even majour vendors seem not in a hurry to make the transition to XHTML! Is there really, then, for most circumstances, any advantage of using XHTML? The future is XHTML, but for now, is HTML 4.01 Strict the best option. If you code HTML 4.01 now in mind of a possible transformation to XHTML 1.0 Strict or a new version of XHTML then you should keep the process quite simple, even automatic with a bit of programming ability (and some additional testing of pages).

**KuraFire** · Apr 20, 2005, 05:17

Originally Posted by mmj

I'm afraid I'll have to disagree with you. I believe it is no easier to produce valid HTML 4.01 Strict than it is to produce valid XHTML 1.0 Strict.

It is not simply the case that HTML 'allows' empty elements to be unclosed. HTML requires empty elements to be unclosed. Closing an empty element in HTML is invalid. The situation with XHTML is different. Not harder, nor easier. There is still a syntax that must be adhered to, it is just a different syntax.

HTML 4.01 Strict will not allow you to omit the head or body element - it just specifies that the start and end tags for these elements are optional. So if you leave them out, they are implied. To be able to leave out beginning or end tags of elements, you have to know which elements have optional tags and which do not.

You cannot just omit the start or end tags of any element in HTML. If you omit the end tag of the title element, for example, you'll end up with an invalid document. If you are going to omit the start or end tags of any element, you have to memorise which elements do and do not have optional tags. There's a lot of elements in HTML. On the other hand, the same is very easy to memorise for XHTML, because the rule is exactly the same for all elements - that is, start and end tags are required on all elements.

You're completely missing the point. The markup is what matters here, the markup is what I'm talking about, and the markup is the only thing that you, the writer of a web document, are involved in. You can more easily write a valid HTML Strict document as you can make mistakes by accident and still validate. Yes, if you omit BODY tags the element is implied -- in the DOM! NOT IN THE MARKUP!

If you omit <body> then nothing will suddenly, magically, place that in your markup. In effect the body element will be implied, yes, but it's still not in your markup.

Hence, given the very definite proof that I already gave in the form of that link, it is most definitely easier to write a valid HTML Strict document than it is to write a valid XHTML Strict document. HTML allows you to make a mistake, XHTML does not. That's a difference, and one of great importance even. It makes a difference in how difficult they are (or aren't), and thus, there is a difference between valid HTML Strict and valid XHTML Strict.

Also, nobody said anything about empty elements.

**AutisticCuckoo** · Apr 20, 2005, 05:20

Originally Posted by mmj

No, XHTML 1.0 may be served as text/html and still be considered XHTML - as defined in Appendix C of the XHTML 1.0 spec.

I've agreed with everything you've said so far in this thread, Thomas, but I'll have to disagree on this one.

Writing XHTML markup as specified in Appendix C "allows" you to serve it as text/html, i.e. to pass it off as HTML. If you do that, it is not XHTML as far as user agents are concerned, because they must interpret it as HTML.

The confusion here seems to come from a lack of understanding of something fundamental: The doctype declaration only tells a validating user agent which grammar to check conformance against. It's the media type (a.k.a. content type or MIME type) that tells the user agent which parser to use (XML or "SGML"), and it's the XML namespace of the <html> tag that tells the user agent that the document is XHTML – provided it is served as an application of XML.

**AutisticCuckoo** · Apr 20, 2005, 05:25

Originally Posted by KuraFire

Yes, if you omit BODY tags the element is implied -- in the DOM! NOT IN THE MARKUP!

Reality check: a user agent reads the markup, parses it, and builds a DOM tree. Then it renders the page from that DOM tree. Whether an implied element exists in the markup or not is completely irrelevant, since it exists in the DOM tree generated from that markup.

Originally Posted by KuraFire

HTML allows you to make a mistake, XHTML does not.

However, that is a moot point as long as it's sent as text/html, because it is then HTML, an HTML parser will be used, an HTML DOM tree will be built, and HTML error handling will be in place.

Well-formedness in XHTML is only enforced if you serve it as an application of XML. I'm all for that. Let's start doing it now. Anyone who still owns Microsoft shares had better sell them quickly.

**worchyld** · Apr 20, 2005, 05:33

I think this is quite a bombshell -- all this time, all those sites, all those people telling me to write xhtml, and I haven't been... It's like being told that the foundation for your house was really, in fact, sand...

**KuraFire** · Apr 20, 2005, 05:37

Originally Posted by AutisticCuckoo

Reality check: a user agent reads the markup, parses it, and builds a DOM tree. Then it renders the page from that DOM tree. Whether an implied element exists in the markup or not is completely irrelevant, since it exists in the DOM tree generated from that markup.

No, you're missing the point again. The point is the markup, serving as an example to others. The DOM tree is completely irrelevant for this because people see the markup and not the DOM (unless they go use the DOM inspector, but that's not what beginning webdevelopers do at all).

I know perfectly well that the markup is used by the browser to build the DOM tree; if you'd read my post correctly, you'd notice that I already said this, too. But we're not discussing the DOM, we're not discussing the presence of elements in the DOM, we're discussing the markup that is used as an example by others.

Originally Posted by AutisticCuckoo

However, that is a moot point as long as it's sent as text/html, because it is then HTML, an HTML parser will be used, an HTML DOM tree will be built, and HTML error handling will be in place.

Well-formedness in XHTML is only enforced if you serve it as an application of XML. I'm all for that. Let's start doing it now. Anyone who still owns Microsoft shares had better sell them quickly.

Again, you're missing the point. It's not error-handling that we're discussing, it's the markup, being used by new webdevelopers as an example.

Since HTML allows you to make a mistake and still be Valid HTML 4.01 Strict, the message that you send out to new webdevelopers is that it's okay to make a mistake. However, once they switch to true XHTML, they'll find out that it's not okay to make a mistake.

HTML is slowing down progress because it's not telling you that you are not allowed to make mistakes. XHTML is not like that.

On a side note: my CMS sends all pages as application/xhtml+xml to browsers that support it.

**KuraFire** · Apr 20, 2005, 05:40

Originally Posted by Ryan Wray

Do you mind explaining why that is? I was under the impression that it would infact take longer to render, considering most browsers don't support incremental display of xhtml. I know Mozilla browsers don't, read here: http://www.mozilla.org/docs/web-deve...aq.html#accept. According to that very FAQ question:

Basically, incremental rendering is only useful if you don't have the entire document instantly. So, if you're on dialup or the page is extremely big, then you'll want incremental rendering because you're only getting the page in increments.

However, if you're on any broadband connection and your bandwidth isn't being consumed for the full 100%, you'll get the entire page instantly (excluding images, but those are irrelevant for this) and you won't need incremental rendering. And in such situations, you'll get the page faster in front of you than you would if it'd been HTML.

**xhtmlcoder** · Apr 20, 2005, 06:12

Originally Posted by KuraFire

Since HTML allows you to make a mistake and still be Valid HTML 4.01 Strict, the message that you send out to new webdevelopers is that it's okay to make a mistake.

No, Mr T. didn't say if you produce malformed HTML 4.01 it would be valid; he did say it is likely the User Agent would probably render and display the results from the markup.

Though if you used malformed XHTML or just wrote XHTML-P don't expect it to just work when served as aplication/xhtml+xml. I think you were getting confused when he was talking about well-formedness verses valid.

**AutisticCuckoo** · Apr 20, 2005, 06:39

Originally Posted by KuraFire

No, you're missing the point again. [...] But we're not discussing the DOM, we're not discussing the presence of elements in the DOM, we're discussing the markup that is used as an example by others.

OK, I didn't understand that. Sorry. I thought we were still talking technical merits of one vs. the other.

Anyway, as long as the document is valid, what more can you ask? If HTML allows you to omit the <body> and </body> tags, and you choose to do so for some reason, that is perfectly acceptable HTML. If a beginner looked at that markup and copied it, s/he would also create acceptable HTML that would work in any HTML user agent. Sooner or later they'd find out that this is frowned upon by the propeller-heads, and they will probably start putting those tags in.

I agree that it doesn't set a good example, and that we should always try to set good examples. But using an XHTML doctype does not in any way guarantee a good example! Do you think that this markup (which would be valid except for the unencoded ampersands in the URI) sets a good example for XHTML?

HTML Code:

<script language="javascript" type="text/javascript">
<!--
   var __CMS_PostbackForm = document.Form1;
   var __CMS_CurrentUrl = "(bad URI)";
   __CMS_PostbackForm.action = __CMS_CurrentUrl;
// -->
</script>

When a beginner sees this, s/he'll think that using the 'language' attribute is necessary, and that you should put comment tags around your script code. That's not good XHTML, is it?

**KuraFire** · Apr 20, 2005, 07:08

Originally Posted by xhtmlcoder

No, Mr T. didn't say if you produce malformed HTML 4.01 it would be valid; he did say it is likely the User Agent would probably render and display the results from the markup.

Though if you used malformed XHTML or just wrote XHTML-P don't expect it to just work when served as aplication/xhtml+xml. I think you were getting confused when he was talking about well-formedness verses valid.

My point was and is that with HTML you can make a mistake and still be valid, but with XHTML you cannot. If you mess up with XHTML, you fail, you lose at Internets, you are teh suck. (to throw in some silly catch phrases)
If you mess up with HTML, there's a chance you won't know because your document still validates as Strict.

**KuraFire** · Apr 20, 2005, 07:19

Originally Posted by AutisticCuckoo

OK, I didn't understand that. Sorry. I thought we were still talking technical merits of one vs. the other.

Anyway, as long as the document is valid, what more can you ask? If HTML allows you to omit the <body> and </body> tags, and you choose to do so for some reason, that is perfectly acceptable HTML. If a beginner looked at that markup and copied it, s/he would also create acceptable HTML that would work in any HTML user agent.

But here's the key: if a beginner does that, their end-result may be acceptable, but they have no clue what they're doing, still, nor why exactly. With XHTML, they're forced to know, at least to SOME extent, what they're doing and why.

I'll agree with you on the obvious rebuttal that tons of people are using XHTML without knowing what they're doing, or even why (though, they know to an extent at least: Web Standards), but that's because the experts of today were all pretty clueless themselves, "yesterday" (i.e. 2-3 years ago at the start of the hype).

I'll agree with you in that all the people writing XHTML without having a clue are not being a good example. However, I can give you 8 billion pages worth of people doing HTML in an absolutely horrible way. At least the people writing (crappy) XHTML have taken the first step towards a better future, which is more than can be said about those 8 billion pages. It is now up to us, the informed webdevelopers, to enlighten these people that just slapping on an XHTML doctype doesn't make their pages be good all of a sudden. But they've taken the first step at least.

Originally Posted by AutisticCuckoo

Sooner or later they'd find out that this is frowned upon by the propeller-heads, and they will probably start putting those tags in.

Or: they'll switch to XHTML and have tons of problems because they got used to leaving out a lot of stuff and will curse XHTML and condemn the future of the web. Risky business, that.

Originally Posted by AutisticCuckoo

I agree that it doesn't set a good example, and that we should always try to set good examples. But using an XHTML doctype does not in any way guarantee a good example!

I agree, but I never said that using an XHTML doctype was any form of guarantee for that. Please keep that in mind. I don't support people mindlessly jumping the XHTML bandwagon and just slapping an XHTML doctype on their horrible tag soup, no! But I see a great many people switching to XHTML and putting serious effort into learning how to write semantic markup, and them I support!

Originally Posted by AutisticCuckoo

Do you think that this markup (which would be valid except for the unencoded ampersands in the URI) sets a good example for XHTML?

HTML Code:

<script language="javascript" type="text/javascript">
 <!--
    var __CMS_PostbackForm = document.Form1;
    var __CMS_CurrentUrl = "(bad URI)";
    __CMS_PostbackForm.action = __CMS_CurrentUrl;
 // -->
 </script>

When a beginner sees this, s/he'll think that using the 'language' attribute is necessary, and that you should put comment tags around your script code. That's not good XHTML, is it?

That's not good XHTML no, but I never said XHTML was perfect either

**jallard** · Apr 20, 2005, 09:34

Hi, folks!

Sorry, but I couldn't figure out how to start a new thread?!? So, here goes:

Sometime ago I made the mistake of purchasing a Flash Template from TemplateMonster.Com: and, what I paid for was a virutal mess of scripting. I have been months trying to fix everything. I recently completed chaning everything to small letters, adding "#" where there were none in the bgcolor="#" script, placing "alt=""" tags where there were none, and placing "" where there were none. (See the example here: <TABLE WIDTH=100% height="100%" BORDER=0 CELLPADDING=0 CELLSPACING=0 bgcolor="FFFFFF">.)

Now my home page --http://www.willametteweb.us-- is all askew. It nakes it even worse if I add the following <!DOCTYPE> to the page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

I have to omit the latter script?!?

My question to all of you is, "How do I fix these problems?" In addition, the W3C HTML Validator doesn't recognize the following scripts either: "td colspan="5" background="images/bgtop1.gif" height="29" width="606">"

Thank you, for your support.

Jallard

The SitePoint Forums have moved.

User Tag List

Thread: Use XHTML or HTML 4.01 Doctype?

Thread Tools

Display

<!DOCTYPE> makes tthe page all askew, even after fixing.

Bookmarks

Bookmarks

Posting Permissions