Re: [w3c/webcomponents] How to define APIs only for custom element authors (#758)

I'm writing up the properties @caridy mentioned. 

The design problem we're trying to solve there is:
- We need a way to set non-reflected versions of the [ARIA IDL attributes](https://www.w3.org/TR/wai-aria-1.2/#idl-interface) which will change dynamically (e.g. [`ariaChecked`](https://www.w3.org/TR/wai-aria-1.2/#idl-def-ariaattributes-ariachecked), which represents the current "checked" state)
- These versions should be *shadowed* by the reflected version (i.e. if I set `ariaChecked` on the host element, as well as the shadow root, the version on the host element should override whatever was set on the shadow root)

`ShadowRoot` really seems like a good fit for this problem in some ways, since it's analogous to using `:host` in a `<style>` element within the shadow root - but unlike style, the properties on the host element can only be set directly on the host element (i.e. can not be defined anywhere but directly on the affected element), so there's no logical place to put the `:host` equivalent.

It also means that you can encapsulate semantic information about the host element without needing to register a custom element.

However, I can imagine asking the question "why can't I set shadowed versions of any element property on the shadow root?" - which definitely sets us on a road to a kitchen sink scenario.

Also, if your custom element doesn't otherwise need a shadow root, it seems like a shame to need to attach one for this purpose.

We could theoretically create a new type of object to hold semantic properties, analogous to a constructable stylesheet, but unlike constructable stylesheets there's no precedent for the type of object this would need to be - it's really just a simple, small map of properties.

Does anyone have any ideas for alternatives to using `ShadowRoot` here?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/758#issuecomment-409771269

Received on Thursday, 2 August 2018 00:58:30 UTC