W3C home > Mailing lists > Public > www-style@w3.org > January 2006

Re: [Selectors], XSLT, and a browser's internal view of an xml document

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 29 Jan 2006 10:11:10 -0600
Message-ID: <43DCE91E.8000108@mit.edu>
To: Noah Scales <noahjscales@yahoo.com>
CC: www-style@w3.org

Noah Scales wrote:
> Mozilla allows XSLT to create an internal view (If I
> understand the STTS 3 meaning of "internal view")

The term is used exactly once in STTS 3 in a rather vague way and is never 
defined, so I'm not sure what exactly you think XSLT does.

What XSLT does is to take one DOM and create another DOM.  This other DOM is 
then rendered.  If the other DOM has CSS applied to it in some way (eg 
<html:style> elements), the CSS is applied.  If not, then no.

> but more likely you output selectors
> from your XSLT transformation to add style to your XML
> source document

You don't add style (CSS, that is) to the source document with XSLT.  Ever.

> unless the output format is XHTML.

Or SVG?  Or MathML?  Or MusicML?  Or any of a whole bunch of other things?  As 
far as I can tell, all you're saying is that if you use XSLT to transform to 
random XML with no semantics you generally have to use CSS to indicate 
presentation of the result document.  Of course presenting random XML with no 
semantics is rather an abuse....

> You can't style arbitrary XML without CSS + CSS
> Selectors, unless you use the CSS namespace

What CSS namespace?

> or you think XHTML is arbitrary XML(like I do).

XHTML has well-defined semantics.

> Or the CSS working group decides on (a limited form of) XPATH as
> their selector language.

This part I don't follow at all.

> CSS functions like attr() (and content()?) combined
> with selectors provide transformations.
> Transformations to an internal view, something that
> XSL can do as well.

Again, I'm not sure what you're saying.

> But without the CSS namespace, XSLT really CAN'T style
> XML without using CSS Selectors. Embedded CSS in an
> XML document has to use CSS Selectors.

It needs to use some selector mechanism.  At the moment, the only selector 
mechanism CSS allows is Selectors (the specification under discussion).

> Since that's
> true, does CSS + Selectors = CSS + STTS? Your working
> group could decide so. 

STTS modifies the DOM.  CSS does not.  Selectors is just a selection mechanism. 
  I _really_ don't follow what your equality above means.

> After all, why use XPATH+XSLT+Selectors+CSS when you
> can use Selectors+CSS?

Because the former allows things that the latter doesn't, of course.

> Why use the performance-dragging when you can use the
> performance-critical?

Because the former allows things that the latter doesn't, of course.

> Maybe that's what browser vendors think.

Browser vendors aren't stupid, you know.  Can't speak to the coders you 
mentioned earlier.  ;)

> Why use XML+CSS when you can use XHTML+CSS?

Good question.  The answer may be "because your semantics cannot be expressed in 
XHTML".  Consider MathML, for example.

 > So you all won't decide on a CSS namespace

Again, what does that mean?

> OK, maybe I'm getting carried away, maybe.

Looks like it to me.  And not bringing the rest of us with you, unfortunately.

> Still, if the CSS working group decides to keep
> developing a selector language that is
> performance-critical, then how about an XML version of
> CSS Selectors that's performance- critical right now?

What does being XML have to do with anything, exactly?

The performance aspect has to do with what selectors are allowed.  XML or not is 
just the syntax.  You could sit down and write an XML syntax for the selectors 
in Selectors if you want and publish the result.

> Can you describe what it does and doesn't do? Your
> answer about matching an element to selectors instead
> of a selector to elements is a bit vague.

How is it vague?  With CSS the question that needs to be answered is "Here is an 
element, what rules apply to it?"  Selectors is somewhat careful to optimize for 
answering this question.  In other use cases, a more useful question is "What is 
the list of all elements which match some criteria?"  Selectors does _NOT_ 
optimize for answering that question.  That's all there is to it.

> You could help me use XSLT in a way that operates more efficiently with major browsers.

What does that have to do with either CSS or the Selectors spec, pray tell me?

Received on Sunday, 29 January 2006 16:11:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:22 UTC