W3C home > Mailing lists > Public > www-style@w3.org > February 2012

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

From: Mihnea-Vlad Ovidenie <mihnea@adobe.com>
Date: Mon, 27 Feb 2012 20:20:41 +0000
To: David Hyatt <hyatt@apple.com>, "www-style@w3.org Style" <www-style@w3.org>
Message-ID: <CB71B0BC.192F9%mihnea@adobe.com>

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:
>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.

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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC