[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bad News on IE6 XML Support
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: email@example.com
- Date: Sun, 09 Sep 2001 01:32:55 -0400
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
> 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
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
> 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"
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
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.
O'Reilly & Associates, Inc.