Re: [css3-regions] issue: is first region initial containing block

On 10/02/2012 06:48, Brad Kemper wrote:
> On 09/02/2012 19:59, David Hyatt wrote:
>> On 09/02/2012 19:08, Brad Kemper wrote:
>>> On 09/02/2012 18:51, David Hyatt wrote:
>>>> On 09/02/2012 05:44, Brad Kemper wrote:
>>>>> On 08/02/2012 19:04, David Hyatt wrote:
>>>>>>
>>>>>> I kind of covered this in another message, but I don't think
>>>>>> regions themselves should be containing blocks for flow thread
>>>>>> content. Rather the ICB for a flow thread should simply match
>>>>>> the dimensions of the first region. This is analogous to how
>>>>>> the ICB for the root element matches the dimensions of the
>>>>>> viewport (or the first page when printing). The ICB for flow
>>>>>> thread contents should not be the region itself though. I don't
>>>>>> think that makes any sense at all.
>>>>>
>>>>> I still don't see what is so wonderful about the first region, or
>>>>> of something with the same dimensions and placement, that it must
>>>>> be the ICB. Why not let an author use the normal root of the
>>>>> window viewport as the ICB, if all ancestor elements are
>>>>> position:static? This is different from printed pages, where
>>>>> there is no page parent to position against.
>>>>
>>>> It depends on what you believe is happening when positioned
>>>> elements are placed in a flow thread. I dislike the idea that the
>>>> positioned object "busts out" of the flow thread if authors don't
>>>> do something to the regions themselves (e.g., position:relative) to
>>>> contain them.

But positioned elements can already bust out of things that are similar 
to flows (if not actually flows themselves): non-positioned floats.

Is your model of a "flow" something that scopes positioned elements in 
some sense?  And so floats don't establish new flows in your model, but 
abspos elements do, for example?

>>>> What you're essentially saying is that if somebody
>>>> tries to paginate content by putting it into regions that the
>>>> positioned content just isn't going to paginate unless something is
>>>> done to contain it.

But I don't see how your model "paginates" content either.  If the 
initial region in a region chain establishes the containing block of 
some abspos element in the flow, the abspos is physically positioned 
relative to the location of that region, not relative to the flow itself.

>>> I prefer to think of it as giving authors the choice to decide
>>> for themselves whether or not their positioned objects should be
>>> positioned relative to the regions or relative to something
>>> containing the regions (such as the page or viewport). What
>>> you're essentially saying is that if somebody tries to paginate
>>> content by putting it into regions, that anything flowing into
>>> that region can never be positioned relative to some ancestor of
>>> the region. That seems like a huge restriction to me, and
>>> unnecessary.
>>
>> I don't see this as much of a restriction. If you wanted to
>> position content relative to the page or viewport, you simply
>> wouldn't put it in the flow thread.

(Snip this discussion. I agree with Brad; we shouldn't make assumptions 
about why authors might or might not want to do something.  Just because 
I've chosen to flow content somewhere doesn't mean I'm asking for 
restrictions on how I abspos things inside it.

>> I don't understand why you would ever want to put positioned
>> content into a flow thread only to have it break out of the regions
>> its flowing through. That seems pointlessly confusing and doesn't
>> make sense structurally from an HTML perspective. Why wouldn't you
>> just put the positioned object closer structurally to the place you
>> really want to position it? If that's the page or viewport, why
>> would you ever lump the content in with the flow thread content?

Well, absolute positioning is a strange beast anyway, isn't it?  Who's 
to say what uses authors might find for it.  Certainly, we can hope that 
with the introduction of new layout models it'll be increasingly 
unnecessary to abspos some part of the document relative to some other 
part a long way away.  But I don't think we should prevent authors from 
doing so.

>>>> We have two other examples to use as a guide. Printing and
>>>> columns. In the printing case, positioned objects do get
>>>> paginated.

Please could you give a concrete example of what you mean here.  Nothing 
I read in CSS21 or css3-page indicates that I can do position:absolute 
relative to the "current" page; rather, they say that the initial 
containing block is established by the first page, so presumably 
top:10px on any element in the document results in that element being 
placed on the first page.

(I'm aware that css3-positioning has the concept of position:page for 
enforcing abspos things to stay on the current page.)

>>>> In the columns case, they don't. I think of regions
>>>> as being more like printing, though, in that the author
>>>> explicitly shunted the positioned content into the flow thread,
>>>> and in my opinion by doing so, we should use a model where this
>>>> positioned content paginates by default.
>>>
>>> With printed pages, there is no other possibility, because the
>>> page does not have any ancestors. The region does (maybe even
>>> regions inside of other regions). The limitations of printed
>>> pages should not limit the increased flexibility of regions.
>>>
>>>> Otherwise we're effectively ignoring the request to put the
>>>> content into the flow thread in the first place.
>>>
>>> We're not ignoring it, we're providing an option for how the
>>> author wants the content to be positioned. Absolutely positioning
>>> elements takes them out of the flow, even without regions.
>>> Position:relative applied ancestors is a standard way for authors
>>> to decide what that abspos is relative to.
>>
>> This assumes that the regions genuinely contain the child flow
>> thread content. I think that's a dangerous assumption to make,
>> since it greatly complicates the implementation of regions.

This is a really interesting point.  How do you see all this flow stuff 
working?  I suppose I simply took it for granted that it caused 
mutations of the box tree: the principal box of a region really does 
contain the boxes generated by the elements that flow through it.  For 
you, a region box is not typically an ancestor of the boxes the flow 
associated to it?  The dimensions of the regions influence the "shape" 
of the rendered flow, but the box tree remains as if there were no 
flow-into or flow-from set?

How does this affect painting order?  If the boxes of the flow don't 
belong to the regions, you could set up something bizarre like the flow 
being hidden behind the region's background because the flow has a 
document tree ancestor which establishes a stacking context at a lower 
level than the stacking context to which the regions belong to.  To fix 
that, you'd have to modify the painting/stacking model somewhat.

>> Once
>> you begin to think of the contents of regions as being actual
>> children of the regions, then you get into this line of thinking
>> where you can pull the flow thread contents higher up in the
>> region's containing block hierarchy

I don't follow you.  Please could you elaborate.

>> That is a massive complication for implementations.

>>>> If you accept that the positioned content is respecting
>>>> pagination, then using the first region's dimensions as an ICB
>>>> (e.g., if someone says bottom:0) makes sense in that it matches
>>>> printing.

Again, where do you see such an abspos box ending up?  I see it as 
ending up 0px above the bottom of the containing block established by 
the first region, irrespective of which region the abspos box would be 
in if it weren't abspos.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Saturday, 20 October 2012 14:38:57 UTC