[whatwg] WebIDL vs HTML5 storage changes
beidson at apple.com
Mon May 19 16:56:07 PDT 2008
>> 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
> - 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,
> 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 = 'value';
> storage.setItem('keyName', 'value');
> delete storage.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
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.
More information about the whatwg