Ernest N. Prabhakar writes:
> * Is XHTML a *strict* subset of HTML>
The XHTML draft has a page or two on compatibility; the intent is to
make it as easy as possible to write XHTML that current browsers won't
gag on, but there are a few gotchas. The most serious, if I'm reading
correctly, is that XML (and hence XHTML) requires values to be given
for all attributes in a tag, but HTML allows values to be omitted for
some boolean attributes (e.g., "checked" in form inputs), and some
extant browsers effectively require this. It's also somewhat tricky
to get a version of the singleton tags ("empty elements" in proper
jargon) which is legal XHTML and which current browsers won't gag on;
the recommendation is to write, say, the HTML <br> as <br />, where
the space is crucial.
All of this applies to "bare" XHTML; if you're using namespaces,
forget it.
> * Are their translations so HTML style sheets can be trivially recast as
> XHTML style sheets? Is this the same as CSS -> XSL? Or am I using obsolete
> terminology again?
See above; I'm not aware of any differences in the style attributes
per se which would require translations above and beyond what you'd
need to get browsers to swallow the tags themselves.
> * Will XHTML be 'properly' rendered by:
> - normal HTML browsers (to the limit of the mappings)
See above.
> - any XML-capable browser (that understands the concept of HTML)
I'll leave this to somebody more informed; I can't see any point to
building something this way now, but if XHTML came along too late for
somebody's shipping product, that product's HTML support could
conceivably be going through a different parser than the XML support,
which still gags on the incompatibilities mentioned above.
> * If I'm writing XHTML, which form should I use to be conservative? Strict?
> - If I'm writing HTML, should I start writing XHTML instead? Why or why
> not?
If you're writing stuff which will be embedded in an XML context, and
don't have a good reason to use some existing authoring tool, you
should strongly consider XHTML. If you're writing stuff which will be
sent, verbatim, to currently deployed browsers, I'd stick to straight
HTML (with abbreviated CHECKED attributes, etc.); the XML conventions
do involve some compatibility hassles with software now in the field,
so if you give yourself that pain, you should know what it's buying
you.
If you're storing structured data, I'm not sure I'd use either; store
it in an application-specific DTD, and translate it into ephemeral
stuff for shipment.
> * Does IE5 'really' support XHTML? Does anyone? Are people going to build
> it into web design tools (a la HTML/FrontPage) or into structured document
> tools (a la SGML/Framemaker)?
Beats me.
> * Is this really intended/going to replace HTML, or is it just a way to
> rationalize the pseudo-HTML efforts people (like the cell phone folks) are
> working on?
I'd expect that to depend on who you ask... there are probably people
involved in the XHTML effort who'd love to replace current HTML, if
only to get stuff which generally conformed to some real DTD, but
there are also probably others who just see it as an RPC tool. If
current HTML dies off, it's going to be a while yet.
> Inquiring minds want to know. The truth is out there... on FoRK.
Maybe, but don't confuse this message with the truth.
rst