Re: XHTML 1.0 spec (was Re: Call for contributions: new and improved "Web site quality" articles

"Brian Kelly" <b.kelly@ukoln.ac.uk>
>    I understand your (and Jim's) rationale.  I got the impression at the
> WWW 2003 conference that the problem with dodgy XHTML was to be addressed
> with XHTML 2.0.

Getting a new markup language out won't solve the problem of dodgy XHTML,
dodgy XHTML is a user problem, not a standards problem - developers have
little incentive to author XHTML valid pages, as there's virtually no cost
in authoring invalid ones.  We can only change this behaviour by providing
real benefits in the valid.  As I see there's 2 options to this, ensure that
new UA's don't render invalid XHTML - this is completely unrealistic, UA's
need to render content that aren't 100% right, planes don't stop flying just
because the lock on the toilet door doesn't work.  Alternatively the UA's
can indicate that it's used some form of fixup, perhaps by not using the
users stylesheet or something that provides the content, whilst still making
it clear it's not right.

Whatever we choose we'll only be able to deploy these new User Agents
against application/xhtml+xml, text/html is lost - that means tag-soup, and
because of that we have to ensure that there's not a large userbase of
invalid XHTML ready to be dumped on this unsuspecting XHTML ua - if there
is, that UA will have to render it, or people won't use it.

>    BTW the reason I'm using XHTML 1.0 is
> (1) to gain experience of problems - as I'm now finding;
> (2) to be able to use XSLT to transform

This is a good reason, but we can still present HTML from XHTML sources,
it's just an extra publishing step, this may be too much trouble, but then I
don't find XHTML meets my needs as a storage format in any case - I'd rather
go RSS->HTML than XHTML->RSS, keeping the storage in the richer semantic
format.

Jim.

Received on Thursday, 2 October 2003 17:45:44 UTC