Re: [selector-profiles] confusion



On 7/11/13 3:17 PM, "François REMY" <francois.remy.dev@outlook.com> wrote:

>>>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?
>
>When the selector has to be reevaluated on an element, a timer starts and
>the operation can get delayed up to 250ms {or any author chosen amount}
>from that point. If during a style resolution the timer has elapsed, the
>browser cannot decide to skip the selector reevaluation anymore and has
>to proceed. If the browser believes it can perform the reevaluation in
>time, he can go ahead immediately and clear the timer.

I've officially lost track of what we're trying to solve here.

>
>That probably requires to measure how much time the execution of those
>selectors take, or use heuristics. Some UA might also reexecute all
>selectors that need to be refreshed unless the last frame was dropped for
>example, that's not restricted.
>
>
>
>> 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?
>
>I don't think the cut-off amount has anything do to with the device: this
>is the maximal delay you don't want to exceed, so it only depends on the
>user experience you want to provide your users with.

Not sure how the maximum delay could be independent of the device when
some devices may not be able to comply with the maximum delay you'd
actually want (assuming you can really determine what that is).

> The meaning of 'up-to' is that the browser can do better that maximum
>delay if that's possible. It would probably be interesting to be able to
>specify a desired reevaluation time as well to help the browser choose
>the right re-evalution schedule.
>
>  @defer 100ms up-to 250ms {
>    // optimally, browsers should try to update at 10fps at least
>    // but browsers can degrade performance up to 4fps if needed
>  }
>
>Or do you intend that the experience you want to provide your users with
>can actually change in function of the device? In that case, you may need
>MQs indeed.
>
>
>
>
>> Opt-in does not tell me how they'll figure out when/how to use this.
>
>When the rendering frame rate of their web app is below the users
>expectations, and the culprit is a repaint/reflow triggered by a
>non-critical css rule being executed, this solution can be used.

So we assume the developer knows the rendering frame rate their users
expect and are then able to figure out the users are not getting it
because of a repaint triggered by a 'non-critical css rule'? You are
assuming quite a bit here. Never mind a granularity of detail that is
highly UA-specific.

>
>
>
>
>> 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!
>
>I was referring to the "Label highlighting on input focus" use-case which
>affects elements not currently under the user attention, and can accept
>longer delays. Hover effects are different in the sense they respond to
>direct user input, you would indeed want tighter reaction time for those
>ones.

You make claims about delay tolerance that are beyond established metrics
in the field. 
 
>
>
>
>>>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.
>
>I never implied webdev was easy, just that we get used to that complexity
>;-)            

I doubt anyone will get used to setting metrics they can't realistically
discover. 

Anyway. This thread is well past its stale date. We should start with
clear use-cases and then propose solutions. Making up complex features
based on little more than a simple CSS rule with no context is unlikely to
yield much that is useful.

Received on Thursday, 11 July 2013 23:00:27 UTC