Repository navigation
document.all willful violation #668
Description
Other than some event loop mismatch which I think we'll be able to resolve more easily, HTML (and JavaScript engines) also contain(s) the document.all willful violation.
https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all
How much appetite is there to try to formalize this exception?
Activity
erights commentedon Aug 15, 2016
@annevk Of all the outstanding web reality issues, this is one of the least appetizing. But like the others, if everyone's gonna do it and we can't kill it, we're better off trying to pin down the best precise semantics we can get away with.
I remember there was a subtle but important difference between how Firefox did this vs how either or both Safari and Chrome did this. I think I remember that the Firefox way seemed like a better first step towards a cleaner semantics which is still compat with web reality. But I no longer remember the details.
Anyone? @BrendanEich , I think you were the one who explained this to me, ages ago. Does this ring a bell?
erights commentedon Aug 15, 2016
I think I also remember that the FF way, if we had been able to agree on it in time, would have allowed us to banish the weirdness in strict mode. However, we were not, and so this was a missed opportunity for a significant cleanup.
Does any of this ring a bell? I think this was only discussed in side conversations, and so was probably never captured in the notes of the main mtg.
domenic commentedon Aug 15, 2016
I'm not aware of any semantic differences between browsers on this feature, but I could be wrong...
My main conflict is: how would we spec this? Presumably we wouldn't have ES talk about a specific object called
document.all. We'd instead define some kind of generic behavior (what V8 calls an "undetectable object") and then HTML could say "document.allis an undetectable object". But you'd never ever ever want people to use "undetectable object" in other cases.I think with diligence we'd be able to prevent people from doing so (e.g. people might want to use it to deprecate features in the future, and we can tell them not to do that). But it still strikes me as weird to create this more generic interface that we insist must only be used once by one client. The current structure of one obviously-ugly willful violation seems more explicit about being a one-off, to me.
bterlson commentedon Aug 16, 2016
I'm not convinced we want the spec machinery for document.all's exotic behavior in ECMA262 - it'd be a fair amound of machinery and wouldn't actually be used in any normative spec text (because we certainly wouldn't define document.all in 262, right?) I'm personally ok with the current level of specification here.
allenwb commentedon Aug 16, 2016
If we think it was important to document, we could do so as an standalone Ecma Technical Note
bterlson commentedon Aug 16, 2016
@allenwb do you think the formalization we would add in the technical note would be beneficial beyond what is already mentioned in HTML?
allenwb commentedon Aug 16, 2016
@bterlson probably a question best answered by browser implementors. Do they think that the definition provided in the HTML spec is inadequate for somebody who is trying to create an interoperatable implementation? Is so, are the inadequacies of the sort that technically could be best addressed by a TC39 document?
bterlson commentedon Aug 16, 2016
@annevk / @domenic: ^ ?
domenic commentedon Aug 16, 2016
There have been no implementer complaints. This is more about us being concerned that we're bad citizens by monkeypatching ToBoolean/typeof/abstract equality comparison, which is "ES's territory".
bterlson commentedon Aug 16, 2016
The grossness of the spec seems commensurate with the grossness of the desired semantics. I see no problems here :)
annevk commentedon Aug 17, 2016
The other thing is that by not including it here you make it harder to reason about an implementation of the language and might miss something important. And indeed you miss opportunities such as disabling the functionality in certain contexts.
ljharb commentedon Aug 17, 2016
We do have
Object.prototypeas an "exotic immutable prototype object" (pending a formal proposal to make that not be exotic), would we want to define an "exotic falsy object", so that the WHATWG spec could describedocument.allas that? We'd then be able to forbid "exotic falsy objects" in any contexts thatdocument.alldidn't need to exist, as @annevk pointed out.bterlson commentedon Aug 17, 2016
@ljharb that's how I'd do it, probably, but I think the current spec text in HTML is straightforward (and unlikely to be broken by spec revisions) so I'm reluctant to add this machinery. Immutable prototype objects have a use case. Crazy undefined-seeming objects don't beyond this compat hack.
evilpie commentedon Aug 17, 2016
So for the Firefox history see bug 792108. Basically we used to have a special way of passing along a "lookup context" (detecting flags) when calling [[Get]]. So for example when executing
typeof document.allwe would pass along the detecting flag and [[Get]] would return undefined in that case. Having special flags for property lookups is just totally incompatible with ES and was removed completely.Oh and the current approach shared with all other? browsers is basically a lot simpler and just needs a check in a handful of places. (ToBoolean, typeof, ?)
46 remaining items
erights commentedon Aug 18, 2016
(and @allenwb )
annevk commentedon Aug 18, 2016
"A web browser's ECMAScript implementation" and "an implementation of the HTML Standard" both seem fine as prerequisite to me. Or maybe go for "a web reality ECMAScript implementation". 😊
erights commentedon Aug 18, 2016
"A web browser's ECMAScript implementation" is still unclear for subsystems within a browser that do implement ECMAScript but do not implement html. "an implementation of the HTML Standard" still seems fine to me.
Thanks for the smiley face on "a web reality ECMAScript implementation" -- I won't take that one seriously until someone else does ;).
allenwb commentedon Aug 18, 2016
I still don't believe that this should be in ECMA-262 at all, but if we reach consensus that it must then a reference to the HTML spec. along the lines that @bterlson and @erights are discussing should be all we have. We should not make any technical accommodation to theECMA-262 to accommodate this feature as any accommodations could be misused to taken as license for other hosts to do similar but different crazy things.
I don't really see why we are wasting time on this. This is an HTML features involving a HTML host object and it is up to HTML to decide how to specify it. The HTML spec. explicitly calls this feature out as a deviation from ECMA-262. That's good. We can't force platforms not to deviate from ECMA-262 but we should be pleased when platforms acknowledge that they have chosen to deviate for platform specific reasons.
This isn't the only deviation among platforms. Browser CSP deviates WRT
eval(including syntactic direct eval) andFunction. node.js completely eliminates the syntax and semantics of the Script parse goal uses its own non-conforming top level syntax and semantics. Many ES implementations targeting embedded environments have assorted deviations. It isn't our job to try to regularize or police all deviations.allenwb commentedon Aug 18, 2016
@littledan
see http://ecma-international.org/memento/TC39.htm
annevk commentedon Aug 18, 2016
@allenwb CSP is part of the language already. Hook for that landed some time ago.
erights commentedon Aug 18, 2016
@allenwb I am conflicted about the explicit willful violation approach.
As @annevk says, CSP is already accommodated and so does not need to admit any violations.
Pro comment:
In general, for the spec to reflect reality well enough, we should try to keep such explicit violation as small as reasonably possible, as we generally try to do. But yes, I don't see why we would need this to be zero.
document.allseems like a fine candidate for the first permanently unaccommodated willful violation.Con comment:
To mix metaphors horribly, this escape hatch could easily become an avalanche. If it does, then tc39 loses control of real-world JavaScript. Let's revisit a good example of the potential problem:
__proto__. At the time we faced this, the precise details of__proto__across browsers was a complete mess. By bringing this issue into tc39, we made the spec much uglier, but we codified a single clear stance of__proto__that all implementations then shifted to.If we had the "explicit willful violation" escape hatch at the time, I think it is quite likely we would have swept this one under that rug. (Holy mixed metaphors batman!) The chaos of bizarrely different precise semantics for this misfeature would have then continued, which is still much worse than what we achieved by bringing this into tc39.
On
__proto__, although we made the spec uglier, we made reality much cleaner.Having written down both sides as I see it, I still lean against the explicit willful violation approach when we can reasonably avoid it. For
document.allspecifically, I still think the costs of bringing into tc39 -- _if we can agree to do so as the narrowest possible exemption consistent with web reality_ -- is less than the costs of letting it escape into the chaos of "explicit willful violation".However, I don't take this as an absolute principle. I can imagine, in desperation, agreeing that other issues fall on the other side of this line.
claudepache commentedon Aug 19, 2016
See: https://bugs.chromium.org/p/chromium/issues/detail?id=567998
claudepache commentedon Aug 19, 2016
The best strategy I can currently think of:
Importantly, that wouldn’t affect uses of such as
if(document.all)orvar isIE = typeof document.all != "undefined", which won’t break when/ifdocument.allis killed.littledan commentedon Aug 22, 2016
@allenwb I think it would be great if the ECMAScript specification were something that web browsers could ship with 100% accuracy. The current specification doesn't offer an extension point for
document.all--the specification is pretty explicit that all objects are truthy. Although the group's mission does not mention web browsers, ECMAScript has always been developed with web browsers as a primary embedding target.@erights I'm pretty convinced by your "con" argument. I like the idea of "the narrowest possible exemption", but mentioning
"document.all"by name (or part of the name) seems to be going a little too far. What if you wanted to implement a web browser from scratch today, based on specifications? Would you prefer to work with specifications which are explicitly designed to disagree with each other to create local, artificial cleanliness, or ones which layer properly and explain a coherent world together?Jack-Works commentedon Jun 8, 2020
Can anyone tell me what happened in 2017? The graph is weird
devsnek commentedon Jun 8, 2020
As it says right below the graph:
Jack-Works commentedon Jun 8, 2020
Oh thanks... I didn't mention that
SonuG56 commentedon Aug 23, 2024