Re: [selector-profiles] confusion



On 7/11/13 3:02 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Thu, Jul 11, 2013 at 2:34 PM, Sylvain Galineau <galineau@adobe.com>
>wrote:
>> On 7/11/13 1:55 PM, "François REMY" <francois.remy.dev@outlook.com>
>>wrote:
>>>>>The one I could think of however is:
>>>>>
>>>>> !label /for/ input:focus {
>>>>> ... focus style for the labels of the focused input ...
>>>>> }
>>>>>
>>>>>This is only working on the complete profile right now for multiple
>>>>>reasons but authors can accept that the styling of the label may be a
>>>>>bit
>>>>>delayed after the focus change, that's not a big deal.
>>>>
>>>> If you'll pardon my French - so to speak - use-cases are the shit. In
>>>>this
>>>> case, whether authors 'can' accept a delay seems rather hugely
>>>>dependent
>>>> on what 'a bit' is. To go to an extreme for argument sake, if the
>>>>delay
>>>> nearly a second and makes transitions or other animations look bad I'm
>>>> doubtful. More fleshed out ideas or mock-ups would definitely help in
>>>> figuring out whether and how any specific proposal might help.
>>>
>>>See my previous mail:
>>>http://lists.w3.org/Archives/Public/www-style/2013Jul/0241.html

>>>
>>>   @defer up-to 250ms { ... }
>>>
>>>Actually, the author is in full control on how often he [want] the
>>>selector to be reevaluateed. Beyond that critical time, the browser is
>>>still allowed to reevaluate more often if he believes he can do it
>>>safely
>>>without degrading the user experience (or less often if it cannot even
>>>render at the expected frame rate).
>>
>> 250ms from where? And how does one figure out the proper 'critical time'
>> for most of their users? The critical time depends on the device
>>so…you're
>> going to set this based on resolution media query or something? Or using
>> the lowest common denominator?
>
>Like I said in an earlier response, actually providing control over
>the time resolution is not a good idea.  You basically list why -
>authors can't predict ahead of time how much time the user's device
>actually needs.  Instead, it should just be up to the browser to
>re-evaluate "whenever it can".

Yes. Discovering the right interval(s) is hopeless.

>
>Or we can go with Lea's idea of the rules never applying normally, but
>exposing a method on the document that causes them to apply (and I
>guess returns a promise that resolves when they're done applying?).

Or we could go with agreeing on concrete detailed use-cases and then argue
the pros and cons of possible solutions. Or did I miss those?

Received on Thursday, 11 July 2013 22:16:15 UTC