- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 11 Jul 2013 15:02:11 -0700
- To: Sylvain Galineau <galineau@adobe.com>
- Cc: François REMY <francois.remy.dev@outlook.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, Jul 11, 2013 at 2:34 PM, Sylvain Galineau <galineau@adobe.com> wrote: > On 7/11/13 1:55 PM, "François REMY" <francois.remy.dev@outlook.com> wrote: >>>>The one I could think of however is: >>>> >>>> !label /for/ input:focus { >>>> ... focus style for the labels of the focused input ... >>>> } >>>> >>>>This is only working on the complete profile right now for multiple >>>>reasons but authors can accept that the styling of the label may be a >>>>bit >>>>delayed after the focus change, that's not a big deal. >>> >>> If you'll pardon my French - so to speak - use-cases are the shit. In >>>this >>> case, whether authors 'can' accept a delay seems rather hugely dependent >>> on what 'a bit' is. To go to an extreme for argument sake, if the delay >>> nearly a second and makes transitions or other animations look bad I'm >>> doubtful. More fleshed out ideas or mock-ups would definitely help in >>> figuring out whether and how any specific proposal might help. >> >>See my previous mail: >>http://lists.w3.org/Archives/Public/www-style/2013Jul/0241.html >> >> @defer up-to 250ms { ... } >> >>Actually, the author is in full control on how often he [want] the >>selector to be reevaluateed. Beyond that critical time, the browser is >>still allowed to reevaluate more often if he believes he can do it safely >>without degrading the user experience (or less often if it cannot even >>render at the expected frame rate). > > 250ms from where? And how does one figure out the proper 'critical time' > for most of their users? The critical time depends on the device so…you're > going to set this based on resolution media query or something? Or using > the lowest common denominator? Like I said in an earlier response, actually providing control over the time resolution is not a good idea. You basically list why - authors can't predict ahead of time how much time the user's device actually needs. Instead, it should just be up to the browser to re-evaluate "whenever it can". Or we can go with Lea's idea of the rules never applying normally, but exposing a method on the document that causes them to apply (and I guess returns a promise that resolves when they're done applying?). ~TJ
Received on Thursday, 11 July 2013 22:03:00 UTC