Hi there,

Wendell Piez wrote:
>You can decide that, 
> XHTML being a "terminal format" not suitable for input to any process 
> other than certain specified target applications (a known set of 
> browsers), formal validation of XHTML doesn't matter as long as the 
> browser does "the right thing" with ul/ol inside p. (Most browsers do.) 
> While this might be controversial --  it is almost certainly too hopeful 
> and a potential cause for regret -- it may be warranted by XHTML's own 
> modeling here. "A chunk of text presented discretely, generally 
> delimited in presentation by vertical whitespace or an analogous pause, 
> whose content can be displayed entirely as a line-wrapped sequence of 
> characters", if it's a fair description of the HTML "p", implies that 
> XHTML has no meaningful semantics (which is a long way of saying "no 
> semantics") beyond the presentational. But this is manifestly what TEI 
> does *not* mean by "p".

This was partly my point earlier today, but I'd still contend that, 
rather than gamble on browsers doing the right thing with bad code, it's 
better to create more anonymously-structured output using divs for 
paragraphs (and other blocks such as <ab>s), and spans for inlines. If 
XHTML is a "terminal format", then this is perfectly reasonable. Even if 
it's not, it can still be XSLT-processed on the basis of element-name + 
class-attribute matching.

The ONLY difference between using XHTML and using XML in a browser is 
that XHTML gives you access to a default browser stylesheet, which saves 
you from having to exhaustively define <p>s as display: block, <span>s 
as display: inline, and so on. Where <p> gets in the way, there's no 
reason to use it, IMHO. We're not far off being able to use pure XML+CSS 
bound to JavaScript events directly in the browser; that'll eliminate 
the need to transform into XHTML at all.


Martin Holmes
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]