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

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

From: Noah Scales <noahjscales@yahoo.com>
Date: Wed, 1 Feb 2006 16:27:06 -0800 (PST)
Message-ID: <20060202002706.75090.qmail@web50408.mail.yahoo.com>
To: www-style@w3.org

Hi, Anne.

--- Anne van Kesteren <annevk@opera.com> wrote:

> Actually, XSLT changes the DOM and therefore the
> semantics of the  document... From what I understand
of STTS it would not do such a thing.

OK. It's confusing for me to properly relate the

- changing versus not changing the DOM.

- serialization versus rendering.

- rendering in static versus dynamic contexts.

- data type-defined semantics (allowed types/regex's
of node contents) versus grammar-defined semantics
(allowed placement and nesting of nodes).

- schema-defined semantics versus what a parser knows
about a particular xml document's contents.

- transformation versus matching versus representing
(as in representing nodes to create).

- presentation versus content.

- inheritance of CSS values versus
Selector-specification of CSS values versus
inline-specification of CSS values.

Sorry, and thank you for your patient reply.

> (CSS declarations can appear inside style=""
> attribute constructs. Such a  style="" attribute is
> available in various markup languages, including  
> XHTML and SVG.)

In CSS3, if you want to specify multiple inline
attributes inside arbitrary XML, you have to use
separate attributes and then separate selectors for


foo[width] {width:attr(width,px);}
foo[height] {height:attr(height,em);}
<foo width="100" height="200">bar bar</foo>


<foo css:style="width:100px;height:200em;">bar

So a css:style attribute is convenient. A css:class
attribute would help mark-up authors who want to embed
CSS rules in a document.

> How exactly would an XML version of Selectors be
> different from the current Selectors draft? There is
> at least one XBL proposal (as pointed out
previously) > that uses Selectors to select elements
in an XML 
> tree. No modifications necessary.

Well, you might remember something similar:

<style xmlns:css="http://www.w3.org/now-css-xml">
<css:height value="attr(height,px)" />

Or maybe 

<css:style xmlns:css="http://www.w3.org/now-css-xml">
<css:rule selector="foo">
<css:height value="attr(foos-height,px)" />
<css:rule selector="bar"
value="{width:attr(foos-width,px);color:green;}" />

The advantages of CSS-XML are subjective to (and
perhaps misunderstood by) me. Perhaps the advantages

- Custom schema let you develop and enforce
fine-grained control of CSS-styling of any mark-up.

- it's easier for a mark-up author to choose which
serialization language, CSS attributes or XSL-FO, is
more suitable for the task at hand? Less complacent
use of CSS for tasks unsuited for it. More use of CSS
by people needing less than XSL-FO requires.

- The Selectors specification won't be limited to
performance-critical functionality? Mark-up authors
will need to use it to add style attributes.

- Custom mark-up can be fine-tuned using inline
styles, rather than using selectors linked to ID's.

- CSS use with custom schemas will be distinct from
Selector use with custom schemas, so multiple selector
languages could be implemented inside CSS? Mark-up
authors could choose to use one over another. 

- CSS styling of custom mark-up would be easier to
output from XSLT/XQUERY? Only because you can style
elements individually, and the css rules rely on XML
and simple 

- CSS styling of custom mark-up would be easier to
author by hand? Of course a lot of handcoders hate XML
and would disagree.

- CSS styles modified through a WYSIWYG interface
would produce source code that's easy to mechanically

- Fine-tuning the presentation of custom mark-up would
be easy using inline styles.

- the distinction between content and presentation
would easier for schema designer's to make? Rather
than add presentation elements to your custom mark-up,
or extend XHTML with presentation elements, your
mark-up can be entirely distinct from presentation
mark-up. You can mechanically remove presentation
elements from a document simply by removing the CSS.

I made a similar presentation last month. Perhaps I've
have taken this as far as it can go.  Thank you for
your time.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
Received on Thursday, 2 February 2006 00:27:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:43 GMT