gnuherds-app-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS branch for XHTML ?


From: Davi Leal
Subject: Re: CVS branch for XHTML ?
Date: Sun, 25 Feb 2007 18:50:41 +0100
User-agent: KMail/1.9.5

Victor Engmark wrote:
> Davi Leal wrote:
> > 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?.

They are not technical but supposed strategic benefits, 
http://www.nypl.org/styleguide/xhtml/benefits.html

> 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.

So, good for HTML.


> HTML gives you lots of possibilities to mess up the tree structure of the
> document,
We should use the validator any way.

> making it slow to parse,
What is a millisecond more?

> prone to different display results in different browsers,
No if it is HTML 4.01 Strict + CSS.

> 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<http://www.mozilla.org/projects/xforms/>extension is well under
> way. Why limit ourselves to HTML?

I agree with you about the project must not be limited. So I think it would be 
good idea to try XHTML Strict in a CVS branch.

Davi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]