- From: François REMY <francois.remy.dev@outlook.com>
- Date: Thu, 11 Jul 2013 19:46:30 +0200
- To: Sylvain Galineau <galineau@adobe.com>
- CC: "lea@w3.org" <lea@w3.org>, "www-style@w3.org" <www-style@w3.org>
>>Anyway, I do think that selectors that are evaluated only once will be a
>>pain for developers. It would be very hard to debug them, or even report
>>them in debug tools. This is not to say it's impossible, but that would
>>be messy...
>
> Assuming you can even come up with a definition of 'once' that aligns with
> whatever use-cases would motivate this. I've lost track of what it is
> we're trying to solve here.
I think there are two issues here:
- The first one is that the "fast" and "complete" profiles do not have clear names that explain what they're all about. By "fast" we actually mean "usable in live stylesheets" and by complete we mean usable in qSA. We should probably update the profiles names (aka do some bikeshedding).
- The second one is that the reason we introduce selectors in the "complete" category is that people have actual use cases for them and will probably use qSA to leverage them anyway. Brian & Lea are arguing we should provide a mechanism to allow them to be used in stylesheets by relaxing the live-updatability constraint browsers impose on themselves. My take was to define an acceptable out-of-date timeout, Lea's one was to run the selctors only once the page loaded.
My proposal copes with all traditional stylesheets needs that can accomodate slight FOUC {for example highlighting an element based on its content as the user is typing for example...} while Lea's one is intended to deal with static documents where you can live up with a selector that actually never update after the page load.
I personally find this too restrictive, but that's my take.
Received on Thursday, 11 July 2013 17:46:57 UTC