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


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

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