W3C home > Mailing lists > Public > www-style@w3.org > March 2013

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

From: Andrei Bucur <abucur@adobe.com>
Date: Mon, 25 Mar 2013 17:13:02 +0000
To: Alan Stearns <stearns@adobe.com>
CC: Mihnea-Vlad Ovidenie <mihnea@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <2C2E2351-56F8-43F0-BFE5-0AFE2A9A1F20@adobe.com>

On Mar 25, 2013, at 6:45 PM, Alan Stearns <stearns@adobe.com> wrote:

> (hopefully fixing the top-posting correctly)
>> On 3/25/13 7:53 AM, "Andrei Bucur" <abucur@adobe.com> wrote:
>>> On Mar 23, 2013, at 1:12 AM, Alan Stearns <stearns@adobe.com> wrote:
>>>> On 3/22/13 6:32 AM, "Mihnea-Vlad Ovidenie" <mihnea@adobe.com> wrote:
>>>> Hi,
>>>> CSSRegions spec [1] has a paragraph describing the computation of
>>>> offset*
>>>> attributes for elements laid out in a named flow. However, it does not
>>>> mention explicitly if/how collecting an element inside a named flow
>>>> affects the way *offsetParent* [2] is determined.
>>>> For instance, in the case of the following markup:
>>>> <div id="contentNode" style="flow-into: flow">
>>>> </div>
>>>> What should *document.getElementById("contentNode").offsetParent*
>>>> return?
>>>> In my opinion, it should return *null*, meaning that the algorithm of
>>>> determining the closest positioned containing element for an element
>>>> collected in a named flow should stop at the named flow level (and
>>>> return
>>>> null in this case).
>>>> Thoughts?
>>>> [1] http://dev.w3.org/csswg/css3-regions/#cssomview-offset-attributes
>>>> [2]
>>>> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interf
>>>> ac
>>>> e
>>> I do not think it should return null. But I don't think that following
>>> the
>>> algorithm defined in cssom-view for fragmented content is necessarily the
>>> right thing to do either. That algorithm doesn't take fragmentation
>>> contexts into account. Since the various offset properties are concerned
>>> with the edges of the CSS layout box, it makes much more sense to me to
>>> update the algorithm to accommodate fragment containers.
>>> Instead of only considering ancestor elements in step 2 of the
>>> offsetParent algorithm, I think it should walk the ancestor chain up to
>>> the nearest fragment boundary, then hop to the fragment container and
>>> walk
>>> its ancestry (repeating for as many fragmentation contexts as are
>>> nested).
>>> Thus the result could be the region containing the element, or a
>>> positioned ancestor of that region.
>>> If and when columns or overflow:fragment boxes can be positioned, this
>>> will be an issue for those fragmentation contexts as well. And in a
>>> paginated view case, I think it will be much more useful to return the
>>> page containing the element.
>>> Thanks,
>>> Alan
>> With regions, this is more complicated because an element
>> gets to occupy a certain space inside the viewport because
>> of both the flow layout and region layout. I can imagine
>> there are situations when developers want to access the
>> offsetParent relative to the flow in some contexts and the
>> visual offsetParent relative to the regions in other contexts.
>> If we go with the approach of changing this to follow only
>> the visual ancestor path there will be no easy way to compute
>> the flow offset* properties. I don't have hard data but I
>> think there are JS libraries that use the offset* properties
>> to make adjustment to the position of elements after layout.
>> If we take the elements using those hypothetical libraries
>> and flow them inside regions their layout will break because
>> they expect offsetParent to point inside the flow, not the regions.
>> Maybe we can create a new API on the CSSOM (like visualOffset*)
>> that can behave the way you described for regions, overflow
>> fragments etc. and follow the visual ancestor path.
> I think named flows and insertion points/shadow dom [1][2] are already
> breaking assumptions that scripts might have about offsetParent. We should
> be looking at what this API is meant to do, and see what makes sense in
> fragmentation contexts with positionable containers. My take is that the
> offsetParent should be the nearest display box for which you can get
> relevant offset values. Take this example:
> #relative-parent {
>  position: relative;
> }
> #relative-child {
>  position: relative;
>  flow-into: named-flow;
> }
> #region {
>  position: relative;
>  flow-from: named-flow;
> }
> <div id="relative-parent">
>  <div id="relative-child"></div>
> </div>
> <div id="region"></div>
> The current algorithm says that relative-child.offsetParent is
> relative-parent, when it's actually being positioned relative to the
> region. I don't think it's useful to return offsetTop, etc. values
> calculated from these disconnected boxes.
> Thanks,
> Alan
> [1] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0881.html
> [2] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0948.html

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

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.

Received on Monday, 25 March 2013 17:14:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC