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