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

Sorry to be so late in coming back to this.

On 08/02/2012 17:52, Brad Kemper wrote:
> On Feb 8, 2012, at 1:28 AM, Alex Mogilevsky wrote:
>> On Tuesday, February 07, 2012 6:34 PM, Brad Kemper wrote:
>>> On 03/02/2012 14:11, Vincent Hardy wrote:
>>>> The edges of the first CSS region in a region chain associated with a
>>>> named flow establish the rectangle that is the containing block used
>>>> for absolutely positioned elements in the named flow which do not have
>>>> an ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’  (see
>>>> [CSS21]). That first CSS region rectangle is used as thecontaining
>>>> block instead of the initial containing block.
>>> What it the purpose of this restriction? If authors wants that
>>> behavior, they can just set 'position:relative' on the first
>>> block. Why must it be prescribed as a containing block?
>> Set position:relative on first region or root element of named flow?
>> Both may work sometimes but not quite.
>> If first region is position:relative and it is the nearest
>> positioned ancestor of absolute positioned element in named flow,
>> positioned content will be literally relative to the first region,
>> not in the fragmented flow.
> That is what I would also expect if the first region was the ICB.

I agree with Brad.  As far as I can tell the same thing is true under 
the currently-specified rules (in which the first region establishes the 
containing block for abspos flow children).

But I think I understand what you're wishing for, Alex.  You want to be 
able to abspos a box that sits in a named flow to position it *relative 
to the top of the flow itself* but somehow following the progress of the 
flow.  For example, in the case of a region chain consisting of one 
sufficiently-large region, the abspos specified using top:1000px would 
physically be 1000px below the top of the region, but if instead there 
were two regions, the first being 750px high, then the abspos box would 
be physically 250px below the top of the second region.

Is this what you expect to happen in the page model?  I don't see any 
indication of that behaviour.  In fact, I'm not aware of this model of 
abspos being used anywhere at all.

If this model were to be adopted, it's not as simple as defining what is 
the containing block of what.  The model would need a clearer definition 
involving some metric which measures the progress of the flow.

> I had meant that the author could set position:relative on first
> region, instead of the first region being the ICB. It seems like that
> would amount to the same effect, except that it wouldn't be mandatory
> (the author could leave the first region as static, and the HTML
> element would remain the true root.

Yes. I don't see why I have to have it forced upon me that my abspos'ing 
can't escape the region chain framework.  I think it's perfectly 
reasonable to want to abspos relative to something exterior to that 

>> Something positioned at "top:<first-region-height>" will be under
>> the first region, not in second region (assuming that is what would
>> happen in paged media -- defining that precisely is a separate
>> issue).
> Granted, it doesn't seem that useful to do it that way. But if it was
> left up to the author, then the author could set all the regions to
> position:relative, and then the abs-pos item would be positioned
> within whatever block it ended up in (or that it's placeholder ended
> up in, actually).

Yes, this is how I imagine it behaving too.  [Of course, it would also 
be nice to be able to opt out of this – and not just in the context of 
regions.  Because of the messy way that the positioning model centres on 
relpos boxes, your abspos'ing origin can be hijacked by an ancestor 
whose position is relpos for reasons distinct from wanting to establish 
the containing block for its positioned children.  There have been 
proposals in the past to be able to explicitly specify which box should 
establish the containing block of an abspos, eg via "named elements".]

So the question becomes – as Brad says – what's so special about the 
first region that we feel it should be an eligible containing 
block–establishing box yet none of the other regions in the region chain 
should inherently be so?  Perhaps I'm missing something, but it seems 
that either no region should inherently be so or else all should.  I 
prefer the former possibility, because relpos (or some future mechanism 
such as the one I described above) can always be used to opt in.

Anton Prowse

Received on Saturday, 20 October 2012 14:28:17 UTC