MJ Ray wrote:
> Davi Leal wrote:
> > fsf.org "works" on IE6 because of they send XHTML with a content-type
> > of "text/html". Sending XHTML that way means you get none of the
> > XML-related benefits due to browsers use the HTML parser -- It is written
> > with XHTML but actually working as HTML. [...]
>
> Are you sure? The FSF-related xhtml sites seem to render in
> 'Standards compliance mode' while the Herds site renders in 'Quirks
> mode' in Iceweasel.
Firefox works fine with XHTML content. IE however can not accept pages sent
with the XHTML mimetype.
However, when the mimetype is "text/html" Firefox drops own to using the
standard HTML parser. The rendering engine takes the output of the parser
(whether its XHTML, HTML, XUL whatever) and displays it.
Just serve as text/html to browsers which don't have application/xhtml+xml in their HTTP accept header. Problem solved.
There is little reason to use XHTML unless you are using any of its extra
features, which wont work in IE7 ;)
Redesigning is a lot cheaper now, when the site is in beta and nobody expects it to be perfect, than in two years (or whatever), when IE supports XHTML and you really need those extra features...
XHTML benefits?. Actually none of those benefits make particular sense. XHTML
is no more accessible than well written HTML.
You're saying that the benefits listed in my email earlier don't make sense? In what way?
Most mobile devices can handle HTML just fine.
What about those which can't? What about the ease of parsing (by humans and machines), which is listed many places as a major reason for changing?
Again good HTML is as logical and structural as XHTML.
That is simply wrong. HTML is inconsistent, with respect to upper/lower case and element termination. HTML mixes style and semantics in the markup, which makes it difficult to change styles and is inefficient WRT bandwidth. HTML gives you lots of possibilities to mess up the tree structure of the document, making it slow to parse, prone to different display results in different browsers, and hard to debug. All these are fixed by XHTML, even considering completely valid HTML vs. XHTML. Been there, done that.
Admittedly the XHTML might have merit, but only if you're considering
embedding other XML directly in the markup such as SVG or MathML, but most
browsers do not support that!.
So, because we're not using SVG (which could make a kick-ass UI in compliant browsers), RDF (which could be a very useful enabling technology), XSLT, XML Schema, or XForms (great for forms-driven sites) right now, we should just make it harder for the site to use those in a few years? Firefox and Opera already support client-side SVG and XSLT, and the
Mozilla XForms extension is well under way. Why limit ourselves to HTML?