Jeff Lynch [MVP]

I've been posting on this more often lately so I can already tell you that if you do use the controls given to us by Microsoft you won't get a fully compliant site. It'll be XHTML compliant (compliance in this case means it validates even though they still use tables where they shouldn't) but it won't be CSS compliant. The menu control for example embeds some malformed CSS into your pages. The templates you linked to also don't validate as having compliant CSS and some have pages that don't even validate as compliant XHTML.

Chris,

How right you are! I'm going to attempt this using 0 tables for page layout, templated server controls wherever possible to avoid the generated layout tables and fully compliant external stylesheets. I post each step on my quest and we'll see if it's possible.

Jeff

As far as I understand the issue:

I'm not sure why XHTML compliance is important to .NET developers. IE is going to render it in Quirks mode either way since you have to serve it as "text/html", or hack it to serve XML with the correct MIME Type ("application/xhtml+xml").

If you're using MathML, SVG, or XSLT, then ok, but if not, it really doesn't do anything HTML4.01-Strict wouldn't do as well, with the advantage that IE will render a validating HTML4.01-Strict document in Standards mode.

Chris Wilson:
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

W3C:
http://www.w3.org/MarkUp/2004/xhtml-faq

And? What's my point?

That wether IE uses Standards Mode or Quirks Mode when rendering your pages will make a much more meaningful difference to your site design (and the level of standards compliance you can achieve/hacks you have to implement) than wether or not you're serving "XHTML".

Here's another link that explains it better than me, but without the rambling. :-)

http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/

Sam,

I kinda like the rambling :)

As to why I'd like to see if it's possible to develop a web standards compliant site using ASP.NET 2.0, it's pretty simple. I expect the site's users will hit it with a variety of browsers including IE 5.5, IE 6, IE 7, IE for Mac and my personal favorite, Firefox and I'd like the site to look the same to all users. I also like the "idea" of separating code from content and think CSS is the way to go. XHTML "seems" to be the future for web sites.

Whether or not I can actually accomplish this in ASP.NET 2.0 remains to be seen and I haven't "tilted at a windmill" in a few years. After this perhaps I'll rename my blog "The Dev from LaMancha".

Jeff

Sam,

The statement you made about how IE 6 renders content in quirks mode since the content is served as text/html is incorrect. IE 6 renders in standards compliant mode as long as you have the correct doctype specified. Here's the msdn post on it: http://msdn.microsoft.com/library/?url=/library/en-us/dnie60/html/cssenhancements.asp

Also, I setup two pages as a test.

http://uallas.com/sandbox/ietest/compliant.html

http://uallas.com/sandbox/ietest/quirks.html

Both use the exact same stylesheet but you should notice a visible difference.

What I'm trying to say is this: Say you can easily create an XHTML compliant website with ASP.NET2 (or any web framework).

Is it desireable to do so?

My opinion is no. Because a perfect, validated XHTML document will force IE into Quirksmode. There are two problems:

IE doesn't support the XML prolog. It can parse XML, or transform it, but it uses MSHTML, so it's not really XML. This might seem like a semantics game until you realize that what this means is that you'll be viewing XHTML documents in Quirks mode.

IE doesn't support the "application/xhtml+xml" MIME type. The results are the same as above: A Quirks mode rendering.

Why is this important?

This page can give you an idea: http://www.quirksmode.org/">http://www.quirksmode.org/

Many IE "bugs" have actually been fixed, such as the box-model issue. Most of these only apply to Standards/Strict mode however. It means by creating your document in such a way that degrades to Quirks mode, you actually turn off all these fixes, and go back to rendering in a way that's compatible with IE4/5.

This means you'll have to use a lot more hacks. For example, in Standards/Strict mode the following should look the same in Firefox and IE:
What I'm trying to say is this: Say you can easily create an XHTML compliant website with ASP.NET2 (or any web framework).

Is it desireable to do so?

My opinion is no. Because a perfect, validated XHTML document will force IE into Quirksmode.

Why is this important? This page helps: http://www.quirksmode.org/">http://www.quirksmode.org/

Many IE "bugs" have actually been fixed, such as the box-model issue. Most of these only apply to Standards/Strict mode however. It means by creating your document in such a way that degrades to Quirks mode, you actually turn off all these fixes, and go back to rendering in a way that's compatible with IE4/5.

This means you'll have to use a lot more hacks. *Especially* if you're using CSS for layout.

Do the advantages of using XHTML (namely referencing other namespaces) outweigh the increased work, and limited browser support for it?

Your Javascript pallette will be limited since XHTML doesn't support things like document.write(). DOM manipulation is painfully slow in most browsers (see http://www.developer-x.com/content/innerhtml/dom_vs_innerHTML_perf_test.html and http://www.quirksmode.org/">http://www.quirksmode.org/dom/innerhtml.html). In browsers that display XHTML correctly, if it's not PERFECT, you'll see an error instead of a page.

Even after all that: Considering namespacing issues, and the strict nature of XHTML well-formedness, my guess it's probably next to impossible to get "real" XHTML output from a component based web framework (such as ASP.NET) anyways.
<div style="margin: 10px; padding 10px;">Test<div style="margin: 10px; padding 10px;">Test 2</div></div>

Wow... that post is really messed up. Sorry about that.

Chris:

You're missing the prolog/encoding.

It certainly demonstrates that there are hacks to make IE render XHTML *as HTML* in Standards mode, but that's not the same thing as creating and rendering XHTML. For example, did you see a warning when visiting those pages in IE? You should have if IE handled XHTML as XML. It doesn't.

And unless you're actually using XSLT, MathML, SVG, etc, the value of XHTML is dubious right now anyways.

That's probably why in the same IE blog post where Chris Wilson says "We have fixed the DOCTYPE switch so it will skip an XML prolog, so that valid XHTML can be handled in strict compliance mode rather than quirks mode.", he also mentions "if we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs.", and goes on to say that we won't see true XHTML rendering until "after IE7".

I think this page says it better than I can: http://www.robertnyman.com/2005/06/26/xhtml-and-error-handling/

I like this snippet: "My thoughts about this started partly by seeing many web developers writing XHTML 1.1 web pages and then send them as text/html, and they were only using it because it was the latest thing, not for any features that XHTML 1.1 offers"

:-)

I know that described me to a T. I'm guessing the same is true for most web developers.

Ok, so I've said a lot of words, but they aren't making any sense and you're still not convinced. ;-)

How about this then: You can't use "text/html" with XHTML1.1. That's right, in the latest version, you won't even be able to validate a page that IE can render. (At least that's how I understand it since IE won't render such a content-type.)

I disagree and think it is completely desirable to do so. My entire website sans my blog is XHTML 1.0 Strict compliant and renders in IE in standards compliant mode. I do not specify the application/xhtml+xml MIME type because that's only required for XHTML 1.1 which hasn't been ratified as a standard yet. Feel free to broswe to http://uallas.com and click the validation links along the footer to see for yourself that they validate. I think you may be misinterpreting the XHTML 1.0 standards in that you seem to think they require the xhtml+xml MIME type to be compliant which simply isn't true. It almost seems like you're confusing XHTML and XML. Even the Web Standards Project website (http://webstandards.org/) uses the text/html MIME type and they're probably the largest body behind the current push of standards compliance.

Just out of curiousity I checked all of the non-Microsoft standards compliance pages Jeff kindly linked to and they are all served up as text/html.

Great discussion guys!

Given how long it took for XHTML 1.0 to become a standard, I "believe" we will be using it for several more years at least. As for the MIME type issue, that is really up to the browser and web server developers to implement.

Thanks for the great comments! I really appreciate the feedback.

Jeff

Thanks Jeff! I do weddings and bar mitzvahs too! :-)

Chris:

It's great to have a little friendly back & forth, thanks.

Here's the forth: ;-)

This is a complex, multi-faceted issue, and I'm certainly no authority personally; I'm just trying to regurgitate my understanding of what I've read and experienced. I do believe you're forgetting a few things though.

* You can have XHTML that validates, but renders in Quirksmode. You're correct that quirksmode isn't forced under all circumstances, so thanks for the effective demonstration.

* XHTML is XML. The opposite isn't true of course. This is why you should declare the xmlns for XHTML in your root tag (html) in your XHTML documents. I think you probably understand this, but I wanted to clarify the point.

* IE doesn't render XHTML as XML if served with the "text/html" Content-Type. It's just well formed HTML to IE. Test it yourself: XHTML doesn't allow "document.write()", but in IE, it will work perfectly fine in your documents. In Firefox 1.5 it looks like it works, but it actually breaks the document. In IE, it'll work just as you'd expect HTML to, because that's what it's being rendered as.

So there's really two very different things:

* Can you generate valid XHTML from your components?/Can you validate your XHTML document?

* Can you render XHTML _as XHTML_?

The answer to the second, in IE, is no. You can't.

So if we whipped out a notepad, and wrote down the Pro/Con list of going to XHTML for a site, what would the Pro list be?

Anything? Are you using other XML namespaces in your documents? Probably not.

Lastly, "I think you may be misinterpreting the XHTML 1.0 standards in that you seem to think they require the xhtml+xml MIME type to be compliant which simply isn't true.":

I think you're misunderstanding me. It's not that XHTML 1.0 doesn't allow the "text/html" MIME type. It's very clear that it does. The point is that if you serve XHTML with that MIME type, then *no browser I'm aware of will actually treat it as XML*. This is very important. It's basically the whole point of using XHTML. So if you're not using "application/xhtml+xml" (and that would be silly for most sites since it'd cut IE out of the picture), and your content is rendered as very good HTML, then why are you using XHTML?

Let me emphasize that: If to the web browser _there is no difference between your XHTML document, and any other HTML4.01-Strict document_, why are you writing XHTML? Neither of the two biggest browsers out there (IE and Firefox) actually support XHTML rendered as XHTML adequately.

If your answer is "because I can", then hey, that's cool. It's just that it seems to be implied that there's some sort of inherent value in a lot of cases that actually, just isn't there.

I'm not saying don't write to the standard. I always close all my tags, use double-quotes, lower-case all tag names, etc etc. Writing good stuff is good. It's just using the XHTML doc-type that's a bit overrated _in my opinion_.

Then again, I use a lot of Javascript in my sites. I'm all about the AJAX/Web2.0/BuzzwordOfTheWeek stuff. ;-) Unfortunately browsers are (generally) very very slow at DOM manipulation. Since "real" XHTML forbids innerHTML, you've got a choice: Don't use much Javascript because your site will feel like a bloated cow, or break compliance with XHTML.

And if you're not compliant, then why use the doc-type in the first place? Prototype/ScriptAculoUs/Behaviour gives me something very tangible. I can't say the same for XHTML. Can you?

PS: Jeff, you're a patient man. :-)

Sam:

No, I'm not really very patient (just ask my wife) but this discussion is excellent and you both bring up some great points. I wish the "web standards" community at large would discuss XHTML, CSS, etc. from a broader perspective like this, rather than just trash IE. I've already learned several new things from this discussion and I look forward to your future comments as I move forward with this little "quest".

Jeff

My apologies Sam, I didn't even realize there was an HTML 4.01 Strict DTD. Now that I do am I going to stop using the XHTML DTDs? Probably not, but it's still good to know. As for the whole AJAX thing, I probably won't jump on that bandwagon. I have an app I built at work that worked flawlessly using some fancy javascripting (not AJAX) for several years and then I go out of town for some advanced .NET 2.0/VS2005 training and it breaks all of a sudden. I have no idea what changed on the PCs and have had zero luck finding the root of the problem so I'm pretty burnt up on javascript in general and will only use it where absolutely necessary. Don't get me wrong, I think the whole AJAX thing is cool just as much as the next guy, I just think javascript seems to fragile. Regarding my app, it's intranet only so I'll probably be rebuilding with WinForms and using ClickOnce deployment. It suxors.

Hello Sir/Madam, I am web developer. I am creating web application, which must be pass w3c accessibility level 2. I really do lot of efforts on accessibility in web application. I am using VS 2005 and ASP.NET 2.0. Please let me know, is this possible? I had experienced the following problems/error while validating the web page through w3c accessibility validators: 1. Missing NOSCRIPT: there are no NOSCRIPT elements in the page. As you know every web page renders Script to post the page in asp.net. But it does not follow the