Re: [selector-profiles] confusion



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

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

You're talking about a delay that applies before selector matching so it'd
be cumulative. Then if the matching rule(s) trigger transitions their
transition-time follows after that. The total elapsed time for the end
user could still be very poor.

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

When it comes to performance, I quite honestly yet have to see beliefs
survive encounter with running code and real-world content.

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

Only one of these trades perf for syntactic productivity (the first); one
(the third) imposes a deliberate delay which strongly suggests a design
requirement (some UI interactions are meant to take a minimum amount of
time e.g. splash screens); none of them match my request though. I'm
specifically requesting examples of simple local style rule updates; are
there popular jQuery plugins that take up to 250ms to change some
foreground and background colors in a widget?

Of course people will trade some perf for convenience. jQuery and other
frameworks prove this. But it's easy to overestimate how far that
trade-off can go. 

Anyway. This discussion remains highly speculative. It's still not so
clear what it is we're trying to optimize. 'Slow selectors' is just too
broad a target. I'd rather figure out where to go based on some real-world
experience of slow selectors. If these are so useful we'll soon have
actual qSA data to build a real plan on, instead of wobbly piles of nested
interlocking assumptions.

Received on Friday, 12 July 2013 06:36:14 UTC