- From: Brendan Eich <brendan@mozilla.org>
- Date: Tue, 13 Oct 2009 01:11:32 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTML WG <public-html@w3.org>
On Oct 13, 2009, at 12:32 AM, Maciej Stachowiak wrote: >> For document.all, which is also falsy (not just in >> ToBoolean(document.all) -> false as I thought, but also in being == >> null and == undefined as you wrote -- and === as well I presume), >> special care will be needed. > > It's specifically *not* strict-equal to null and undefined, at least > in WebKit. Why not === undefined if the object masquerades as undefined? JSLint has caused some document.all === undefined tests to arise, if my memory serves (I will have to check tomorrow). >> You can't treat this property's value like any saner object, even >> if you can assume it is "own" in document or >> HTMLDocument.prototype. Is its property-home really that important >> in light of its unusual value-semantics? > > I don't think I can make a case that specifically for document.all > this detail is important. But I think we should consider the general > case first, and that is what I was trying to do above. Let's deal with document.all. We can hash out prototype bindings in public-script-coord, if they aren't already addressed in the WebIDL draft. I'm fine with what you've described for the general case. The entire point of this thread is document.all in particular, so onward. >>> In the past, we have learned that it's required to have global >>> properties of the Window object with names like "HTMLInputElement" >>> and properties named "prototype" which hold the prototype to be >>> used for HTML input element instances, even though this was not >>> spelled out by former specs. >> >> Isn't HTMLInputElement a replaceable property of the window object? > > It is indeed. But my point was that people depend on the interface > objects and their .prototype properties being there, so they can do > their prototype-hacking thing. I don't think the prototype-hacking > crowd is deeply concerned about program integrity. Nor are such hackers concerned about document.all prototype-hacking, because document.all is simply not prototype-hackable in current browsers. So this is not an issue. > Again, my concerns are primarily about whether this level of detail > is specified for DOM objects in general. Sorry if I was unclear on > that. I don't want to decide the general principle based on > document.all - hard cases make bad law. Hey, I said that (http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0059.html ) :-P. Great, can we get to the specific case that is the subject of this thread? > If for some reason it's way harder to follow Web IDL guidance on > what is an own property and what is a prototype property for the > "all" property of the document object, then that may be a reasonable > choice. This particular detail seems like one of the least important > aspects of document.all behavior to me. Me too, which is why I suggested underspecifying it, which means not specifying document.all in HTML5 using WebIDL as you noted somewhere. >> Separately, someone has to come up with a proposal for ES-Harmony >> if we want standards conformance. > > Can you point me to the resources that describe the process for > that? I can consider writing it up. Will send separately. >>> What about the comma operator? I noticed in testing that >>> "detecting" taint seems to propagate through comma. >> >> Testcase? You may be seeing dead code elimination instead of what >> you think you see. > > <script> > var x = (alert("x"), document.all); You're assigning document.all to x, so this is a detecting case as noted previously (assignment and property initialization in an object initialiser). >> Parentheses around expressions are not part of the abstract syntax. > > I agree in principle, but at least in 3rd edition the grouping > operator had its own pseudo-code operational semantics. ECMA-262 does not specify abstract syntax at all. If there were a bytecode for the comma operator (it would be a nop), it could be skipped (we used to do exactly that for decompiler support). So either way, comma is doable. >> People who bother to detect document.all usually just test its >> falsiness. If they pedantically compare it to something, it's == >> null or undefined, or maybe === undefined (to pass JSLint). We >> never discovered pages needing more. > > Sure, I'm not asking these questions to point out bugs in the > Mozilla implementation I know; I'm detailing our experience not because I worry about bugs, rather to suggest how little machinery is needed to support undetected document.all and increase the number of IE-assuming pages that "work". Over-specifying document.all emulation could "clean up" some browser- specific behavior in cases that aren't actually required for IE-only pages to work. I don't think this is a good use of time if we can agree on a less restrictive spec. >> This is not something I would standardize, as I wrote on public- >> script-coord, in fact it's an unintended consequence. > > Indeed, it sounds like the Gecko behavior as-is would not be a great > candidate for standardization; the precise behavior seems to depend > on SpiderMonkey implementation details. That's overstated. I listed abstract postfix bytecode, almost all corresponding to operators in the language, without naming any SpiderMonkey C++ identifiers. It's equally true that masquerades-as-undefined depends on JSC (WebKit) implementation details at present. Are we making progress by trading these kinds of statements? I don't think so. > So I think the options for document.all are: (1) design a variant of > the Gecko behavior that is suitable to put in a standard; (2) go > with something closer to the WebKit behavior; Who says (2) is suitable to put in a standard? The HTML5 draft explicitly acknowledges that it does not conform to ECMA-262. > (3) write the spec loosely enough that either behavior is > conforming, but the spec gives enough guidance that you can > implement sufficiently compatible behavior by reading it; In case it's not clear, I'm favoring 3. Wait, it was clear. :-/ > (4) have the spec give enough of a blank check that either behavior > is conforming, without any restrictions (so for example making > document.all a completely normal property would also be OK); (5) > have the spec completely ignore this issue. > > I'm not a huge fan of (4) or (5) on that list. I'm not until we spend so much time on this retrograde issue that more forward-looking spec work languishes. :-| /be
Received on Tuesday, 13 October 2009 08:12:56 UTC