W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2016

[whatwg] Opinions on window.console = "foo", and other oddities of window.console

From: Domenic Denicola <d@domenic.me>
Date: Mon, 8 Feb 2016 23:25:55 +0000
To: "whatwg@whatwg.org" <whatwg@whatwg.org>
Message-ID: <CY1PR0501MB1369834F93B752EA5D5336D9DFD50@CY1PR0501MB1369.namprd05.prod.outlook.com>
Cc: "terin@terinstock.com" <terin@terinstock.com>, Travis Leithead <travis.leithead@microsoft.com>, Robert Kowalski <rok@kowalski.gd>
As you may know, we now have a standard for the console object: http://console.spec.whatwg.org/

One of the first issues we encountered while investigating console behavior is https://github.com/whatwg/console/issues/1, which is that browsers currently allow setting `window.console` (and presumably `self.console` in workers) to any value. This is pretty weird, but every tested browser (Firefox, Chrome, Edge, and Safari) follows it.

Probably the default course of action here is to just spec this. But we wanted to check to see if any implementers thought this was weird, and wanted to experiment with e.g. removing the setter.

Even if we do go this route, we have another weirdness:

- Firefox has an accessor descriptor (get/set), Chrome, Safari, and Edge have a data descriptor (value)
- Firefox, Chrome, and Edge are enumerable; Safari is not enumerable

I guess Chrome and Safari's data descriptors are not surprising, given that their bindings infrastructure for Window isn't fully Web IDL-compatible yet. But Edge is pretty surprising. Travis, do you have any info on that?

So I think the plan of record is: `attribute any console`, with prose describing how the getter returns "the window's console object" which is initially set to a new instance of Console, but the setter can change it to any value. This means accessor descriptors and enumerable, since that's how IDL works. If anyone thinks this is bad, let us know. Otherwise the standard will be updated any day now in that direction. 
Received on Monday, 8 February 2016 23:26:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:37 UTC