This is needed to optimize our css. Currently, we need to use the famously inefficient descendant selector in order to draw a border around selected treerows when a tree has focus, like this: tree:focus > treechildren treeitem[selected][current] > treerow I suspect that this rule is partially to blame for the super-slow style resolution in mail when you switch the focus amongst the 3 panes. The way to solve this is to mark the selected treerows with a "focused" attribute when the tree is focused, and remove it when it's not. I've run some tests with and without these selectors in mail, and there seems to be a slightly perceptible speed increase without them. It's hard to really gauge though, since my workstation is fairly quick. attinasi/hyatt, do you think this is even worth the trouble, or is the time to mark all selected rows with a new attribute not any better than the algorithm currently used to resolve a descendant selector on a large tree?
If you can change the selector tree:focus > treechildren treeitem[selected][current] > treerow to tree:focus treerow[focused] then you will make style resolution much faster, for sure. I have no idea what it takes to set and clear the "focused' attribute on the treerow, however, so it is unclear if this is a net win or not. The problem with the selector matching algorithm is that it tries to match from the bottom up, so you pay the price of the selector matching on all treerows (until the matching fails anyway). Marking each treerow will only affect the currently selected and deselected rows, right?
I am not sure this needs to be done. My profiles of focusing the tree revealed the problem to be more with pseudo matching than with the > selectors. I think it would be more accurate to have a bug with the summary "Focusing trees in mail/news is slow", and then we can profile and discuss the various options.
The cost can also vary based off of what's being blurred. You're switching between two objects usually, and so you have to consider that you're potentially doing style re-resolution on two trees, not one.
The problem I was referring to isn't with the ">" child selector, it's with the " " descendant selector -- have you noticed any slowdown with regard to this selector?
Not really, since the descendant selector only occurs to the left of selected tree items. If you can whip this up to experiment, though, it might be worth trying. I'm just nervous about it, because in the case where you have all your messages selected, you could be setting thousands of attributes on a focus. THere is a point at which the cost of setting a bunch of attributes far outweighs the cost of crawling up only in the selected row case.
don't think this will be necessary