RE: [selector-profiles] confusion

>>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.

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. 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.




> 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.



>>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 ;-)

Received on Thursday, 11 July 2013 22:17:27 UTC