- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 15 Feb 2014 17:23:02 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Ryosuke Niwa <rniwa@apple.com>, Daniel Freedman <dfreedm@google.com>, Alex Russell <slightlyoff@google.com>, Elliott Sprehn <esprehn@chromium.org>, public-webapps <public-webapps@w3.org>
On Feb 14, 2014, at 7:16 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
>> We most vigorously object to making the CSS style resolver depend on JS
>> DOM object properties.
>
> Ryosuke, I think you misunderstood the proposal. I'm pretty sure we all object to having the CSS style resolver depend on anything that involves JS properties. But it's not necessarily a problem to have it depends on internal node state that can be set via DOM APIs (e.g. it already depends on DOM attribute values and whatnot).
>
> So in implementation terms, an element would just have an internal boolean and setting "this.shadowRoot = undefined" or whatnot would set that boolean; the CSS machinery would read that boolean. That seems fairly workable to me; whether it's the sort of API we want is a separate issue that I have no opinion on.
The API we currently have doesn't actually allow this:
readonly attribute ShadowRoot? shadowRoot;
Now, we could change this attribute to not be readonly. However, that makes me wonder - what happens if you assign something other than null? Would this become an API to replace the shadow root? That seems like a bad idea. On the whole, this choice seems like messier API change than a parameter to createShadowRoot indicating the mode (which I thought the WG had rough consensus on over a year ago).
Regards,
Maciej
Received on Sunday, 16 February 2014 01:24:11 UTC