Re: [DOM4] Question about using sequence<T> v.s., NodeList for

Hi Ojam, all,

Thanks for the feedback. I have updated the proposed changes (http://wiki.csswg.org/spec/css3-regions/css-om) to use a static NodeList for Nodes and sequence<T> for Ranges and Regions.

Cheers,
-v

From: Ojan Vafai <ojan@chromium.org<mailto:ojan@chromium.org>>
Date: Fri, 16 Mar 2012 18:45:08 -0700
To: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: Anne van Kesteren <annevk@opera.com<mailto:annevk@opera.com>>, "public-webapps@w3.org<mailto:public-webapps@w3.org>" <public-webapps@w3.org<mailto:public-webapps@w3.org>>
Subject: Re: [DOM4] Question about using sequence<T> v.s., NodeList for

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 <vhardy@adobe.com<mailto:vhardy@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 <vhardy@adobe.com<mailto:vhardy@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