Re: [css3-regions] offsetParent for element collected inside a named flow

On 3/25/13 10:13 AM, "Andrei Bucur" <abucur@adobe.com> wrote:

<snip>

>
>(sorry for top-posting! It's fixed now, right?)
>
>I don't refer to the case when you interogate offsetParent on the direct
>flow children. What I had in mind is something like this:
><div id="outside" style="position: relative; flow-into: flow;">
>...Fragment 1 of div... (in region 1)
>...Fragment 2 of div... (in region2)
><div id="inside"></div>
></div>
>
>We have a flow with two regions and an "outside" div flown inside it. A
>part of "outside" is laid out in "region1". The other part in "region2",
>including the "inside" div.
>The problem appears when asking offsetParent for the "inside" div. The
>visual offsetParent is "region2". The flow offsetParent is "outside".
>
>The idea is to be careful not to break content assuming offsetParent
>would return "outside" and do something with it. This can happen if the
>developer is interested on who is positioning "inside" on a smaller
>scale, locally, and wants for example to measure the distance between
>"outer" and "inside" in flow coordinates.
>
>I agree most of the time people will want the visual offsetParent (e.g.
>to determine the distance to the top of the viewport) but I guess we
>should leave a way for developers to handle the above use case.

I think you're arguing to backward-compatibility; it's hard to tell how
much of it you're going to get since offsetTop/offsetLeft
will presumably reflect where the regions laid out the content nodes and
those may break assumptions made by existing code anyway
(e.g. that descendants have a higher offsetTop). Any attempt to make
properties in the offset* family make sense in new layouts
must consider the cases when they are used together.

I suppose a minimal starting point is to look at what happens to these
properties for elements flowing inside a multicol.

Received on Monday, 25 March 2013 21:12:37 UTC