@wallhackio @vaporeon_ lmao

@wallhackio @vaporeon_ now THIS is javascript

@wallhackio @vaporeon_ this behavior is standardized btw https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-IsHTMLDDA-internal-slot

@wallhackio @vaporeon_ a consequence of this standardization is that, in web browsers, document.all == null and null == document.all are both true

@wallhackio @vaporeon_ so anyway MDN is lying here when they say the behavior is "non-standard". it is literally standardized

@wallhackio @vaporeon_ oh they mean that the actual document.all purropurrty is nonstandard, as in, the DOM---wait no fuck the standard says it's "obsolete" but REQUIRED fur implementers to implement a document.all purropurrty

@aescling @wallhackio @vaporeon_ I believe they mean the property "document.all is null in some comparisons" is what they're saying is nonstandard and should not be relied upon. es2027 technically says it must not happen elsewhere but *can* happen for document.all and the HTML standard doesn't say one way or the other, so I'm not sure it technically is a standard. (Either way it is not a "standard" value when coercing an HTMLCollection to boolean and worth calling out.)

@aescling @vaporeon_ sure Brandon Eich, why not do that

@aescling @wallhackio Can you explain to Vaporeon what is happening here?

@vaporeon_ @wallhackio i am showing that, in the browser, document.all exists and is an object. boolean conversion of document.all purroduces false, which the exception to the rule that objects are always truthy (which is to say, the rule that the interal boolean coercion mechanism always purroduces true when coercing an object)

@wallhackio @vaporeon_ or if you lint your js with typescript, the only actually good use fur typescript

@wallhackio @vaporeon_ fuck the typescript compiler i just wanna run my actual js directly