Re: [selectors] Finding a way to run "complete" profile selectors in CSS

First off, let me express how glad I am that we’re discussing this! ANY solution, regardless of how lazily evaluated or whether it needs a couple lines of JS, ANY compromise we have to make, is better than nothing and covers at least *some* of the use cases. Yes, looser restrictions might be more difficult for authors to learn, but it’s a tradeoff. After all, the current restriction is already somewhat difficult for authors to grasp, from what I’ve noticed.

On Jul 12, 2013, at 02:28, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> What are the use-cases for "slow selectors", how well are they
> addressed by either of these two solutions, and is there anything
> better we could do?


Regarding the use cases, François mentioned a few, glad he remembered our discussion after all :-) The one that I’ve personally needed the most was the accessible drop down menu, a variation of that pattern is in so many UI controls!

Another example is hover effects that affect siblings before and after them, like the OSX dock effect.

Also, styling other elements (not labels) based on :checked, when the checkbox is included inside the label. Currently there are numerous UI patterns forced to use ids everywhere because otherwise they cannot leverage :checked to style other elements, such as [1]. Some of these are certainly hacks that should be done with JS instead, but there are some decent use cases among them.

However, I feel we’re just reciting use cases for these selectors here, weren’t these discussed extensively before these selectors were added in the first place? Can’t we find those?
Even for features with numerous use-cases, I’ve often found it incredibly hard and time consuming to remember the use cases I’ve encountered over the years. If somebody has already performed the effort, we should use it.

[1]: http://labs.thecssninja.com/bootleg/

On Jul 12, 2013, at 02:48, fantasai <fantasai.lists@inkedblade.net> wrote:
> This is silly. I'd rather just wait until these become critical enough
> that someone wants to implement them with appropriate optimizations. [1]
> Speccing, implementing, teaching, and asking authors everywhere to use
> some kind of crazy-awkward performance hack is not imho good for the Web,
> or a good use of anyone's time.

This may not even be possible, ever. I don’t like it either, but it solves some real problems. After all, JavaScript has a couple of methods entirely for performance reasons, like requestAnimationFrame and setImmediate or even the entire Web Workers API. As CSS matures and grows, it’s not crazy to expect performance to become a consideration.

There’s always the solution of allowing these selectors in regular stylesheets, with a note in the spec that UAs are allowed to implement them lazily (for a certain definition of lazily) or defer them (for a certain definition of defer) or whatever special treatment we decide is a good idea. Then, if UAs find a way to make them fast in the future, the syntax won't change. It’s still an extra thing to teach, but so is everything we’ve discussed, including the current idea of disallowing them completely.

On Jul 12, 2013, at 03:40, François REMY <francois.remy.dev@outlook.com> wrote:
> You make that such assumption optimizations are possible to implement, and that their complexity will be worth the use-cases. Some hard stuff will remain hard forever. For sure you can just wait for devices to become increasingly fast but that feels weird to me.

From some recent discussions with Chrome engineers, I learned that these selectors are O(N^2). So, regardless of how fast computers get, they will never be fast enough. Whether they can be made faster than O(N^2) is another question, that I think would merit some actual research. If I’m not mistaken, there is no proof for the opposite.

Cheers,
Lea

Received on Friday, 12 July 2013 09:10:55 UTC