W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 16 Mar 2012 18:45:08 -0700
Message-ID: <CANMdWTthhT0V2p5xRVX6BTg3eC2Qk-xVV5BEs3UX3caZ7vPuWA@mail.gmail.com>
To: Vincent Hardy <vhardy@adobe.com>
Cc: Anne van Kesteren <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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> 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>
> 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
>
>
>
Received on Saturday, 17 March 2012 01:45:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT