Re: [DOMCore] Is Element.attributes live or static?

On 6/19/11 10:49 PM, Boris Zbarsky wrote:
> On 6/20/11 1:26 AM, David Flanagan wrote:
>> With all the changes that DOM Core makes to the attributes attribute
>> (moving it from Node to Element, changing it from NamedNodeMap to
>> Attr[], and making Attrs not nodes) it is no longer clear whether it is
>> supposed to be a live representation of an elements' attributes.
>
> The current Web DOM Core text makes it non-live as far as I can see. 
> There is no concept of "Live" for WebIDL arrays.
But there is nothing that prevents the elements or length of a read-only 
WebIDL array from changing behind-the-scenes.  User code can't change 
the array elements, but my reading is that the implementation can:
>
> Arrays can either be fixed length or variable length. Fixed length 
> arrays cannot have their length changed by user code after they have 
> been created, while variable length arrays can. Unless otherwise 
> specified, arrays are fixed length.
>
> Arrays can also be designated as being read only. User code cannot 
> modify the values of read only array elements. If an array is read 
> only, then it is also implicitly fixed length 
> <http://dev.w3.org/2006/webapi/WebIDL/#dfn-fixed-length>.
>
That same section (§3.8.19) also says "An array returned from a user 
agent implemented object might also be modified by the object".

So I think that if DOM Core wants this to be a live collection, WebIDL 
won't get in the way.  If we were talking about a getAttributes() 
method, I'd expect it to return a static snapshot. But since attributes 
is an attribute, I'd expect it to return the same value each time and 
I'd expect that value to be live.  So even if we could get away with 
static here, I think that live is the better choice.

     David

>> I assume that web compatibility requires attributes to be live.
>
> It may well, yes....  In which case the current spec text is probably 
> not ok.  Data would be good.
>
> -Boris
>