Re: [selector-profiles] confusion



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?

>
>
>
>> More seriously, your argument implies the author can
>> easily figure out which rules are not worth keeping up to date. Given
>>the
>> wide range of devices and contexts the content may be run in, this
>>sounds
>> very dicey. 
>
>This is basically an opt-in.

Opt-in does not tell me how they'll figure out when/how to use this.

>Except if they want to use "static" selectors which will not work outside
>the async bubble (@delayed/@defer up-to, or whatever) they are completely
>free to ignore this optimization, like all kinds of optimizations.
>
>As a rule of thumb, things that do not affect layout (colors, shadows,
>subtle anims) can accept being delayed for slightly less than half a
>second without the user giving a shit.

> 
Uh? Says who? No button color transition on hover I've ever seen in the
real world would survive close to a half-second delay without looking
broken. You're talking about a delay as long/longer than most UI
transition effects!

>If you go below 250ms, users often don't even see the delay, especially
>if you transition things.

Again, totally untrue. 1/4 of a second is definitely visible. Even half
that is noticeable. Many simple color-on-hover effects are actually 250ms
or less. Delaying them by half that amount is visible. I suggest you try
it. 

>
>
>
>> People have a hard enough time building responsive designs;
>> expecting them to also, somehow, factor in which selectors will perform
>> well where ahead of time sounds like a stretch.
>
>Sure, life is sooooooooo hard for web developers. Poor us :-D  

From having debugged hundreds of site compat issues over nearly 6 years I
can confidently assert that it is. You belong to a tiny, tiny minority.
Don't extrapolate.

Received on Thursday, 11 July 2013 21:34:50 UTC