[WebIDL] Treatment of getters and setters

Hello WGs.

I’ve just committed changes to Web IDL on how it treats index and name
getters and setters.  Browers don’t agree on some specifics of how the
index and name properties on HTMLCollections are handled, so I’ve tried
to make some sensible decisions in these cases.  Comments welcome!

Here’s a summary of changes to Web IDL:

  * Removed [IndexGetter], [IndexSetter], [NamedGetter] and
    [NamedSetter].

  * Removed the custom [[Get]] behaviour on host objects.

  * Added [NumberedIndex] and [NamedIndex], which can appear on
    interfaces.  Both of these can take identifier arguments Creatable,
    Modifiable and/or Deletable, which control how the properties that
    are placed on host objects can be interacted with.  Properties for
    [NumberedIndex] are enumerable, and those for [NamedIndex] aren’t.

  * Changed the custom [[Put]] behaviour on host objects so that it
    only is there to support [PutForwards].

For details see:

  http://dev.w3.org/2006/webapi/WebIDL/#NamedIndex
  http://dev.w3.org/2006/webapi/WebIDL/#NumberedIndex
  http://dev.w3.org/2006/webapi/WebIDL/#index-properties

As a consequence, I suggest the following changes in HTML 5.

The section describing HTMLCollection would need something like the
following (and the other collection interfaces would need something
similar):

  [NumberedIndex, NamedIndex]
  interface HTMLCollection {
    readonly attribute unsigned long length;
    Element item(in unsigned long index);
    Element namedItem(in DOMString name);
  };

  The numbered index has keys in the range 0 ≤ index < length, which
  map to the indexth node in the collection.

  The named index has a key for every string that when passed to
  namedItem() would return a node, and which maps to that returned node.

Storage would need something like:

  [NumberedIndex, NamedIndex=(Modifiable,Removable)]
  interface Storage {
    readonly attribute unsigned long length;
    DOMString key(in unsigned long index);
    DOMString getItem(in DOMString key);
    void setItem(in DOMString key, in DOMString data);
    void removeItem(in DOMString key);
    void clear();
  };
  
  The numbered index has keys in the range 0 ≤ n < length, which
  map to the nth key in the list associated with the Storage object.
  
  The named index has a key for every key in the list associated with
  the object, which maps to the corresponding value in the list.
  
  When the value of a named index entry is modified, the value of the
  corresponding entry in the object's key/value pair list is set to the
  same value.
  
  When a named index entry is removed, the corresponding entry in the
  object's key/value pair list is removed.

And for DOMStringMap:

  [NamedIndex=(Creatable,Modifiable,Removable)]
  interface DOMStringMap {
  };
  
  The named index has entries that depend on the algorithms associated
  with the DOMStringMap object.  The keys of the named index are those
  that would be returned from calling the algorithm for enumerating
  names.  Each key maps to the value that would be returned from calling
  the algorithm for getting values from names, passing that key as the
  name.
  
  When the value of a named index entry is created or modified, the
  algorithm for setting names to certain values must be called, passing
  the entry's key as the name and the entry's value as the value.
  
  When the value of a named index entry is removed, the algorithm for
  deleting names must be called, passing the entry's key as the name.
  The named index entry removal must return true.

This would require adding a fourth algorithm for DOMStringMaps, the
“algorithm for enumerating names”.  It would just look at the current
@data-* attributes on the element.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 17 November 2008 08:17:11 UTC