Re: [css3-regions] Suggestions for CSS OM Changes

On 2/27/12 9:33 PM, "David Hyatt" <hyatt@apple.com> wrote:

>Right now I like what is proposed in section 6.1 here:
>
>http://dev.w3.org/csswg/css3-regions/#cssom_view_and_css_regions
>
>I don't really care for 6.2 or 6.3 though. For 6.2, rather than adding
>directly to Element, you could just put the API on NamedFlow instead.
>This compartmentalizes the feature better.
>
>I would suggest these methods on NamedFlow instead:
>
>DOMString overflowForRegion(Element region);
>Range[] flowRangesForRegion(Element region);
>
>Obviously throw an exception if the element passed in is not a region or
>does not contain content from the flow.
>
>For 6.3, I think what you really want is to fire a single event on the
>document itself, and just make sure the named flow is accessible on the
>event. I don't think it makes sense to fire a separate event on every
>region, since you run into bizarre cycles and dependency issues where the
>handling of the event itself can trigger a relayout of earlier regions.
>It seems sufficient to simply have one event that fires whenever the flow
>thread's layout changes in any region.
>
>I would change the name to regionFlowLayoutUpdate and have an event with
>a DOMString field, flow, that tells you the name of the flow that
>changed. Then the author can easily obtain the regions for that named
>flow using the NamedFlow APIs.
>
>dave
>(hyatt@apple.com)
>
>

Right now the NamedFlow interface does not expose the regions associated
with the flow, so we should probably add something like:

readonly attribute NodeList regions;


As with other NamedFlow collections, this one would also be a live
collection.

Cheers,
Mihnea Ovidenie

Received on Monday, 27 February 2012 20:21:52 UTC