W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

Re: Configurable, writable "const" values?

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 01 Dec 2010 13:00:31 -0800
Cc: Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
Message-id: <876B4A91-63E3-470A-925E-A449A71AAEE2@apple.com>
To: Travis Leithead <Travis.Leithead@microsoft.com>

On Dec 1, 2010, at 12:32 PM, Travis Leithead wrote:

> I was reviewing browser Interop for the following scenario, and want to get your take on the matter (because some recent W3C test submissions are exercising these assumptions and IE is considering changing our implementation): 
> 
> var original = Node.ELEMENT_NODE;
> Node.ELEMENT_NODE = "ten";
> var check = Node.ELEMENT_NODE;
> if (original !== check)
>    alert("const properties aren't constant");
> else
>    alert("const properties can't be written");
> 
> 
> Tested__      Result__
> WebIDL        not writable
> Opera         not writable
> IE9           writable
> FF4           writable
> Chrome7       not writable
> Safari5       not writable
> 
> Any objections if IE9 changes to not writable? I presume FF would also eventually change? Is there a web compatibility reason for not doing this?

I don't think there is a web compatibility constraint here. Safari has had the "not writable" behavior for a long time. I expect the other way does not have a problem either. So we should pick what is more sensible as the standard behavior. I think making constants constant is more sensible. I think we'd be open to changing WebKit's behavior if we come to consensus that the writable way is better.

Regards,
Maciej
Received on Wednesday, 1 December 2010 21:01:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC