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

Re: [css3-regions] regions forming stacking contexts

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 2 Feb 2012 07:25:49 -0800
Message-Id: <3B4AD0EA-9D00-45FE-A0F0-B2CDB30C841A@gmail.com>
Cc: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org Style" <www-style@w3.org>
To: "robert@ocallahan.org" <robert@ocallahan.org>
On Feb 1, 2012, at 11:00 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:

> On Thu, Feb 2, 2012 at 7:37 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Feb 1, 2012, at 1:48 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:
>> It might be possible to address the problem by somehow saying that each region renders an independent copy of the content flowed into the region. Then an element that's a stack context but split across regions would split into stacking contexts within each region. Or something like that.
> I imagine it a bit like two iframes of possibly different sizes scrolled to different points of the same document.
> That's not very accurate since <iframe>s always clip their contents,

Not "very". "A bit like" is what I said.

> and in fact CSS/HTML does not allow the same document to be rendered into multiple <iframe>s at the same time.

Huh. I did not know that. It seems like an odd restriction. I can have the same document in multiple windows.  

> On reflection, the model of treating the content in each region as a completely independent copy, rendering them independently, and then slicing them up will lead to some bad results.

OK, forget iframes. What I was describing, in the part where I was talking about negative margins, was that a region would determine what content would be pushed to a subsequent region (as pages and columns do already), but that the second region would then not determine _anything_ about the first region. Overflow along the top of the second region would be as per any element, but most content would not overflow the bottom, as that gets pushed to the next (third) region.

> For example, suppose we have two regions R1 and R2, into which we flow a series of atomic elements E1, E2 etc each with a large 'outline'. If elements E1 to Ek fit into R1, I don't think you want to see the bottom of Ek's outline rendered at the top of R2. (That's what you would get with your <iframe> model too.) If E1 completely fits into R1, then its outline should only appear in and around R1.

Agreed (aside from my loose analogy with iframes not intending to go that far). Outlines and shadows would just stick out in one place only, just like if they were at the bottom of some mundane non-region DIV. Abs-pos descendants of things that _do_ fit in the region) would just obey normal overflow rules for that region, I'd think, as would replaced elements. Isn't that how columns work?
>> How's that? Are we allowing per-region styling of the flowed content now? That has all kinds of issues of its own :-).
> I think it always has, and that was a big part of the appeal for creating magazine-like layouts. See figure 2 and section 1.2 in the editors draft, for instance[1], where it says, "Region styling allows content to be styled depending on the region it flows into".  Section 4.5 goes into more detail, with "Only a limited list of properties can be set in a region style rule", which are listed there.
> That's a relief.
> My biggest immediate worries about that list are backgrounds and borders. Defining the background positioning and painting areas is tricky when the background style of an element can vary along the element.

Is it worse than having the width change from one printed page to the next?

I'd think that if, say, a second region starts with half an element in a previous region, then you'd determine background-position by imagining that the missing top of the box had the same styling as the bottom. Unless you had 'box-decoration-break: clone'. 
Received on Thursday, 2 February 2012 15:26:21 UTC

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