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

Hi Noah,

On Sun, 05 Feb 2006 00:28:53 +0100, Noah Scales <>  
>> I don't think CSS as currently designed, implemented
>> and used fits really well in some tree-based
>> language.
> OK, but I'm flexible.


>> Also, the examples you gave still show the need for
>> some kind of CSS parser,
> The CSS working group decides whether user agents will
> parse CSS. You could redesign CSS to look like FO, but
> without page-masters and flow elements, if that's what
> you want.

Well not really, I rather keep data and style separate. Also after  
possible transformations have been done so that the final DOM tree is  
"semantic" in some way that it can be used by all kinds of devices and all  
kinds of tools can extract information from it without having to solve  
that problem at a higher level.

> If you can combine att:val pairs into a single style
> element, then you can style arbitrary mark-up the same
> way you style HTML right now. You can keep CSS rules
> with their current syntax inside a <css:style> tag.
> Just the ability to easily style custom XML is great!

Where is the need for a special <css:style>? From what I understand  
<?xml-stylesheet?> is supposed to solve that by doing something like:

  <?xml-stylesheet href="#test" type="text/css"?>
   <foo xml:id="test">
    heading { border-left:solid }

Unfortunately the XML Core WG has still not updated the document to make  
it clear how such inline elements are to be processed. (Proper error  
handling testsuites for that are also missing, although some have been  
submitted to the WG iirc by Ian Hickson based on some testcases I made  
long ago.)

>> the order of elements is significant
> The order of styled elements in the XML document, or
> the order of styling rules in the <css:style> tag, or
> what?

The order of elements in a style sheet expressed in XML. (Well, when you  
more or less copy CSS feature for feature.)

Anne van Kesteren

Received on Sunday, 5 February 2006 13:02:27 UTC