This is an old revision of the document!


CSS Object Model for CSS Regions

getFlowByName when there is no flow

Access to flow content (suggested CSS OM Changes)

Changes proposed here follow the discussion on the mailing list.

Region interface

This would replace the supplemental Element interface:

interface Region {
    readonly attribute DOMString regionOverflow;
    getter Range[] getRegionFlowRanges();
};              
NamedFlow interface changes

Changes:

  1. Ordered List ItemThe getRegionsByContentNode method now returns a static array of Regions, not a live NodeList.
  2. The contentNodes attribute now returns a static list of nodes. Should this be changed to 'getContentNodes()' to make this more obvious to the user?
  3. Added a getRegions method to get the current list of regions which are associated with the NamedFlow.
interface NamedFlow {
  readonly attribute DOMString name;
  readonly attribute boolean overflow;
  
  getter Region[] getRegions();
  getter Node[] getContentNodes();
  Region[] getRegionsByContentNode(Node node);
};

Flowed content boxes and DOM access

getClientRects and getBoundingClientRects

The DOM specification provides a way to compute the bounding client rectangle for an element (getBoundingClientRect()) and its generated boxes (getClientRects).

The current definition seems appropriate for CSS regions and the multiple boxes generated for an element flowing through multiple regions. The getClientRects method would return the list of boxes for the element found in the different regions. The getBoundingClientRect method would work as specified.

offsetWidth/offsetHeight/offsetTop/offsetLeft

The offsetWidth/offsetHeight/offsetTop/offsetLeft attributes would work as specified, using the first box, i.e., the first part of the element flowing in a region. The usefulness of that is limited, but it is the same situation as for elements flowing in a multi-column.

The clientTop/clientLeft/clientWidth/clientHeight attributes are relative to the padding edge of the element. For an element fragmented accross region, the padding edge would be made of the outermost edges, for all the element's fragment boxes. However, this does not seem to be the way implementations work for multi-column content, where the WebKit and Opera browsers report the edges of the element as if it was laid out in a single column (i.e., as if it appended all the fragments in the box direction), Firefox reports the edges of the first fragment's box.

 
spec/css3-regions/css-om.1331678600.txt.gz · Last modified: 2014/12/09 15:48 (external edit)
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki