- From: David Hyatt <hyatt@apple.com>
- Date: Mon, 27 Feb 2012 13:33:01 -0600
- To: "www-style@w3.org Style" <www-style@w3.org>
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)
Received on Monday, 27 February 2012 19:33:42 UTC