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:40:37 -0800 (PST)
Message-ID: <20060202004038.83834.qmail@web50404.mail.yahoo.com>
To: www-style@w3.org

Sorry, I wrote that too quickly.

When I wrote:

- 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 

it should be completed by the phrase "selectors." It's
probably false, anyway, now that I rethink it.

Excuse my other grammar/diction errors. :-(

-Noah

--- Noah Scales <noahjscales@yahoo.com> wrote:

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


__________________________________________________
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:40:43 GMT

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