RE: [selector-profiles] confusion

> ...which is? I thought existing
> selectors are very fast anyway
> so any additional optimization
> is premature optimization.

The selectors themselves may be cheap, but the fact a selector starts to apply can actually trigger heavy operations like a relayout and a repainting of part of the document. There are some operations that are not actually critical for the document that you may allow the browser not to perform every frame to improve performance-critical operations like scrolling or zooming. 

That can be especially important for infinite scrolling use cases where some selectors could for example update the rendering of already-existing sibling elements via a sibling selector (... ~ ...) and slow down the scrolling experience while the said elements are actually being put out-of-view very quickly thereafter (and that the browser may actually want to delay that expensive rendering to the time they will be in view again).



You may for example check out [1] in the 'Unfortunate combination' section that explains how :hover and scrolling sometimes can make scrolling on lower-end devices laggy.

[1] http://www.html5rocks.com/en/tutorials/speed/unnecessary-paints/
[1] So how can we stop this from happening? As it happens the fix is pretty simple to implement. The trick here is to attach a scroll
 handler that will disable hover effects and set a timer for enabling 
them again. That means we are guaranteeing that when you scroll we won't
 need to perform any expensive interaction paints. When you've stopped 
for long enough we figure it's safe to switch them back on again.




> In any case, if whatever mechanism
> we come up with applies to selectors
> in general, it should be done in a
> way that older browsers still apply
> these selectors (i.e. an @rule
> wouldn't be a good idea).

That's a good point. I've no idea how to get up to that, but it's worth exploring.

Received on Thursday, 11 July 2013 18:55:53 UTC