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

Hello, Mr. Baron.

In response to the XSL working group, you point out:

"Selectors have been optimized for testing a single
HTML or XML element against a set of selectors rather
than testing a single selector against a set of
elements; this type of use is expected to be usable in
performance-critical code, even when performed
frequently."

Mozilla allows XSLT to create an internal view (If I
understand the STTS 3 meaning of "internal view") of
an arbitrary source XML document styled with CSS. You
could add css:style attributes to the internal view's
styled elements, but more likely you output selectors
from your XSLT transformation to add style to your XML
source document, unless the output format is XHTML.
You can't style arbitrary XML without CSS + CSS
Selectors, unless you use the CSS namespace, or you
think XHTML is arbitrary XML(like I do). Or the CSS
working group decides on (a limited form of) XPATH as
their selector language.

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

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. Since that's
true, does CSS + Selectors = CSS + STTS? Your working
group could decide so. 

After all, why use XPATH+XSLT+Selectors+CSS when you
can use Selectors+CSS? Maybe that's what coders think.
Why use the performance-dragging when you can use the
performance-critical? Maybe that's what browser
vendors think. Why use XML+CSS when you can use
XHTML+CSS? That's what some CSS working group members
think. So you all won't decide on a CSS namespace
and/or XPATH selector syntax, and CSS Selectors ->
Selectors -> STTS -> ... There are some deeper issues
here, about what the future web should look like,
maybe.

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

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?
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. Can you give
it some context? You could help me use XSLT in a way
that operates more efficiently with major browsers.

-Noah

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

Received on Sunday, 29 January 2006 14:13:13 UTC