Congratz. It was document.all.
"In case you're wondering, I've never seen anyone return or store
`document.all` ever."
Before W3C standard you could (and some people did):
function elements() {
if(document.all) {
return document.all
} else if(document.layers) {
return document.layers
} else {
throw "You must use IE4+ or NS 4.7!"
}
}
This is actually the wrong way to use document.layers, but it was not uncommon
to see. Later when the W3C was standardizing, you managed the three pathways by
passing the id to the function.
You can see examples of this on comp.lang.javascript, and through a search
engine by looking for "return document.all" or "return document.layers". There
are also some legacy books showing the practice.
/Michael
-----Original Message-----
From: Isiah Meadows <[email protected]>
Sent: Saturday, July 27, 2019 4:42 PM
To: Michael Haufe <[email protected]>
Cc: Jordan Harband <[email protected]>; [email protected]
Subject: Re: Proposal: Typeof Trap
`document.all`, and that's only required for web browsers to implement
- it's in Annex B. Some newer JS engines targeting non-browser platforms (like
Moddable's XS and I believe Nashorn as well) don't even implement it, and it
leads to a slightly simpler runtime.
And it's only there thanks to a bunch of people relying on `if
(document.all) doSomething()` for detecting legacy crap while others at the
same time just assuming it's there without checking for it first, almost always
on ancient web pages. Oh, and people were also calling it via
`document.all(nameOrIndex)` instead of `document.all[nameOrIndex]`, so the HTML
spec also has it implementing `[[Call]]`.
- HTML spec:
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#the-htmlallcollection-interface
- ES spec: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
In case you're wondering, I've never seen anyone return or store `document.all`
ever.
-----
Isiah Meadows
[email protected]
www.isiahmeadows.com
On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[email protected]> wrote:
>
> More than one case:
>
>
>
> <script>
>
> var foo = f()
>
> typeof foo // object
>
> foo instanceof Object // false
>
>
>
> var bar = g()
>
> typeof bar //undefined
>
> bar instanceof Object //true
>
> bar() //
>
> </script>
>
>
>
> You could probably guess what the value of foo is. Can you guess what the
> second is in any useful way?
>
>
>
> From: Jordan Harband <[email protected]>
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe <[email protected]>
> Cc: [email protected]
> Subject: Re: Proposal: Typeof Trap
>
>
>
> With something that while unintuitive in one case, is eternally robust and
> reliable.
>
>
>
> If you want extensibility, define Symbol.toStringTag on your objects.
>
>
>
> On Sat, Jul 27, 2019 at 1:23 PM Michael Haufe <[email protected]>
> wrote:
>
> If it's unfixably broken[1], non-extensible, excessively vague, and
> non-orthogonal, where does that leave you?
>
>
>
> [1] <https://twitter.com/BrendanEich/status/798317702775324672>
>
>
>
> From: Jordan Harband <[email protected]>
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe <[email protected]>
> Cc: ViliusCreator <[email protected]>;
> [email protected]
> Subject: Re: Proposal: Typeof Trap
>
>
>
> Those two PRs are about removing implementation-defined behavior from
> `typeof`, making it *more* reliable - there is no trend away from using and
> relying on `typeof`, full stop.
>
>
>
> `Symbol.hasInstance` is a part of why `instanceof` is actually unreliable -
> because user code can hook into it. It would be a massive loss imo if
> `typeof` lost its bulletproof status by adding a user hook.
>
>
>
> On Sat, Jul 27, 2019 at 12:37 PM Michael Haufe <[email protected]>
> wrote:
>
> The trend seems to be to rely on typeof less and less as time passes:
>
>
>
> From the March 2019 Agenda
> <https://github.com/tc39/agendas/blob/274e49412c09f81a0a82f386e6eead481c69adad/2019/03.md>:
>
>
>
> “Implementation-defined typeof still necessary?”
> <https://github.com/tc39/ecma262/issues/1440>
>
> “Normative: Remove implementation-defined typeof behavior”
> <https://github.com/tc39/ecma262/pull/1441>
>
>
>
>
>
> The only real discussion around this I can find is from a related proposal
> from Brendan Eich a few years ago:
>
>
>
> https://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-
> objects-slides-from-thursday-s-tc39-meeting
>
>
>
>
>
>
>
> From: ViliusCreator <[email protected]>
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe <[email protected]>
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
