The main reason to keep NodeList is because we'd like to add other APIs to NodeList in the future that operate on the Nodes in the list (e.g. remove). I don't really see use-cases for wanting a similar thing with the other cases here, so I think sticking with arrays of Ranges and Regions is fine.
On Fri, Mar 16, 2012 at 6:56 AM, Vincent Hardy <vha...@adobe.com> wrote: > > On Mar 16, 2012, at 1:40 AM, Anne van Kesteren wrote: > > On Fri, 16 Mar 2012 01:59:48 +0100, Vincent Hardy <vha...@adobe.com> > wrote: > > b. Use sequence<T> everywhere except where T=Node, in which case we > > would use NodeList. This is consistent with DOM4 and inconsistent within > > the spec. > > > I think this is fine, but you should use Range[] and not sequence<Range>. > You cannot use sequence for attributes. Do you have a pointer to the > specification by the way? Kind of curious why you want to expose a list of > > Range objects. > > > Hi Anne, > > The proposal is at http://wiki.csswg.org/spec/css3-regions/css-om. The > proposed modifications are not in the specification yet, they need more > discussions. > > The proposal is to use sequence<Range> as returned values from functions, > not as attribute values, which is why I went with sequence<T> and not T[] > (I had a brief exchange with Cameron about this). > > what I proposed as option b. in my message would be: > > interface Region { > readonly attribute DOMString flowConsumed; > sequence<Range> getRegionFlowRanges(); // Returns a static list, new > array returned on each call > }; > > interface NamedFlow { > readonly attribute DOMString name; > readonly attribute boolean overflow; > > sequence<Region> getRegions(); // Returns a static list, new array > returned on each call > NodeList getContentNodes(); // Returns a static list, new array returned on > each call > sequence<Region> getRegionsByContentNode(Node node); // idem > }; > > > The alternate options on the page are: > > *Option I* > > > interface Region { > readonly attribute DOMString flowConsumed; > sequence<Range> getRegionFlowRanges(); > }; > > > interface NamedFlow { > readonly attribute DOMString name; > readonly attribute boolean overflow; > > sequence<Region> getRegions(); > sequence<Node> getContentNodes(); > sequence<Region> getRegionsByContentNode(Node node); > }; > > > Or: *Option II* > > > [ArrayClass] > interface RangeList { > getter Range? item(unsigned long index); > readonly attribute unsigned long length; > }; > > [ArrayClass] > interface RegionList { > getter Region? item(unsigned long index); > readonly attribute unsigned long length; > }; > > interface Region { > readonly attribute DOMString flowConsumed; > RangeList getRegionFlowRanges(); > }; > > interface NamedFlow { > readonly attribute DOMString name; > readonly attribute boolean overflow; > > RegionList getRegions(); > NodeList getContentNodes(); > RegionList getRegionsByContentNode(Node node); > }; > > The reason we are using an array of ranges as opposed to a single Range > object is that the named flow is made of a a list of elements that do not > share a common parent. So for example, we can have a sequence of elemA and > then elemB in the named flow, but they do not have the same parent. When > they are laid out across regions, say region1 and region2, we may get all > of elemA in region1 and some of elemB. In that case, the ranges for region1 > would be: > > - first range that encompasses all of elemA > - second range that encompasses some of elemB > > and for region2: > > - range that encompasses the remainder of elemB (i.e, the start container > and offset on this range are the same as the end container and end offset > on the last range in region1). > > Does that answer your question? > Vincent > > >
