Re: [DOM4] Question about using sequenceT v.s., NodeList for

2012-03-16 Thread Vincent Hardy

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.commailto:vha...@adobe.com wrote:
b. Use sequenceT 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 sequenceRange.
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 sequenceRange as returned values from functions, not 
as attribute values, which is why I went with sequenceT 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;
sequenceRange getRegionFlowRanges(); // Returns a static list, new array 
returned on each call
};

interface NamedFlow {
  readonly attribute DOMString name;
  readonly attribute boolean overflow;

  sequenceRegion getRegions();  // Returns a static list, new array returned 
on each call
  NodeList getContentNodes(); // Returns a static list, new array returned on 
each call
  sequenceRegion getRegionsByContentNode(Node node); // idem
};

The alternate options on the page are:

Option I

interface Region {
readonly attribute DOMString flowConsumed;
sequenceRange getRegionFlowRanges();
};

interface NamedFlow {
  readonly attribute DOMString name;
  readonly attribute boolean overflow;

  sequenceRegion getRegions();
  sequenceNode getContentNodes();
  sequenceRegion 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




Re: [DOM4] Question about using sequenceT v.s., NodeList for

2012-03-16 Thread Ojan Vafai
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 sequenceT 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 sequenceRange.
 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 sequenceRange as returned values from functions,
 not as attribute values, which is why I went with sequenceT 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;
 sequenceRange getRegionFlowRanges(); // Returns a static list, new 
 array returned on each call
 };

 interface NamedFlow {
   readonly attribute DOMString name;
   readonly attribute boolean overflow;

   sequenceRegion getRegions();  // Returns a static list, new array 
 returned on each call
   NodeList getContentNodes(); // Returns a static list, new array returned on 
 each call
   sequenceRegion getRegionsByContentNode(Node node); // idem
 };


 The alternate options on the page are:

 *Option I*


 interface Region {
 readonly attribute DOMString flowConsumed;
 sequenceRange getRegionFlowRanges();
 };


 interface NamedFlow {
   readonly attribute DOMString name;
   readonly attribute boolean overflow;

   sequenceRegion getRegions();
   sequenceNode getContentNodes();
   sequenceRegion 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





Re: [DOM4] NodeList should be deprecated

2012-03-16 Thread Ojan Vafai
On Wed, Mar 14, 2012 at 5:32 AM, Anne van Kesteren ann...@opera.com wrote:

 On Wed, 14 Mar 2012 09:03:23 +0100, Cameron McCormack c...@mcc.id.au
 wrote:

 Anne van Kesteren:

 Wasn't there a compatibility constrain with doing that?


 I don't remember -- the only difference it would make is that
 Object.getPrototypeOf(**NodeList.prototype) == Array.prototype.


 Okay, annotated NodeList with [ArrayClass]. What about HTMLCollection?
 Should I add it there too? Could you take a look at NodeList and
 HTMLCollection for accuracy?


Should HTMLCollection inherit from NodeList? All the APIs I can think of
that you'd want to add to NodeList you'd want on HTMLCollection as well.

To be clear, array methods that modify the array in-place would silently do
nothing because the properties on NodeLists/HTMLCollections are read-only.
But you'd be able to use things like forEach and filter.


Re: [DOM4] NodeList should be deprecated

2012-03-16 Thread Cameron McCormack
Anne van Kesteren:  Okay, annotated NodeList with [ArrayClass]. What 
about HTMLCollection?

Should I add it there too? Could you take a look at NodeList and
HTMLCollection for accuracy?


It is probably not feasible to add to HTMLCollection, because it has a 
named property getter which is not [OverrideBuiltins].  That means that 
all the new properties on the prototype like concat, push, etc. 
would begin to shadow any named elements on the collection.




Re: [DOM4] NodeList should be deprecated

2012-03-16 Thread Cameron McCormack
Cameron McCormack:  It is probably not feasible to add to 
HTMLCollection, because it has a

named property getter which is not [OverrideBuiltins].  That means that
all the new properties on the prototype like concat, push, etc.
would begin to shadow any named elements on the collection.


On the other hand it would be great to be able to do things like:

  document.getElementsByTagName(span)
  .map(function(x) { return x.clientWidth });

:(

I am a bit reluctant to special case the visibility of named properties 
on HTMLCollection to be something other than the current 
[OverrideBuiltins] or non-[OverrideBuiltins] behaviour.