W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-regions] regions forming stacking contexts

From: Vincent Hardy <vhardy@adobe.com>
Date: Fri, 3 Feb 2012 09:24:00 -0800
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <D2D51CD4-1661-4509-BF52-EFC255897DB8@adobe.com>

On Feb 3, 2012, at 5:29 PM, Boris Zbarsky wrote:

> On 2/3/12 2:35 AM, Vincent Hardy wrote:
>>> Do you get a 20px tall yellow box in the first region and an 80px tall
>>> yellow box in the second one? Or just a 20px tall one in the first
>>> region? Or something else?
>> You would get 20px in the first region and 80px in the second one.
>> This is the same behavior as what happens when printing an
>> absolutely positioned box.
> That's not the behavior when printing in all UAs, and the printing spec 
> doesn't actually clearly define this to be the behavior.

[vh] On the simple test I made, I saw the same result in FF and WK, and a different one in Opera (which only printed the first page). May be I tested something too simple. Here is what I tried:

    <title>Print and absolute positioning</title>


    <span style="position:absolute;width:50%;height:40cm;background:yellow;border:1px solid black"></span>

>> This falls out of the section 4.1 in the regions spec. stating that
>> the ICB is the first region's box.
> Except it doesn't.  Knowing what the ICB is says nothing about what 
> happens at a page boundary.

[vh] I see your point, I was making a leap. Breaking between region is happening like it does between pages which is why I was coming to that conclusion. 

>>> What are the widths if the two regions have
>>> different widths?
>> In this case, the computed style on the box width is 100% which can
>> only be resolved to a used value at layout time.
> Where is that defined?  I'd think that the width of the box would just 
> be based on its containing block, as usual, which in this case is the 
> ICB, which is the first region.
> If that's _not_ what happens, then some spec-work is needed to make that 
> clear, because right now the spec says the width should not change as 
> far as I can see.

[vh] I think you are right, spec. work is needed here, because the actual values, especially for width, requires using the current regions width. I created a bug to make sure it gets added to the spec:


Received on Friday, 3 February 2012 17:24:54 UTC

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