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

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
following:

- 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
each. 

So

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

versus

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

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:selector="my_webpage_header[@height]">
<css:height value="attr(height,px)" />
</css:selector>
</style>

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>
<css:rule selector="bar"
value="{width:attr(foos-width,px);color:green;}" />
<css:style>


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

- 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
process.

- 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.

-Noah

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

Received on Thursday, 2 February 2006 00:27:17 UTC