Ian Hickson: > > > For DOMStringMap, my intention was to not provide methods at all, and > > > only provide the JS-native mechanisms.
Maciej Stachowiak: > > A bold choice, but I would not recommend it as the sole available > > mechanism. Ian Hickson: > See above for UndoManager, but for DOMStringMap I don't want to add any > other mechanisms, because they introduce name clashes. Right now the IDL > for DOMStringMap is: > > [NameCreator, NameDeleter, NameGetter, NameSetter] > interface DOMStringMap {}; > > It basically emulates a JS Object. It's intended only for JS. I don't see > why this is a bad idea. At the moment, the interface is useful only for JS (and other languages that support this kind of indexing). For other languages, a DOMStringMap object would appear to be a completely opaque object without any means of interacting with it. Given that this is basically meant to be a shorthand for getting/setting attributes with particular names, I would be happy with it not existing in other language bindings. Web IDL doesn’t have a mechanism to state that an interface member or a definition should only be included if the target language binding is a particular one, though. An alternative would be to put operations on the interface to act as the getters/setters/etc., and use the [NoIndexingOperations] extended attribute to indicate that these operations won’t correspond to properties in language bindings such as ECMAScript. That would then at least make the interface useful for other languages. -- Cameron McCormack ≝ http://mcc.id.au/