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

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

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 31 Jan 2006 12:09:24 -0600
Message-ID: <43DFA7D4.3090708@mit.edu>
To: Noah Scales <noahjscales@yahoo.com>
CC: www-style@w3.org

Noah Scales wrote:
> The result of applying a CSS 3.0 stylesheet to an XML
> document, if it were serialized, may have different
> elements and attributes than the original XML
> document.

No, it may not.  If you think it may, you have a pretty fundamental 
misunderstandng of how CSS works.

> No one thinks about it like that unless, like me, they don't appreciate
> that the W3C CSS Working Group does not consider the
> result of applying a CSS stylesheet to an XML document
> to be worth serializing

I'm really sure what you're trying to serialize.  Again, CSS does not change the 
DOM.  Please illustrate with an example what you're talking about?

> "Your logic is basically the following: "XML documents
> may only consist of Unicode characters, so Unicode
> should actually be called 'XML Unicode'.
> That's clearly false, no?  What you're saying is
> equivalent."
> Well, other character encodings of XML are possible.
> For example, 'ISO-8859-1 XML'.

ISO-8859-1 is just a way of encoding Unicode characters into bits.  All XML 
documents consist of Unicode characters (by definition; see section 2.2 of the 
XML 1.0 specification, which very clearly says this).  The characters can be 
encoded into bits in various ways, again see section 2.2 of the XML 1.0 

The fact that you consider "Unicode" to be a character encoding is something 
that you should consider fixing.  It's a character set, not a character encoding.

> So your argument may be the following:

I didn't make an argument, actually.  ;)

> "It's inane/pointless/fruitless/unhelpful for you to
> distinguish Unicode XML from other character encodings
> when you are refering to XML in general. So it's
> inane/pointless/fruitless/unhelpful for you to
> distinguish CSS Selectors from XPATH Selectors when
> you are refering to Selectors in general."
> But the CSS Selector specification only discusses the
> one selector language CSS uses.

And that other languages also used.  A point you seem keen on ignoring.

It would be nice if naming could simply disambiguate "Selectors" and "XPath 
Selectors".  I never claimed to like the name "Selectors".  I just pointed out 
that your logical argument against it was not actually logical.

> "You claim this repeatedly, but this is simply not
> true.  If you feel that it's true for some reason, I'd
> love to hear your reason."
> If I interpret you correctly, you want my reasons to
> claim that an arbitrary xml document modified by
> embedded CSS can't be reserialized without including
> CSS Selectors in the document or in an external
> stylesheet.

CSS does not modify documents, so yeah.  I'd like to know your reasons for 
thinking that something like "an arbitrary xml document modified by
embedded CSS" exists.

> I think a counterexample better
> demonstrates the impossibility. Here's my
> counterexample.
> <?xml version="1.0"?>
> <page 
>     xmlns="http://www.awebsite.org/2006"
>     xmlns:xlink="http://www.w3.org/1999/xlink"
>     xmlns:css="http://www.w3.org/2006/css">
> <css:style>
> mylink {
>        hover-background:yellow;
>        color:rgb(255,0,0);
>        text-decoration:underline;
>    }   
> </css:style>
> <mylink xlink:type="simple"
> xlink:href="somepage.xml">some page</mylink>.
> </page>
> ----------
> after transformation by XSLT...
> ----------
> <?xml version="1.0"?>
> <page 
>     xmlns="http://www.mywebsite.net/2006"
>     xmlns:xlink="http://www.w3.org/1999/xlink"
>     xmlns:css="http://www.w3.org/2006/css">
> <mylink xlink:type="simple" xlink:href="somepage.xml"
> css:style="hover-background:yellow;color:rgb(255,0,0);"
> css:style="hover-text-decoration:underline;">some
> page</mylink>.
> </page>

I really don't follow this counterexample.  You're talking about XHTML, but 
there's no XHTML in sight.  You're using various namespaces that don't exist and 
that hence have undefined semantics.

So no, this is not what I was asking for.

> You can visualize an output XHTML file as a DOM tree,
> complete with style-named attribute nodes whose value
> is css att:val pairs

Meaning what?

 > and an input XHTML file as a DOM tree, with a single style element containing
> selectors.

Again, I'm not sure what you're getting at.

> But whatever data is created by applying
> CSS to an input XML document can't be output in XML at
> all, unless CSS Selectors are present in the output as
> well.

So let me see if I follow....  You have a file that contains some style 
information (say an <html:style> element with some rules in it).  You want to 
transform it with XSLT and somehow map the old style information into the new 
document?  And you're saying that at the moment this means that the transform 
result would haev to include something like an <html:style> element with some 
(possibly different) rules in it?

> The XML code counterexample demonstrates one way
> that's false.

If I understood your point correctly (see my previous paragraph), then I'm not 
sure I see what the counterexample demonstrates.  If I didn't understand 
correctly, please correct?

> The other, trivial, counterexample is if
> XPATH selectors are substituted for CSS selectors in a
> source XML file containing an xml-stylesheet
> instruction that points to an embedded CSS stylesheet.
> You asked what reason I have to say that. Well, can
> you add inline CSS to arbitrary XML elements and have
> a browser render it properly?

Is that all you're asking for?  A way to add inline CSS to arbitrary elements in 
arbitrary XML languages without having to specify a style attribute in each 
separate namespace?

> OK, perhaps you're right. So you mean that you can't
> use CSS to create an output file different from an
> input file, even though you use CSS to do the
> following:
>  - create sequence numbers.
>  - copy attribute values from one element to before or
> after another.
>  - insert text and images before and after elements.
>  - show and hide elements.
>  - do arithmetic (using "calc()"). 

That's correct.  All this only changes what the thing looks like when rendered 
on screen.  It doesn't change the DOM.

> So you can't get an xml serialization that reflects
> how CSS modified your XML file, because CSS, by
> definition, doesn't modify the input DOM tree created
> from your input XML file.


 > It's for XSLT to transform
> and serialize the input tree created from an XML file.
> Is my understanding improved?


Received on Tuesday, 31 January 2006 18:09:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:22 UTC