The Future Of XHTML

Hello everyone,
Has anyone noticed that valid XHTML can sometimes not
be valid XML? Try it: simply change the extension of a
valid XHTML document to xml, or change the MIME type
at what ever server you have, and run it through a
validator. Doesn't work, does it?
I'm surprised that W3C haven't seen this bug before,
but there you go. This also ties in with the recent
problems outlined with the MIME type of XHTML -
personally I think a new one "text/xhtml" may be
needed, because it seems that XHTML is neither HTML or
XML at all.You may say "well it gets read by the
browser as HTML (text/html), but what if you had a
<br/> tag instead of <br />. In some browsers this
would give problems because it isn't HTML.
XHTML needs more thought put into it before XHTML 1.1
is released. Did anyone see the comments I made about
XSLT and CSS? Someone pointed out to me that it may be
better to break away completely from CSS and the old
HTML semantics of it. XHTML 1.1 should be a pure XML
language compatible with XSLT for the new upcoming
branch of XML browsers (e.g. IE5. Does anyone know if
Netscape 6 supports XML?). The Internet is evolving to
fast for some people to catch up, so backwards
compatability is always going to be an issue, but I
can see the days where we will be able to have raw
XHTML, our own XML, and XSLT all combined into one
document. Ad, what with the coming XForms and XLink
specifications, the future of XHTML could be very
bright indeed.
Imagine this:-
You could have a single document that is firstly a
structural document for all of your screen output:
this would be done with the XHTML modules. Then, you
could style this with a mixture of CSS and XSLT (or
only XSLT if I had my way!). You could then have
another part of the document that contained raw XML to
be interpreted by (perhaps) some script on the
viewable page, or maybe it itself could be transformed
into XHTML by a further XSLT document. Then, to add
insult to injury, you could further enhance the
document by adding interactivity, say including other
documents from a different server using XLinks, and
maybe a form here and there?
My suggestion is simple, can anyone work out a way of
making sure that a future XHTML document can do all
that I described above, as well as maintaining
backwards compatability? I'm sure W3C will manage it,
but they need to act quickly.
Overall, everyone will be saying that this is too much
of a gap to bridge in just one go, but does anyone
remember how quickly HTML caught on in the first
place? And what of ASP and all of the other Server
Side Scripting languages?
Actually, that brings me to another quick point, what
is W3C doing to address the unscrupulous people who
detect what browser the client is using, and then
deliver shoddy code as appropriate? This means you
could have a document with a marquee tag (perish the
thought) but that still validates as an XHTML page
through W3Cs validator. A bit of a nightmare problem
that!
Come on W3C, flex your corporate muscle, any carry
through all of your XML dreams - make us proud!
Sean B. Palmer
WapDesign ORG U.K. - http://www.wapdesign.org.uk/

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/

Received on Thursday, 22 June 2000 08:24:10 UTC