This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
spec:css3-regions:css-om [2012/03/27 14:03] – vhardy | spec:css3-regions:css-om [2012/03/27 14:25] – vhardy | ||
---|---|---|---|
Line 1: | Line 1: | ||
==== CSS Object Model for CSS Regions ==== | ==== CSS Object Model for CSS Regions ==== | ||
+ | |||
+ | === Flowed content boxes and DOM access === | ||
+ | |||
+ | == getClientRects and getBoundingClientRects == | ||
+ | |||
+ | **Integrated** https:// | ||
+ | |||
+ | The DOM specification provides a [[http:// | ||
+ | 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/ | ||
+ | |||
+ | **Integrated** https:// | ||
+ | |||
+ | The offsetWidth/ | ||
+ | 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/ | ||
+ | an element fragmented accross region, the padding edge would be made of the outermost edges, for all the element' | ||
+ | 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' | ||
+ | |||
=== getFlowByName when there is no flow === | === getFlowByName when there is no flow === | ||
Line 84: | Line 113: | ||
Issue: should we have a RegionChain abstraction that is associated 1:1 (for now) with a NamedFlow. | Issue: should we have a RegionChain abstraction that is associated 1:1 (for now) with a NamedFlow. | ||
- | |||
- | === Flowed content boxes and DOM access === | ||
- | |||
- | == getClientRects and getBoundingClientRects == | ||
- | |||
- | The DOM specification provides a [[http:// | ||
- | 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/ | ||
- | |||
- | The offsetWidth/ | ||
- | 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/ | ||
- | an element fragmented accross region, the padding edge would be made of the outermost edges, for all the element' | ||
- | 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' | ||
=== Document interface additions === | === Document interface additions === |