Lists Home |
Date Index |
- To: "Elliotte Rusty Harold" <email@example.com>
- Subject: RE: [xml-dev] What is the rule for parsing XML in a namespace inside HTML?
- From: "Joshua Allen" <firstname.lastname@example.org>
- Date: Tue, 13 Jul 2004 10:34:09 -0700
- Cc: "XML Developers List" <email@example.com>
- Thread-index: AcRo+ckDxWhvLCHWTgae9yG+vPao1AAAbJuA
- Thread-topic: [xml-dev] What is the rule for parsing XML in a namespace inside HTML?
> XHTML, then one can legitimately lay the blame at the feet of the
> browser vendor.
I am just saying it's bad advice to tell a user to go do something which
we know darn well doesn't work and probably will not be fixed anytime
soon. Assigning blame doesn't help the user get her web page working.
> narcissism here is Microsoft's claim that because they don't support
> XHTML it doesn't matter and doesn't work.
First, the poor support for XHTML extends far beyond Microsoft. The
market for tools which consume and produce HTML is vastly more mature.
Second, my reasons for discouraging use of XHTML are not based on the
poor browser support. I was simply arguing that people who *encourage*
XHTML, while knowing the reality of poor tools support, are not
advocating on behalf of the user. It's user-hostile to ask someone to
abandon tools that work and use buggy tools to create a page; when the
only appreciable benefit is that "some guy named Elliotte who I don't
even know might write a screen scraper for my page". The fact is, you
probably will never write a screen scraper for their web page, and this
possibility is very low on the average user's list of priorities. They
just want something that works. Projecting your own desire to write a
screen scraper onto the general population is bound to result in flawed
My reasons for discouraging XHTML are that it has no appreciable
benefits. Users should either stick with HTML; or if they want to have
a pure machine-processable architecture, move to XML+XSLT+CSS. XHTML
serves no purpose that cannot be met with either of those other two,