RE: Bad News on IE6 XML Support

["Simon St.Laurent" <simonstl@simonstl.com>]

At 10:00 PM 9/8/2001 -0700, Joshua Allen wrote:
>OK, on this thread we have seen people make some pretty vague and
>sweeping generalizations; I have seen claims that IE has the best CSS
>support, Netscape, and now we are talking about Opera.  So I might as
>well add my own.  I have found that I can use client-side (or
>server-side) XSLT to transform XML into well-formed HTML using CSS, and
>have been able to do most of what I want in most cases.  This is
>provided that I use XSLT to do the structural transformation and CSS
>just for "styles".

Sure.  _You_ can do that.  I can't say that message "use XSLT to transform 
your XML into HTML+CSS" goes over well with the thousands of Web designers 
for whom learning CSS was already work and for whom XSLT looks like 
yet-another-ugly-acronym-to-cope-with-as-best-as-possible (YAUTCWOWABAP).


>   I have also found that practically any CSS feature
>that really would have made my life easier was completely un-implemented
>on *any* browser -- these are features like the selectors that let you
>insert content before or after, so are not exactly "style" oriented
>anyway.

Sure, though I'd settle at this point for basic rendering like the CSS2 
display properties.  Makes checking out XML - any table-structured XML, 
actually - really easy to display in Mozilla, among other things.  Make my 
life easier!

>   There are some other issues, like performance of CSS on large
>documents, that have forced me to use other solutions at times.  These
>are some big problems that have no workarounds that I am aware of, other
>than not using CSS.  I am sorry, but from my experience, I don't really
>think *any* browser can claim to have "good" CSS support.

Have you tried Mozilla?  I'd hope you've at least looked at it for 
competitive reasons.  I'm not quite ready to give it a seal of approval, 
but in this area I'm find that it has genuinely "useful" CSS support.

>   Or else
>"good" is a really subjective word.  If you stick to simple
>lowest-common-denominator stuff, it's "OK".  But that is about as far as
>I would go.  For anything beyond simple styles, the "remaining barriers"
>are formidable.

I'd settle pretty happily at this point for CSS to have some means of 
coping with XLink  and for support of the CSS2 display property.  Creating 
hyperlinks and embedding images (etc.) in documents is pretty fundamental 
(XLink), as is layout beyond block/inline/list-item/hidden.

>Well, this brings up the question of why we need XHTML in the first
>place, if we can just attach CSS to XML?

That's the conclusion I've reached lately.  Legacy browsers and a 
vocabulary people feel comfortable with are the only remaining reasons I 
can find to keep HTML alive.  If it wasn't for legacy browsers and the 
issues we've been discussing in this thread, I'd be happy to throw off the 
straitjacket of (X)HTML.  (I regard XHTML as more processable than HTML, 
but that's not all that exciting to most people.)

>   Actually, I think that browser
>support for putting CSS on XML is actually *better* than support for
>XHTML.

I find it easier to style XML than to have to consider what HTML equivalent 
is appropriate and then style it.

>   Sure CSS support in general is not so great, but it is easy for
>example to just produce a well-formed XML document that is all <span />
>tags with the original element/tag name becoming the class="" attribute.

That's kind of an abuse of span, which I think is pretty much meant to be 
inline.  It also doesn't get you any closer to tables, which you can do in 
CSS2 without having to muck around _at all_ in XSLT.

>This is just a slight modification to the XSLT identity transform and
>then even Opera can render this XML correctly with CSS. This adheres to
>the idea of letting XSLT do structural transform, and letting CSS apply
>style to the structure (separation of presentation and content, etc.).

Well, based on the idiosyncracies, I suspect that's more or less what IE 
does to XML under the covers.

At best, it seems like a lot of extra work for zero benefit compared to 
working with XML+CSS directly.  I can't say I feel any need whatsoever to 
"let XSLT do the structural transform" in cases where reorganizing the 
document isn't necessary.

>XHTML seems (to me) to sort of violate the separation by making tags
>like <i>, and <b> that actually have presentation semantics implied.  So
>personally I choose to just use the identity-transform trick to let me
>apply style to well-formed XML without mushing the meanings (and it
>works in all browsers today).  Again I may be off-base, but since you
>mention that XML+CSS is a step up from (X)HTML+CSS (and I strongly
>agree), I am wondering why more people do not just go there?

Well, there are these browsers in the way.  Some are legacies, some came 
out last week.  I could do this identity transform workaround, but it's 
pretty ugly and might require me to set up extra processing on the 
server.  For folks who maintain sites with static files - still lots of 
them, me included - that means changing infrastructure.

So without browser vendors coming around to the notion that a browser built 
on HTML is a pretty weak substitute when it's time to present XML, the rest 
of us are stuck where we are.  Using XSLT to transform XML to HTML, even in 
the simplest possible way, is still counter-intuitive and means writing 
different and extra style sheets.

Simon St.Laurent
Associate Editor
O'Reilly & Associates, Inc.