W3C home > Mailing lists > Public > www-style@w3.org > August 2011

RE: [css3-regions] writing mode and directionality for flows

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Wed, 17 Aug 2011 05:54:10 +0000
To: David Hyatt <hyatt@apple.com>
CC: Vincent Hardy <vhardy@adobe.com>, "www-style@w3.org CSS" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284120F0D09@TK5EX14MBXC218.redmond.corp.microsoft.com>
 From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of David Hyatt
 Sent: Monday, August 15, 2011 1:02 PM

I may be not answering exactly the questions raised, but there are complicated topics touched, I have to comment...

 On Aug 14, 2011, at 2:09 PM, Alex Mogilevsky wrote:
 > Considering that in paged media first page is the ICB, first region will be ICB too (right?), 
 > then it would be reasonable to expect that root writing mode is that of the first region element.
 I assume it would be something like that. I do wonder how fixed positioned elements placed into a flow are 
 supposed to work though. Do they get sliced up into the regions, or should we just say that -webkit-flow does not 
 apply to fixed positioned elements? I'm inclined to just say that -webkit-flow doesn't apply to fixed 

We have discussed that 'flow-into' should override 'position' or 'float', but I don't see a resolution one way or another. It would be reasonable to expect that 'flow-into' doesn't affect any element property, the element is just added to a flow and the properties are interpreted by whoever is consuming the flow. That wouldn't create any new problems that don't yet exist in layout, would it? 

 I think we may need to formalize the notion of a containing block that represents the 
 flow itself before it's sliced up into all the regions. Then the portion of that strip 
 that is placed into the first region would be the "ICB" for absolute positioned 
 descendants, etc.

Same applies to any block or box that is broken across regions or pages. The important piece here is to define how it consumes space (height) while progressing over a region. The choice is between 

	a) consume height of the region or 
	b) consume the height of content that fit into the region

I think IE does something closer to (b), need to check though. (a) is easier but it may accumulate bigger errors.

Then ICB coordinate space spreads over regions with the same rules.

Defining the root block as a "strip" is a bit tricky though. That's ok for positioning, but flowing text into variable-width regions requires tweaks for box model for highest level flow.

 Once you have a formal notion of this single "flow thread" that goes through all the 
 regions and that is itself a block, then I think some definitions become simpler/more 
 obvious. For example you can see clearly that you desire one default pagination 
 direction, i.e., one single way of making the slices in the strip, either top to bottom 
 in horizontal-tb, right to left in vertical-rl, or left to right in vertical-lr.

I tend to think about it as flow consuming space in regions, where regions provide rectangles (which don't have any direction), and the flow consumes the space based on its own direction... Same result. Is that any more intuitive?
 I also think if we're willing to give up certain features, e.g., variable width 
 paginated blocks, we could come up with simpler ways to handle variable width regions, 
 such as just supporting it on lines rather than on blocks.. for example by imagining 
 that narrower regions have synthetic floats introduced along their edges that lines 
 would avoid. This would allow you to still have the notion of a single flow thread that 
 has the same width across all regions, and lines would fit within narrower regions 
 because of these synthetic floats we put in.  Lots of stuff would still work (lines 
 would look good, text-align would work, etc.), but then some things would not, e.g., 
 expecting a block with a border to actually have different widths if paginated across a 

It should be fine to only support variable-width regions for text. It seems the hardest case though... 

Synthetic floats to make flow narrower would work if they also could make flow wider. That's just an observation.

Received on Wednesday, 17 August 2011 05:54:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:05 UTC