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 09:24:49 -0700
To: Fran├žois REMY <francois.remy.dev@outlook.com>
CC: "lea@w3.org" <lea@w3.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE042976.7920%galineau@adobe.com>


On 7/11/13 9:17 AM, "Fran├žois REMY" <francois.remy.dev@outlook.com> wrote:

>>>> Or there could just be a @static rule,
>>>> with everything inside running statically,
>>>> including fast selectors. Just an idea.
>>>
>>>What do you actually mean by 'running statically'? Being executed only
>>>once at the page load? If the page takes a while to load, which is
>>>commonly the case on mobile phones & cellular connections, your style
>>>may
>>>even never get applied using that strategy.
>>
>> If something runs once the page loads, why wouldn't it run if the load
>>is
>> slow? It'd never get applied if the load never completes but that'd be
>> true whether the UA runs on a mobile device or a desktop.
>
>Well, I just meant that some pages just never execute the load event on
>mobile phones because they actually never stop loading in a reasonable
>timeframe (ie: the user navigate away before the page finished loading).
>Of course if you let your phone download the page without interacting
>with it, the event will eventually fire at some point.

In which case anything that depends on the load event never happens; which
can cause loads of other problems (bad pun). So this issue isn't related
to Lea's suggestion per se.

>
>Anyway, I do think that selectors that are evaluated only once will be a
>pain for developers. It would be very hard to debug them, or even report
>them in debug tools. This is not to say it's impossible, but that would
>be messy... 

Assuming you can even come up with a definition of 'once' that aligns with
whatever use-cases would motivate this. I've lost track of what it is
we're trying to solve here.		 	   		  

Received on Thursday, 11 July 2013 16:25:19 UTC

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