- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 16 Feb 2012 08:58:05 +0100
- To: "Alex Russell" <slightlyoff@google.com>, "Marcos Caceres" <w3c@marcosc.com>, "Travis Leithead" <travis.leithead@microsoft.com>, "Anne van Kesteren" <annevk@opera.com>
- Cc: "Dominique Hazael-Massieux" <dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Harald Alvestrand" <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, 15 Feb 2012 21:47:37 +0100, Anne van Kesteren <annevk@opera.com> wrote: > On Wed, 15 Feb 2012 20:31:05 +0100, Travis Leithead > <travis.leithead@microsoft.com> wrote: >> Sounds like the argument for consistency with previous "readyState" >> definitions loses to the use the new best-practice approach. >> >> To accommodate both, perhaps you should consider _not_ using the name >> readyState, and chose another similar-name that can apply the >> best-practice syntax. > > Yeah, you could e.g. use "state". "readyState" is all over the place and > used for many different things. In XMLHttpRequest it is probably best > avoided these days in favor of more fine-tuned events. Can't we have our cake and eat it too? If we really want to favor consistency on the scripting side (not implementation), we could let HTMLMediaElement.readyState and XMLHttpRequest.readyState return magic objects that compare true both to their string and their numeric constants. It might have to toString to the number, though... -- Philip Jägenstedt Core Developer Opera Software
Received on Thursday, 16 February 2012 07:58:48 UTC