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

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

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

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.

Alex

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