[css-shadow-parts] IDL for attributes

[fergald]

As discussed at Web Components F2F (2018-03, Tokyo) and in TAG issue update spec to include IDL for part, partmap, theme to allow programmatic API.

[domenic]

Since these are supposed to be "superglobal", the best precedent is things like https://dom.spec.whatwg.org/#dom-element-id

[fergald]

Posting discussion about programmatic from #2411 to here.

@fergald

In my model the partmap is a dictionary where the values are Set()s of part names. So deleting would be partmap['a'].delete('b') and to remove "a" entirely, delete partmap['a'] (although partmap['a'].clear() would have the same effect).

What's the tradeoff between a dictionary of sets and something with an explicit API. Are there operations that dictionaries/sets allow that we wouldn't want or conversely are there operations dictionaries/sets don't allow that we would want and couldn't add later without breaking compatibility? I don't really want to write up an API for something that behaves essentially as a dictionary of sets if I can avoid it.

@rniwa

Well, browser engines can't observe changes to a dictionary so your proposal as currently stands will make partmap readonly, and any changes to it will be discarded. It's even weirder because it has [SameObject] on it. It means the browser engine has to update the dictionary continuously? I don't think it works because then author scripts can override property descriptors of a dictionary, and all sorts of insanity ensues.

[domenic]

I would strongly suggest just exposing these as strings in IDL for now. There is no need for a more complicated data structure, at least until authors ask for one.

We have precedent for microsyntaxes being reflected as simple strings in at least <img srcset>, <iframe csp>, <iframe allow>, and <link sizes>.

We can always add something more complex later, depending on how we find developers are using these things, e.g. feature policy is looking at a read-only API that gives a view onto the allow attribute. But for now, no need.

[domenic]

Concretely, and with regard to the feedback in #2411 (comment), I think this means:

• Say "content attribute" in most (all?) places you current say "attribute". You can omit it if it's quite obvious, e.g. I think "the [part] attribute" is fine as long as [part] links to the <dfn> which will say "The part content attribute".
• Add the IDL, roughly partial interface Element { [CEReactions] DOMString part; } (and partmap).
• Define the IDL attribute like the ID attribute is defined in DOM, including the correct "reflect" link. Unlike DOM, you can use a proper link for the last part of the sentence, instead of just monospace font.

[rniwa]

If we're exposing it simply as a string, we're probably better off not having IDL attribute at all. Just use good old setAttribute / getAttribute for now.

[domenic]

Well, that'd be inconsistent with the rest of the platform, and cause problems for developers or frameworks used to having omnipresent attribute/property reflection. So I think following the example of srcset, csp, allow, sizes, etc. (which all have simple string reflection) is probably the right path.

[rniwa]

Then I'd argue that we should be adding IDL attribute which reflects the fact partmap is a map. I'm sorry but there is no consensus here.

[domenic]

Why do you not argue the same for the other attributes I list?

Note that we have no precedent in the platform for exposing a map-microsyntax as map-like IDL attribute.

[rniwa]

I'd argue that those attributes should have had a better IDL attribute but that's somewhat of an orthogonal discussion to have. Anyhow, I think here's an idea on how these map-like IDL might work. Introduce a new interface like DOMTokenMap then have stringifier return the actual string. The IDL attribute would have PutsForwards to forward the assignment to value property of DOMTokenMap. Then DOMTokenMap can have named properties to set and get mapped values.

[domenic]

I think we should wait for web developers to ask for a new structured attribute manipulation technology, and gather their use cases in a way that services all such attributes, instead of designing one ourselves independently. Right now we know web developers have the use case of working with property-based frameworks like React, for which string reflection is preferable (e.g. they use className, not classList, and if we only reflected classList, React would be unable to use classes). We should wait for a similar ask for structured reflection before adding it, which we can easily do additionally.

Also note that named properties are deprecated in IDL.