Consider renaming all legacy extended attributes

[domenic]

I'm not sure this is worth the churn, but if we wanted to, let's do it all at once.

• LenientSetter -> LegacyLenientSetter
  • Used by fullscreen
• LenientThis -> LegacyLenientThis
  • Used by HTML
• NamedConstructor -> LegacyFactoryFunction Rename "named constructors" #277
  • Used by HTML
• OverrideBuiltins -> LegacyOverrideBuiltins??
  • Used by HTML
• Replaceable -> LegacyReplaceable?
• TreatNonObjectAsNull -> LegacyTreatNonObjectAsNull
  • Used by HTML
• TreatNullAs=EmptyString -> LegacyNullToEmptyString (different naming scheme than LegacyTreatNonObjectAsNull since it operates on types, not callback functions)
  • Used by CSSOM, DOM Parsing, HTML, DOM
• Unforgeable -> LegacyUnforgeable???
  • Used by HTML, DOM

I have attached varying degrees of ?s for the ones I am unsure on.

[annevk]

In general I'm very much in favor of this and I think they all make sense. I'm a little worried where we have something we recommend, EventHandler, depend on something that we don't, [TreatNonObjectAsNull], as I wouldn't want folks to start ignoring EventHandler. I think that'll probably be okay in practice though.

[bzbarsky]

Replaceable is not legacy. It's basically required for any new attribute we add on globals. And even then it may not be enough; see https://bugzilla.mozilla.org/show_bug.cgi?id=1359022 for example.

[annevk]

If [Replaceable] is limited to globals it seems reasonable to keep it with the existing name.

[bzbarsky]

Hmm. In Gecko, the only non-global use of Replaceable is .stack on DOMException. Which is exciting for all sorts of reasons, not least because there is no mention of .stack in https://heycam.github.io/webidl/#es-exceptions

Of course there's no mention of it in ES either, for ES exceptions, but in practice browsers implement it (with non-identical semantics) and websites rely on it....

[annevk]

It sounds like we could limit it to globals in standards then and deal with stack once someone figures out what to do there (which likely will need to be defined in JavaScript-prose anyway given how we define DOMException today).

[TimothyGu]

Is this describing the same issue as #100? If so we should close one of them out.

[tobie]

Is this describing the same issue as #100? If so we should close one of them out.

This issue seems specific to extended attributes.

[annevk]

Updated the title of #100.

[annevk]

I don't think we have any legitimate use cases for [Unforgeable] left. See also discussion over at w3c/webappsec-secure-contexts#46 and whatwg/html#2294.

[annevk]

I think we should rename OverrideBuiltins to LegacyOverrideBuiltIns (note the uppercase I). That makes us more consistent with JavaScript and HTML, which mostly say "built-in", not "builtin".