- From: Sylvain Galineau <galineau@adobe.com>
- Date: Fri, 23 Aug 2013 13:53:56 -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/23/13 10:02 AM, "François REMY" <francois.remy.dev@outlook.com> wrote: >> 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 fixing implementation bugs does not qualify as polyfilling, you may >also want to patch an existing property. Well, that's exactly the thing. Given finite time and resources browser vendors will demonstrably prioritize fixing the bugs or plugging the feature gaps that are painful enough to motivate both polyfilling and the use of polyfills in production. Making it marginally easier to work around a particular bug - marginally because intercepting gets/sets will typically be a very small part of the actual work - does not turn that bug into a feature, nor may it reduce its severity much in many cases. So every time you can propose something that is generally useful *in addition to* helping with polyfilling it'll look more compelling than a feature whose sole target audience is made of polyfillers. You can argue until you're blue in the face that your priority - polyfilling - is important, and what is wrong with people who don't 'get it'; or you assume ease of polyfill authoring is not a self-evidently sufficient use-case and figure out what other problems could be solved by the capability you seek. >I don't think I can see much use for extending CSSStyleDeclaration >otherwise, but maybe there's and I just don't know about. > > > >> 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). > >Definitely, but I feel like this is another story. My issue here is that >for now there's no way to make the "element.style.xyz" stuff working, and >that issue is completely related to the CSSStyleDeclaration interface >alone. > >Meanwhile, I definitely believe for a long time that a "Style Mutation >Observer" would help polyfilling scenarios, and also some very >interesting other use cases (like live query detection). The good thing >here is that this is not totally impractical since, as Boris noted, css >properties are already partially observable for transition purposes. >Extending this observability a little bit shouldn't be that hard, but >this is another story that will yields other problems. > >That being said, a setter could be made working on the basis of this SMO >by harnessing some CSS Custom Property (ie: remap flow-from to >var-css-flow-from and listen for changes to this property). This could >possibly make a getter working, too. > >This seems like a non-necessary work-around, however... Again, the main point is not that your request is not useful for polyfilling. What I suggest is that you shouldn't assume easier polyfilling is sufficient to make a new API worthwhile vs all the other things that need to get done.
Received on Friday, 23 August 2013 20:54:45 UTC