Re: [selector-profiles] confusion


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

>> On 7/11/13 10:25 PM, François REMY wrote:
>>>> How do you determine that it has to be reevaluated?
>>>
>>> That's up to the browser to optimise that.
>>
>> Well, but ... that's the part that's typically "slow"!
>
>This is because it seems the goal has always been to narrow down to the
>smallest number of elements that may have been affected. For those
>complex selectors like "!abc ... def" that task is very hard indeed if
>def is a frequent tag.
>
>However, you can take a very different approach for them if you're not
>forced to be exact about them every time. For instance, let's say the
>author want the selector matching be accurate within 250ms, that leaves
>you 15 frames to accomplish the task. instead of optimising upfront you
>just queue all the possibly influenced elements in a list and you process
>them in a background thread asynchronously.

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. The animated
UI feedback you see in modern apps - web and native -  and OSs is very
often shorter than 250ms. Delaying <=250ms feedback by up to 250ms sounds
rather suboptimal; if that delay also varies over time users will perceive
the app as being of low quality and authors will give up rather than
making their app look bad. At a minimum, you are expecting authors to be
happy with a level of style update delay they do not experience today and
very rarely experienced before, if ever, in exchange for some selector
syntactic sugar. So to test your assumption, 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 in exchange for a better authoring syntax?

Received on Friday, 12 July 2013 04:43:56 UTC