W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css-om] CSSStyleDeclaration.parentElement

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>
Message-ID: <CE3D1585.B73B%galineau@adobe.com>

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
>> to know what element it applies to. While that makes sense it also
>> 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
>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

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