[Top][All Lists]
[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
- Re: HTML vs XHTML, (continued)
- Re: HTML 4.01 Strict + CSS -- Later XHTML if convenient?, Davi Leal, 2007/02/25
- Re: HTML 4.01 Strict + CSS -- Later XHTML if convenient?, Victor Engmark, 2007/02/25
- Re: The team have XHTML experience, Davi Leal, 2007/02/25
- Re: HTML vs XHTML, MJ Ray, 2007/02/25
- Re: HTML 4.01 Strict + CSS, Davi Leal, 2007/02/25
- Re: HTML 4.01 Strict + CSS, Victor Engmark, 2007/02/25
- Re: CVS branch for XHTML ?,
Davi Leal <=
- Re: CVS branch for XHTML ?, David Paleino, 2007/02/25
- Re: CVS branch, Davi Leal, 2007/02/25
- Re: The CVS branch is right, Davi Leal, 2007/02/25
- Re: CVS branch for XHTML ?, Victor Engmark, 2007/02/25
- Re: XHTML quicker ?, Davi Leal, 2007/02/25