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

On Thu, Jul 11, 2013 at 4:48 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 07/11/2013 04:28 PM, Tab Atkins Jr. wrote:
>> Basic issue: we've got cool new selectors in Selectors 4 (and more
>> that we'd like to add in future levels) that we aren't allowed to use
>> in normal CSS because they're too slow.  Being able to use them in JS
>> is great, but it's really annoying that we can't do so in normal CSS.
>>
>> The question then is how we can mitigate the problem that is currently
>> preventing us from using them in normal CSS.  The issue is that the
>> new selectors are too slow to reasonably run as often as we run other
>> selectors, so an obvious solution is to allow their use in some way
>> that indicates they're not run as quickly as other selectors.
>>
>> ... Add a new at-rule, perhaps named @defer ...
>>
>>
>> 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?
>
> 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.

That may very well never happen.  If it does, it is likely not for an
extended period of time.  In the meantime, it will take a lot longer
for these selectors to become "critical enough" because people aren't
even *allowed* to use them in their stylesheets.  Polyfilling isn't a
reasonable solution here, because you have to either take the
full-sheet-reparse penalty or store the style data somewhere other
than your stylesheet.  (If we had custom at-rules, it would be more
reasonable to wait for polyfills to drive demand.)

I don't think it's reasonable to call this a performance "hack" when
it's directly addressing the exact problem with them - they're just
too slow to be run at the same time as other selectors.

~TJ

Received on Friday, 12 July 2013 00:13:36 UTC