- From: fergald via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Mar 2018 02:51:02 +0000
- To: public-css-archive@w3.org
I think there is some miscommunication here > 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. There is a model described in the spec which maps part names to elements. This mapping of names to elements is conceptual only, it's not what devs will interact with and it's not how blink will implement this either. No one is proposing to expose this model to devs. This would require dynamic updates and a whole load of other problems but it is not relevant, except as a way of specifying the behaviour of the feature. The model that devs need to consider is one that maps, let's call them, "outer" part names to "inner" part names and it is simply a map from string to set-of-strings. It does not change dynamically. If we need to create an new class because browsers can't observe changes to a dictionary, that's fine. > My preference here is to subclass DOMTokenList and overload add and remove with a variant which takes multiple arguments and/or a dictionary. That would make the whole thing work & consistent with the rest of the DOM. I don't think it's useful to base a _map_ on DOMTokenList. It's not a list of tokens, it's a comma separated list of pairs of tokens. I think we would have to override _every_ method of DOMTokenList. Having the _values_ of the map be DOMTokenList seems reasonable. Since we hope to support things like "partname-*", I'm not sure if that really fits with DOMTokenList but it looks like space is the only character not allow, so actually this seems fine. Here's what I propose - I have a few pull requests out for the spec. I will assemble them and add some more stuff (a clear dev-facing model for the part map) and publish that somewhere and get agreement on the shape of that. I'm happy to VC about this too to clarify any points but maybe that's best left until I publish an updated version. -- GitHub Notification of comment by fergald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2411#issuecomment-376743319 using your GitHub account
Received on Wednesday, 28 March 2018 02:51:05 UTC