MikeGale wrote:1) Previous versions of markup need a declaration. Why break the chain?
Sort of. There's no denying that XHTML 1.1 conformance requirements call the DOCTYPE a "MUST", and If a document really does validate (in the true XML sense), then I'm all for making that assertion by referencing the formal definition in the document itself. Likewise, if you were to write a document to current XHTML5 proposals, there's nothing stopping you from writing a formal specification (and people have
http://syntax.whattf.org/) .
From the point of view of a browser that supports XML though (essentially all of them incl. IE9), XHTML™ is nothing special. XHTML is just yet another XML language whose elements are implicitly bound to styles. The thing which triggers that presentation is the namespace, not the doctype, which means the presentation is always identical regardless of which "version" of XHTML you're using (for now at least). This is correct behavior, and means that any kind of schema should only be used for it's real purpose - a way to inform others and UAs of the properties of a document's structure, not as a way of informing UAs about versions of a spec in order to treat documents differently on that basis.
That said, I don't think most people who write webpages understand XHTML modularization, and since XHTML 1.1's second edition became a recommendation a few weeks ago, the DTD is still a requirement. If you wanted to extend the schema, you would have to do the same to the DTD. In the future I'd suspect that wanting to do that will become both more common and more difficult if legacy DTD remains a requirement. (It isn't that bad, but
NVDL is easier). Even the official XHTML DTDs contain hacks to work around namespace issues by adding common ones as default attributes. They go further by making a special exception in the spec for "XHTML validators", and the W3C validator for instance works around the problem by hiding namespace-related errors.
With regards to the original poster, the CSE validator technically isn't a validator AFAICT, just a lint tool that's strictly limited to the scope of (X)HTML, but freaks out if you try to abuse it for either general-purpose XML validation, or an HTML language it doesn't understand. Even if CSE were a validator, as I said in my previous post, the correct behavior would be to not pass validation because the document doesn't (and couldn't possibly) conform to the specified DOCTYPE. It would be more correct to leave it out, and since XHTML5 is completely incompatible with IE, there's no reason for it anyway unless specifying a real DTD for validation.
2) The rest of the argument seems to depend on not caring whether it works in IE. In my real world I don't have control over what browsers the audience uses, I get whatever they've chosen to use, neither do I want to control. (Though I am delighted when a Netscape 4 or IE6, market share goes low enough that I can just ignore them, no testing every time I edit a page!) So any argument that's based on ignoring high market share browsers isn't valuable to me.
That's all perfectly fine and understandable especially if someone is paying you to support IE6. On commercial websites you don't really have a choice and will just have to make due with what's available.
When I'm not required to do this, I'm going to make available to users of modern browsers pages that emphasize correctness, scalability, and make use of all available standard features. I prioritize forwards over backwards compatibility wherever possible. My opinion is to judge by the intended audience. People who care about viewing web content correctly and wish to access pages which make use of more advanced media are not going to be using IE.
I don't feel bad about breaking things because
NOBODY uses IE by choice. At least no informed person, because it is strictly inferior to every other browser by every measure. The barriers to switching to a modern browser are very low due to the plethora of fantastic free and open source implementations of those standards which eliminate any rational reason there might be to continue using IE (lest your irrational tech department forces you because they're too cheap to update their intranet, or have backwards ideas about security). I'm also reasonably confident that such implementations will continue to be well maintained and free on all major platforms for the foreseeable future. Even if IE9 is a smashing success, the same can't be said.
One little known fact about IE is that as a last resort, IE makes use of the file extension to determine the document type even if served as application/xhtml+xml. I spent half a day testing things, even analyzing packets in wireshark fed to IE6, 7, and 8 in a virtual machine to make sure I was giving it the right headers, but it kept displaying pages as html rather than downloading them. It turns out I had to change the extensions to .xml or .xhtml to cause a failure. Though it's probably a bad idea to rely upon that behavior, it turns out there's no need to do bad content negotiation. It works so long as the xhtml documents are close enough to html to work (as is normally the requirement).
3) Even though a DTD/Schema isn't that great an design, they hold out the promise of being able to do what you want. Escaping from the dictatorship of a "one size fits all" specification. Albeit with extra work. Something that just works on all user agents. It sounds really good and would help those who want to do more. I gave it try some time ago. Can't recall the details, but it just didn't work in the real world. If that's changed please give me a reference. (Mind you no flaky, well it almost works, sort of stuff. I'm after something that's commercial/business strength and actually just works, across the browsers I encounter.)
Not quite sure what you meant by this one. Most current browsers fully support HTML4, XHTML, and CSS2 albeit sometimes inconsistently. For other languages, nobody supports every feature of any spec. If what you mean by the "real world" is IE, then yes, stable IE versions don't support hardly anything beyond basic CSS and HTML (and often incorreclty). Other browsers do consistently implement certain subsets of other languages to the point where I wouldn't consider them flaky, and XML makes for a great "one size fits all" base to build from. Any browser (but IE) should let you roll your own XML language and style it with CSS or XSLT. SVG is quite well supported to the point where it can be mixed with other XML languages or HTML5, styled with CSS, and manipulated with Javascript in a mostly predictable way.
http://apike.ca/prog_svg_threed.html http://totlandweb.info/reiko