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

Hi, Boris.

The output document would have to contain CSS
Selectors if the output were XML in the form of an
embedded stylesheet pointed to by a #name in the href
of the <?xml-stylesheet> tag. Unless, as you point
out, its an XML language that contains a style element
that can hold CSS values. So not only XHTML allows a
style tag, but so does SVG. And a whole bunch of other
things (arbitrary XML formats)? So the css namespace
is useful to modularize how new XML formats can be
styled.

If what you write is true:

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

Then it should be called "CSS Selectors", for that
reason alone.

As far as why using the attr() and content() functions
combined with selectors creates an internal view of
different DOM than the original file, you need an
example in which use of the attr() function with
selectors creates a different DOM from its source
prior to transformation by CSS+CSS Selectors? Is
showing you an XSLT transformation that produces the
same output sufficient?

-Noah

--- Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?
> 
> -Boris
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Received on Sunday, 29 January 2006 20:52:35 UTC