W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2008

[whatwg] WebIDL vs HTML5 storage changes

From: Brady Eidson <beidson@apple.com>
Date: Mon, 19 May 2008 16:56:07 -0700
Message-ID: <E2CC0E97-39B5-4126-86EC-AD801634DA7D@apple.com>
>> I looked into this and in all other cases we use an override of  
>> delete for the following effects:
> - Special case for Arrays since they store some of their properties  
> differently.
> - Prevent deletion (though it would be better in most of these cases  
> to just rely on DontDelete attributes)/
> - Cross-site scripting security checks on delete.
> I think the Storage case would be more complicated than this,  
> because it dispatches an event and so can run arbitrary JavaScript  
> code. I think our JS interpreter is likely not prepared for "delete"  
> executing arbitrary JS code, and so may crash when this happens. We  
> can fix it, but I think delete having special behavior is not that  
> great from the point of design.
> Comparing conciseness and familiarity:
> storage.keyName
> storage.getItem('keyName')
> storage.keyName = 'value';
> storage.setItem('keyName', 'value');
> delete storage.keyName;
> storage.removeItem('keyName');
> The getter seems like the biggest relative increase in conciseness,  
> and the getter and setter will both be much more familiar with  
> operator syntax. But delete is fairly rarely used (and unlike  
> getters and setters does not allow overriding at the JS level in  
> many implementations) so the syntax is not much more familiar. The  
> improvement in conciseness is also less.
> We should also keep in mind that overloading operators is kind of a  
> big deal and should not be done lightly. If the HTML5 spec required  
> custom behavior for * or && for certain objects rather than  
> following the JS rules I think we would all be pretty concerned.
> So I'd rather avoid messing with the (relative) purity of the delete  
> operator.

I am a lot more swayed by this argument against adoption.

At this point, my concerns are not of a technical nature, but rather  
of a "real life web" nature - either you force FFX and IE8 to remove  
it, you have others adopt it, or the spec introduces a de facto  
incompatibility on the web.

I have no solution, only this particular awareness of the problem.


> Regards,
> Maciej
Received on Monday, 19 May 2008 16:56:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:02 UTC