I think it’s cleaner more powerfull and it doesn’t introduce new combinators.

Hell, if they can implement most of the CSS 2/3 selector stuff in javascript before Microsoft could implement some of it for IE 7, I wouldn’t be surprised.

Let’s hope that all the heavy hitters get on board and push this through!

Something like:

<div class="box">
  <span class="box_head" />
  <span class="box_body" />
</div>

…

span.box_body < div.box > span.box_head
{
  css code
}

This should allow us to access any level of the DOM hierarchy based on any selector.

But..

Since I’m not an expert on browser implemantation. This is just an opinion..

Nowadays, we are already doing this. WITH JAVASCRIPT :( !!

And the designers will continue doing this and many other things that will reduce the browser performance more and more.

Allowing us to do that providing the best method the browser can achieve (performatically) via a CSS syntax should standarize the way we do things like that.

This should improve the actual performance since we already do this by worse ways.

In the example you used a > img the > symbol represents not an arrow, but the descendance of the img element on the DOM.

Something like the img element is inferior (minor) than element a.

So, the correct syntax, in my opinion, of course, should be:

img < a

Wich represents that the a element is superior (greater) than element img.

This keeps the a element on the end of the syntax. Like the descendant selectors we are used to write in CSS.

This also looks more close to the javascript or jQuery syntax as well:

img.parent()

The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors.

But when trying to apply styles while rendering the partial page as it is served to the browser it makes perfect sense. There’s no need to re-query the partial document when the renderer encounters a potential target for a style—it already has its target, it just needs to (if you’ll excuse the expression) qualify it by examining its attributes and ancestors.

Is this same logic used for redraws? It seems like the right-to-left approach would be less efficient once the DOM is already constructed.

I think the disbelief (and grief) that implementors get from designers and developers when this type of selector is brushed off is due to diametrically opposed mental models of how CSS selects its targets.

Because we read and write left-to-right, we assume the parser does as well. That gives the impression that the parser would look at div a and think (as we do) “I need to grab all divs, then grab any as in those divs and apply this style” when (please correct me if I’m misunderstanding this) the truth is more like “I need to grab all as and then release any that aren’t an ancestor of a div.” We are more accustomed to interacting with a fully-realized DOM (thanks to your hard work up front).

There’s a trade-off between markup complexity and style resolution complexity. Where you want to stand depends on what you’re trying to do. If you’re writing a reasonably-short static document, you don’t lose much performance and you gain leaner, more maintainable markup by using more sophisticated selectors. If you’re writing a highly-dynamic web app (or, in the case targeted above, browser UI) then you’re better off using heavier markup so you can use dead-simple selectors.

Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant [emphasis added] and child selectors will actually make a page perform significantly better in all browsers.

Do descendant selectors really fall in that list? I’m not sure this particular topic gets talked about often enough. What’s the impact of each type of selector on rendering performance? Eg. what kind of effect does a selector like ol ul li have on performance? Is this documented somewhere?

The true utility of CSS—to me—is establishing context with a parent element and then styling its descendants based on that context, thereby minimizing repetitive and redundant presentational hooks in the markup. But from what you’ve said, it sounds like I’m “doing it wrong.”

For example, consider the rule:

.foo div { }

Now imagine some gigantic document with lots of divs sprinkled all over the place. Somebody then goes and sets the class name of the body to foo.

In WebKit, that will result in us essentially having to re-resolve style on the entire document. For a large page, that example could lock up the browser.

To expect that WebKit would know exactly how many divs were inside the body and where they are in order to do precise invalidation is unrealistic, since that would consume too much memory (especially as you started piling on arbitrarily complex rules).

The problems can get even worse when you chain selectors together.

.foo ~ .goo div { }

If some element suddenly acquires the class name foo, you have to examine every single following sibling and all of their descendants.

These sorts of cases are reasonably uncommon with forward chaining selectors (or at least the author scopes them reasonably well when they do occur).

With parent selectors it becomes extremely easy to accidentally cause a document-wide grovel. People can and will misuse this selector. Supporting it is giving people a whole lot of rope to hang themselves with.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.

For example style information can actually be shared across siblings and even cousins in a DOM tree if you know no sibling rules are used. WebKit typically achieves a 75% memory reduction in style footprint on pages that don’t make use of sibling selectors.

Descent into children can be avoided when changes happen if you know no descendant rules are used. Dynamic effects like :hover will perform better if descendant rules are avoided.

In many cases these rules can still be used and the performance will be perfectly fine. This is especially true on small blog pages that don’t get that large. However once you scale up (e.g., the HTML5 specification), the problems become more apparent.

I think you do not fully appreciate what it means to have to support selectors in a dynamic environment.

I’m quite certain that I don’t Dave. That’s why I asked for and appreciate browser developer insight. Can you give us an example of how the selector might be abused? Something as simple as body < a:visited?

That you have recent experience re-evaluating the problem is good enough for me, we’re just trying to get a better understanding of the problem.

In the end, I got back the performance, but at the cost of bloating memory.

If you think a parent selector can’t render pages unusable in 2008, you are wrong. It can quite easily. The problem with this selector is that badly written rules could lock up a browser. An additional concern is that authors would use these rules just for alternative browsers (leaving IE to perform well and degrading Opera/Safari/Firefox performance).

I think you do not fully appreciate what it means to have to support selectors in a dynamic environment.

CSS allows you to style elements based on an ancestor element but it does not allow you to style a parent element based on the presence of a descendant element.