W3C home > Mailing lists > Public > www-style@w3.org > April 2000

Re: Extensions to CSS3 selectors

From: Ian Graham <igraham@smaug.java.utoronto.ca>
Date: Wed, 26 Apr 2000 11:50:40 -0400
To: Jonas Sicking <sicking@bigfoot.com>
cc: www-style@w3.org
Message-ID: <Pine.SGI.4.05.10004261057130.32947-100000@smaug.java.utoronto.ca>

On Tue, 25 Apr 2000, Jonas Sicking wrote:

> On Tuesday, April 25 2000 Ian Graham wrote
> > On Tue, 25 Apr 2000, Jonas Sicking wrote:
> > > On Sunday, April 23 2000, Ian Graham wrote
> > >
> > > > On Sat, 22 Apr 2000, Tim Bannister wrote:
> > > >
> > > > > On Fri, 21 Apr 2000, Jonas Sicking wrote:
> > > > >
> > > > I would suggest (see [1]) the following specification:
> > > >
> > > > :empty  The Empty-Element Pseudo-Class.
> > > > ......
> > >
> > > Should whitespace only really be considered insignifican if the element
> is
> > > declared to be whitespace preserving? In xhtml (and therefor html?) the
> > > think the style, script and pre elements are declared to preseve
> whitespace.
> > > In XML any tag could be declared to preseve whitespace.
> >
> > That's a good point. My first though is that, if xml:space="default", then
> > such elements may or may not become empty after processing (depending on
> > the way the application deals with white space), so that treating both
> > cases as 'empty' means that rendering will be the same regardless of how
> > the processor handles the XML data. IMHO this is the desired behavior.
> >
> > It's less obvious with xml:space="preserve". HOwever, in this case I would
> > argue that rules such as
> >
> > elem:space[xml:space=default]  { one set of rules}
> > elem:space[xml:space=preserve] { another set of rules}
> >
> > would let you deal with this situation, while preserving the idea that
> > :empty means 'empty' in the expected sense.
> 
> What do you mean by "expected sence"? IMHO

I mean 'expected' in the sense that an author might insert white space
to make the markup more readable -- as in
<elem>
</elem>
without intending that the element be seen/processed as different from
<elem></elem>. 

> <E xml:space="preserve">   </E>
> should NOT qualify as empty since I think that setting xml:space="preserve"
> means that white-space characters should be treated as normal characters.
> When setting "preserve" you have to be extra careful that you don't produce
> any extra whitespace since it will probobly affect the end resault. For
> example, should this really be considered empty?
> <PRE>
> 
>
> </PRE>
> 
> How does the DOM handle this? When are textnodes created? does xml:space
> affect this?
> 
> / Jonas Sicking

The DOM doesn't say how and when text nodes should be created -- it simply
assumes that they do or don't exist. As far as I know this is the domain
of the overall application, which can choose (if xml:space="default") to
discard white space, if it deems this to be the 'better' choice [1]. This
means that the situation is essentially undetermined unless you explicitly
set xml:space="preserve" in the document.  Note that a non-validating
parser will make no assumptions about the value for xml:space unless it is
explicitly set for an element. Notably it is _not_ globally set for the
XHTML 1.0 DTDs (it is set for script, style, and pre elements) [2]. But, a
nonvalidating parser will not know this, and can still do what it wants
...  Thus default can mean either preserve or dont .. which is
somewhat confusing, to say the least...

For example, the MSXML processor will by default prune text nodes
containing only white space from the DOM tree. Thus the markup <a> </a>
becomes an element node with no text node child. However, the MSXML
processor will _preserve_ this text node if you set a processor parameter
(processorObjName.preserveWhiteSpace = 1 ). I believe it will also
preserve this text node if you explicitly set xml:space="preserve", but
haven't tested this. Nav6, on the other hand, preserves white space by
default.

But I see the problem you are raising -- that, if I set
xml:space="preserve" then I am really saying that whitespace is real
content, and I don't want my CSS to think it's empty.  In that case, it
might be better to change the proposal so that :empty does not match
elements that have xml:space="preserve" and that contain child nodes of
any type.

Does that seem more reasonable?

[1] http://www.w3.org/TR/REC-xml.html#sec-white-space
[2] http://www.w3.org/TR/xhtml1/DTD/ (and therein)

Ian
Received on Wednesday, 26 April 2000 11:50:56 GMT

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