Re: Computational complexity of CSS

Paul, the reason of problem with this:

p.navbar > a {display: inline; other stuff for all links;}
a.hidden {display: none;}

is pretty simple - specificity order of these two styles is following:

a.hidden {display: none;}
p.navbar > a {display: inline; other stuff for all links;}

so second display: inline overrides first display: none. This is it.

And this is quite far from what we are discussing in this topic.

Having said that I would note that CSS++ (css with classes)
construction like:

p.navbar
{
   background: blue;
   [
     a {display: inline; other stuff for all links;}
     a.hidden {display: none;}
   ]
}

is more I would say natural and predictable and effectively reduces O(N*M) 
problems.

Andrew Feodoniouk.
http://terrainformatica.com



----- Original Message ----- 
From: Paul D Stanwyck
To: www-style@w3.org
Sent: Thursday, November 17, 2005 2:10 PM
Subject: Re: Computational complexity of CSS


Malcolm Rowe wrote:
On Wed, Nov 16, 2005 at 12:53:19PM -0800, Andrew Fedoniouk wrote:

I beleive that at least some recommendations should be
published on W3C site like:

".a1 > .a2" is better than ".a1 .a2"
"p[a1]" is better than just "[a1]",
etc.

I think I'm right in saying that at least the second of those will
actually be _slower_ in Gecko: it resolves style from the 'inside out',
so upon adding an attribute 'a1', it will actually have to do additional
work to check that the attribute belongs to an element called 'p'

In my very recent experience (using Firefox), I found this point to be very 
important.
Although I cannot comment on how "fast" such mechanisms are, I can tell you how 
effective they are. When I wanted to use CSS to inhibit the rendering of a link 
within a navbar I wrote this:
    p.navbar > a {display: inline; other stuff for all links;}
    a.hidden {display: none;}
It didn't work. My intiution was that the second line would NOT need specifics 
like "p.navbar >" because of the CSS Rec stating that selectors such as:
    a[attr]   p.class
Need only be coded as:
    [attr]   .class
Soon enough, I learned that by coding the entire selector specifically:
    p.navbar > a.hidden {...}
The problem was fixed. It would seem that, at least, Firefox has treated this as 
a preffered means of using selectors. That being said:

Even if that's not entirely accurate, it's still true to say that those
kind of suggestions would have to be made in the context of a specific
implementation, because, as several people have mentioned, the assertions
you've made above don't actually follow from the specification at all.  So
I could see Mozilla or Opera publishing 'Optimising CSS for {Gecko,Opera}'
documents, perhaps, but it's not really something that falls to W3C to do.


This is absolutely true, IMHO. The CSS WG cannot do much more than to maybe make 
it known, somehow, that user-agents will do the parsing in that implementations 
own specific way. But even doing that is almost out of the scope of the WG as it 
is.

I would also like to state that I am just an interested end-user for the most 
part and did not bring this up to debate how I could/should have coded the link. 
I just thought that it ran along the lines of this thread and decided to share 
it.

--Paul Stanwyck

Received on Thursday, 17 November 2005 22:57:56 UTC