- From: Rune Lillesveen <rune@opera.com>
- Date: Fri, 8 Apr 2016 14:14:58 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Francois Remy <francois.remy.dev@outlook.com>, Simon Pieters <simonp@opera.com>, "Davis, Greg" <greg.davis@pearson.com>, www-style list <www-style@w3.org>, Marat Tanalin <mtanalin@yandex.ru>
On Fri, Apr 8, 2016 at 4:41 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Thu, Apr 7, 2016 at 12:35 PM, Francois Remy > <francois.remy.dev@outlook.com> wrote: >>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] >>> On Thu, Apr 7, 2016 at 4:06 AM, Simon Pieters <simonp@opera.com> wrote: >>> > It seems to me this could be equally useful for attributes, in >>> > particular >>> > data-* attributes. >>> >>> Yeah, it's a pretty long-standing request for data-* attributes. >>> >>> > While we're bikeshedding, a more succinct syntax would be IDENT >>> > DELIM(*) (no allowed whitespace between) so you can do: >>> > >>> > x-admin-* { ... } >>> > [data-my-*] { ... } >>> >>> Definitely my preference. Very readable, and it bridges the universal selector >>> nicely - * is just a tagname selector with a wildcard and no prefix. >>> >>> > Performance-wise it seems to me this shouldn't be worse than partial >>> > attribute value selectors, but I could be missing something? >>> >>> I *think* you're right, but we should tag in some implementors. I've bugged >>> Elliot privately. >> >> I think this would break an optimization some browsers do where they create a bloom filter of attributes being used for css selectors, in order to avoid invalidating the style for most attribute changes. This would make it harder by adding another component on top of the bloom filter. Not sure this is worth the pain. If you control the element, just add a "data-my=true" attribute and test for it. > > Yup, this is what Elliot told me today. We use some data structures > to know what sort of tagnames and attribute names are relevant to > subtrees, so we can tell quickly whether or not a given DOM mutation > needs to recompute the style for the subtree. Any "fuzzy" matching > like this defeats those optimizations, so their presence will slow > down the performance of the CSS engine on the entire page. A straight-forward implementation of this in Blink without introducing any new optimization strategies would slow down style invalidation and recalc the same way a universal selector would. We would put these rules into the universal rule bucket. 1. We would consider matching "x-* {}" for all elements like we would consider "* {}". 2. We would consider matching "x-*.x {}" for all elements with class="x" like we would for ".x {}". 3. We would recalc style for all descendants of an element which gets its class set to "x" if we have a rule ".x x-* {}" like we would if we had ".x * {}". and so on ... However, matching a bunch of universal selectors is cheaper than comparing a lot of x-*, y-* patterns against the tag name of every element for which you calculate style. -- Rune Lillesveen
Received on Friday, 8 April 2016 12:15:27 UTC