Obsolete this document

[littledan]

The JavaScript WHATWG spec is pretty small and largely subsumed by TC39 work. There are just a few things left. Ideally, we would bring the remaining items into ECMAScript (e.g., library features like __defineSetter__ and RegExp legacy $1 properties) and just leave it to HTML/WebIDL to reference ECMAScript and require Annex B. Now that there's the stage process and ecmarkup, we could even have spec text which is at an earlier stage to describe certain features where consensus doesn't yet exist.

@annevk @domenic @mathiasbynens What do you think?

[mathiasbynens]

👍, being superseded by the ECMAScript standard has always been the goal.

Compared to its first release (even before https://rawgit.com/whatwg/javascript/e244c5996edeabfbb614a9a5e2d40303068d26b5/index.html), the JS spec has become ridiculously small and the remaining bits are underspecified.

[annevk]

Looking through the document these things are left:

• Requirement on Annex B and Unicode version.
• Requirement on Date.UTC.
• RegExp, including Octal escapes in regular expression literals (including in strict mode), RegExp.$1-$9, and RegExp.lastMatch / RegExp["$&"] (last one not actually defined).
• __defineGetter__, __defineSetter__, __lookupGetter__, and __lookupSetter__.

I think the Unicode version is being bumped by TC39. Requiring Annex B could be something HTML does.

Are there issues filed against https://github.com/tc39/ecma262 for the remainder?

[littledan]

The process isn't to file bugs for feature requests (those are being closed), but to write an explainer document and link it as a stage 0 proposal/get it on the agenda for a TC39 meeting. I don't think there are bugs or documents for any of these. If anyone wants to champion these things at TC39, I'd recommend starting with the getter/setter functionality. I can see some old mailing list posts about some of these issues, and there was some disagreement, but I think it can be worked through. For RegExp properties, maybe if there's some arrangement for them to be safely disable-able then they could be standardized.

@ljharb You've done some work on adding some standard library functions. Any interest in these (or Date parsing)?

@erights Could you summarize/tell me where I can find information on previous discussions/why these were not included in ES2015?

[annevk]

@littledan these are not feature requests though. These are implemented by all engines and the web most likely depends on them. Classifying those as feature requests seems misguided.

[ljharb]

@littledan I've got a pretty big list, and Date functions, RegExp static properties, and dunder methods frighten me. That said I'll be happy to help wherever I can.

[littledan]

What frightens you about them? (If you don't do this, then whoever else takes it up should take that into account.)

[domenic]

Think of it this way: here's your chance to go from stage 0 to stage 4 in a single meeting ;).

[annevk]

Dunder methods is tc39/ecma262#381 now. Paging @claudepache to see if he's interested in the remainder of the list. 😊

[erights]

The RegExp statics are mutable global state and a global communications channel.
https://github.com/google/caja/wiki/RegexpsLeakMatchGlobally
Their existence must not be normative, so that a system (like SES's repairES5) that removes them produces a state that is still considered a conformant ES implementation.

Regarding the RegExp statics, the important issue is
http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable
which we should propose and make normative. I just verified that Chrome 48.0.2564.103 ships with these statics configurable, and actually deletable, demonstrating that it is web compatible to require this.

[littledan]

@erights How would you feel about standardizing these RegExp properties with the semantics that Chrome ships?

[erights]

I am certainly against specifying these as normative. As I say above:

Their existence must not be normative, so that a system (like SES's repairES5) that removes them
produces a state that is still considered a conformant ES implementation.

However, in light of Claude's point at tc39/proposal-regexp-legacy-features#3 and my reply at tc39/proposal-regexp-legacy-features#3 (comment) , if inter-realm leakage were also banned, I would see benefit to these being normative-optional rather than continuing as unspecified. i.e., where there is no normative requirement that they be present, but there is a normative requirement that, if they are present, then

• they must actually be deletable. If deleted, they do not magically reappear.
• they must not leak info cross realm.

With these, yes, I think I would support normative-optional.

[littledan]

What if they're in the existing primordials, and deleting them takes effect? Does Chrome 48 make them sufficiently deletable, or are additional changes needed?

Beyond that, what does it mean that for something to make sure not to not leak cross-realm? Seems like with deletion, SES will have all the tools it needs.

Does Annex B suffice for normative-optional?

[erights]

What if they're in the existing primordials, and deleting them takes effect?

I don't understand the question. Rephrase?

Does Chrome 48 make them sufficiently deletable, or are additional changes needed?

From my testing, they seem to be sufficiently deletable on Chrome 48. The reason I specified "deletable" explicitly is that a property may legally be both configurable and not deletable. We need to ensure that these are actually deletable (as they are on Chrome)

Beyond that, what does it mean that for something to make sure not to not leak cross-realm?
Seems like with deletion, SES will have all the tools it needs.

I thought so until I saw claude's example. The issue is, what happens when a RegExp.prototype.exec method from one realm is applied to a RegExp instance from another realm. In this cross realm case, info must not leak to either, even if the properties are not deleted.

Does Annex B suffice for normative-optional?

I should double check the language, but yes, I believe so. That's what I had in mind.