RE: [selector-profiles] confusion

> I still think there should be some way for 
> authors to opt in to using these selectors
> in a static manner, or the possibility to
> use polyfills that do so by utilizing qSA. 
> 
> It seems so wasteful to make the effort to
> support them and not let authors take
> advantage of them in regular CSS at all,
> even statically and/or with some limitations.
>
> Any thoughts on how that could happen?

Basically, you can polyfill them using qSA and switching on-and-off a class on matching elements. I've been working recently on a querySelectorLive implementation that could be leveraged in that way. The big difference between a polyfill and an actual browser is that the polyfill only runs once in a while (my implementation is using a 250ms event coalescing, but you could decide to modify that time to fit your needs) and therefore avoid degrading the framerate by rerunning too frequently costly selectors.

This comes at the cost that it's possible for the selector to be out-of-date for up to 250ms. I think it would be possible to leverage "Static Selectors" in normal CSS if you wrap them in a special at-rule specifying they are not essential to page layout and their reevaluation can therefore be delayed to save battery life of improve frame rate.



@delayed up-to 250ms {
  
  /* these selectors will be updated when the browser will have time to do so, but at least once every 250ms; it's not guaranteed all the selectors within this at-rule get updated at the same time */
  a:contains(img):contains(span) { ... }
  
}



The nice thing is that you can probably put non-critical :hover stuff in such section so that the browser can decide not to run the selectors when the user is scrolling on the page (which can improve performance by not re-rendering again & again the elements moving accidentally beneath the mouse cursor). 		 	   		  

Received on Thursday, 11 July 2013 15:44:46 UTC