- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 12 Jul 2013 09:38:16 -0700
- To: Timmy <timmywillisn@gmail.com>
- Cc: www-style list <www-style@w3.org>
Whoops, didn't catch that there was more text later in the message. (Please use text-based formatting, not things like colors and indentation, to indicate quotes. Some of us always use text-based email, and the list archives definitely do, so emails like yours are harder to understand later.) On Fri, Jul 12, 2013 at 7:16 AM, Timmy <timmywillisn@gmail.com> wrote: > This doesn't seem like the best API to me. If the problem is that we'd like > to be able to use selectors in the complete profile in CSS (rather than > through QSA), you're still required to call a javascript function (i.e. the > proposed .CSS) to use them? I say let's have a solution that is purely CSS. > > Perhaps this was already suggested, but what about taking a queue from > javascript strict mode and adding some sort of CSS statement to effectively > "turn on" selectors in the complete profile? It would be a way for the > developer to say that she is aware they are slower, but wants to use them > anyway. Perhaps this flag could be scoped so that it could be applied only > to a style element or only to a particular stylesheet. > > This seems simpler to me than the deferred at rule (as styles from the > complete profile can be anywhere in a user's CSS rather than separated into > at rules). If any of the selectors from the complete profile get fast enough > to warrant addition to the fast profile, no changes to code are necessary > (they just get faster). This would just be a "please make my entire page run slower" switch, which isn't acceptable. What's worse, it would probably work fine on the developer's high-end desktop or beefy laptop that they're coding on, but then be super-slow on a user's mobile phone. ~TJ
Received on Friday, 12 July 2013 16:39:02 UTC