Cameron McCormack
Cameron McCormack
I wonder if `[SameObject]` should just become `[Constant]`, as Gecko's bindings supports. Then we could use it for any type (including the **any** type!).
In section 5.4, I think: > The data attribute must return a structured clone of notification's data. should be just: > The data attribute must return the notification's data. since...
Oh I see, the "notification" is the abstract thing that one or more `Notification` object get created to represent. Still I don't think there is any need to add any...
OK. It's not exactly clear whether "must return a structured clone of notification's data" should mean a new structured clone every time you fetch the IDL attribute or just any...
Technically it's a spec bug if the spec author uses `[SameObject]` and then requires in prose that a different object is returned at some point. So it is an "enforcement"...
There is some discussion about an IDL-level feature better than `FrozenArray`, aimed at solving use cases like `adoptedStyleSheets`, here: https://github.com/heycam/webidl/issues/796
If we end up moving to using that ObservableArray proposal, and we use a spec hook to disallow duplicates, then that could have surprising effects such as preventing `.reverse()` from...
Would this affect SVG images used as CSS `` values too?
Mis-typed the issue number. :)