- From: Sylvain Galineau <galineau@adobe.com>
- Date: Fri, 23 Aug 2013 08:09:44 -0700
- To: François REMY <francois.remy.dev@outlook.com>, Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
On 8/22/13 10:57 AM, "François REMY" <francois.remy.dev@outlook.com> wrote: >>>> So this property would point to the element for element.style >>>> but be null for cssrule.style et al? >>> >>> Yes. So that either parentElement or parentRule have a non-null value. >>> >>> >>> >>>> I'm having a bit of difficulty reasoning around your use case since >>>>it's >>>> about polyfilling. For instance, getting flow-from implemented in >>>> browsers >>>> would remove the need for parentElement in your case. > >The use case of a polyfill is /by definition/ suppressed by a browser >implementation. That doesn't make it worthless by any amount, especially >when we talk about a feature that benefits all css polyfills, not just >one in particular. I don't believe Simon says this was 'worthless'. There is quite a bit of room between 'not compelling enough' and 'worthless'. Making apparent disagreements wider than they are rarely helps. If I get this right you want to be able to write custom CSSStyleDeclaration getter/setters; but the setter will almost always want to know what element it applies to. While that makes sense it also sounds like pure polyfilling API; or are there other use-cases that would make use of it? If there are other scenarios where developers want to know whether a CSS property value changed for a set of elements then we'd probably want a different API and pass the relevant information to the author's event handler(s). (This suggestion is solely meant to suggest how/why it may help to think beyond polyfilling).
Received on Friday, 23 August 2013 15:10:27 UTC