W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: [selector-profiles] confusion

From: Sylvain Galineau <galineau@adobe.com>
Date: Thu, 11 Jul 2013 23:35:47 -0700
To: Fran├žois REMY <francois.remy.dev@outlook.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE04EB90.7B9F%galineau@adobe.com>

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
>> Lag perception is very reliably reported by most users between
>> 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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC