RE: [css3-regions] regions forming stacking contexts

I mentioned region styling to illustrate that there are further issues with trying to somehow connect rendering parts of one element in different regions. Oh, did you know that regions may be of different width, so parts of one element may have different width?



It seems there are some optimizations that become a problem with fragmentation, but somehow are not a problem in print preview. I don't know how Mozilla rendering works (and I don't need to know...)



As far as standards go, it talks about layout process as generating boxes, and boxes are generated separately for each region. Whatever their relative stacking is, I would expect it to be easier for a region to have a stacking context (although the opposite shouldn't be that hard either, considering what already needs to be done for z-index...)

________________________________
From: rocallahan@gmail.com [rocallahan@gmail.com] on behalf of Robert O'Callahan [robert@ocallahan.org]
Sent: Wednesday, February 01, 2012 11:00 PM
To: Brad Kemper
Cc: Alex Mogilevsky; www-style@w3.org Style
Subject: Re: [css3-regions] regions forming stacking contexts

On Thu, Feb 2, 2012 at 7:37 PM, Brad Kemper <brad.kemper@gmail.com<mailto:brad.kemper@gmail.com>> wrote:
On Feb 1, 2012, at 1:48 PM, "Robert O'Callahan" <robert@ocallahan.org<mailto: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, and in fact CSS/HTML does not allow the same document to be rendered into multiple <iframe>s at the same time.

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


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.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]