Consider flipping the [Unscopable] design

[annevk]

Rather than adding [Unscopable] to each new member on Element and Document (elsewhere?) maybe we should instead annotate all existing members with [Scopable] and not add that for new members? Or enumerate all existing members somewhere to avoid cargo culting?

It's very easy to forget adding [Unscopable] and we continue to run into subtle issues because of that.

See whatwg/fullscreen#84 for the latest installment.

[tobie]

Agreed if the idea is to have everything unscopable in the future and just annotate the ones that need to stay scopable for backwards compatibility issues (in which case we can prefix it with "Legacy" while we're at it).

[domenic]

So we'd have some per-interface opt-in? And then I guess mixins would automatically get the behavior of the interface they mix in to. Seems OK I guess, although it's going to make the IDL for Element and Document (and Node? and EventTarget?) pretty hard to read.

Then I guess we can name them [LegacyUnscopable] (per interface) and [LegacyScopable] (per member) since new members will get the right default, i.e. nobody should ever add any of these again to new APIs.

[annevk]

An alternative would be to list all the scopables in a fixed list somewhere for each of the affected interfaces.

Though maybe it's not doable given the hundred-plus element interfaces in HTML alone.

[domenic]

Hmm, yeah, I'm becoming less a fan of this idea when I consider how many members would get annotated with [LegacyScopable]...

I also fear we'd have people who define new content attributes cargo-culting [LegacyScopable] onto their corresponding IDL attributes, like they currently do for [CEReactions]. That cargo-culting works well for [CEReactions], but would be the opposite of what we want for [LegacyScopable].

[annevk]

Yeah, that's why I was thinking of having a fixed set of members somewhere that folks would be less likely to touch, but still...

[bzbarsky]

So fundamentally, we want unscopability for new members on Document, Node, Element, HTMLElement and their mixins. We do not want this for existing scopable members, nor for any members on any other interfaces.

I suppose we could try to write a web platform test that asserts things about the scopable set of names on an HTML element instance and effectively hardcodes today's list... This would at least fail if people add a new scopable thing and then we can have a discussion about whether the new thing should be scopable or not.

[domenic]

nor for any members on any other interfaces.

Why not on EventTarget or HTMLParagraphElement (or other elements)? Aren't their members also included in the event handler with(){}-like behavior?

Tests sound like a promising approach, although in practice I think everyone just automatically rebaselines every time they import new tests (right?), so I'm not sure new failures are always noticed promptly.

[bzbarsky]

Hmm. EventTarget, yes. HTMLParagraphElement, maybe not a big deal, because that would only affect event handlers on <p>. But yes, maybe we want all element subclasses to be safe...