RE: [selector-profiles] confusion

> I honestly don't get why you think 250ms is acceptable, even as a maximum.
> Lag perception is very reliably reported by most users between 100-200ms.
> As you approach 300ms, reaction time is considered sluggish. 

You're probably right. Now I think about it, 250 is the timespan between two setInterval calls, which mean the mean wait time is 125ms, not 250ms. That seems more in line with your numbers already.

Anyway, no selector will ever take so much time that you can't run it in a reasonable amount of time, if we can use it in qSA that means it is expected to complete sufficiently fast to be synchronously usable on the document.

The most annoying issue for browsers is that recomputing their action can actually cause frame drops, because there could be a lot of selectors in the user stylesheets; with this proposal we can transform frame drops by asynchronous matching. I do believe that the maximum number of frames an async selector could be late will never excess 2 or 3, which is much less than 250ms.


> let's look at it from another
> angle: do you have examples of existing sites or apps that routinely trade
> style update delays of ~250ms [for something else]?

You mean, like all the ASP.NET WebForms websites that use postback to update the content of the page? 

Or powerpoint online that need to send info back to an online server to render a word art because it's easier than to make a client-side renderer in javascript?

Or the Twitter button indicating loading that replace the Twitter logo that has delayed loading to avoid being shown when results download very quickly? 

I honestly think there are examples. This is not to say this is good, but this can sometimes be needed to trade convenience for degraded experience on lower-end devices.

Received on Friday, 12 July 2013 05:32:38 UTC