RE: [css3-regions] more feedback

± From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
± Of Vincent Hardy
± Sent: Wednesday, May 18, 2011 11:37 AM
± 
± >What could it be called? "content-overflow:normal|paginate|auto"?
± >Or perhaps "content-media:screen|print"? (probably not media)
± 
± >> I was thinking of adding a 'break' value to the 'overflow' value,
± >>which means that the container does not position elements in the
± >>normal flow that do not fit in its own box.

I believe the relationship of 'overflow' and pagination was discussed here before (not sure how to find the thread though), and the conclusion was that it is best not to take over 'overflow' property, because if a particular page or region may not fit in its viewport it is reasonable to provide a way to scroll it.

How about 'region-overflow' ?

± >> There is the "projection" media type

Interesting, but I guess it should work. Both is reading on screen...

± >± > * 2.4: different kinds of flows
± >± > I don't understand this section at all. Can you add an example?
± 
± >> The initial intent is to articulate the relations between a
± >>container, the set of elements it positions and the layout scheme it
± >>uses. This is important because these relations can be implicit in
± >>CSS, prior to CSS Regions which makes it possible to act on which set
± >>of elements a given container positions.

I guess I still don't understand why merging content sources requires a classification of flows. I would expect that when an element becomes a flow source, its 'float' and 'position' properties are ignored. Multicolumn could be special if they are concatenated with special rules, but I am not sure if it is being proposed. And generated content shouldn't be special anywhere.

Or am I missing something?

± >> 'content' does help legibility, but we also worked to provide a
± >>consistent model for all the different flows (e.g., generated content,
± >>absolute positioning) so my preference would be to stick to the
± >>proposal and adjust the 'flow: <>' syntax.

OK. 

± >± > * Issue 9: random reordering of content at page boundaries sounds ±
± >questionable.
± 
± >> Yes. If you have a page that is filled 2/3 with text and then is not
± >>able to fit a table. It would be nice to be able to fill in more text
± >>and just have the table on the next page. This is usually better than
± >>having a big gap or breaking the table.

This should be doable by making the table a float. If currently defined float types can't do it we should consider more. GCPM floats most certainly can.

± >If really desirable, it will work, as long as it is defined what
± >happens when values are different across a page break.
± 
± >> If we add the further constraint I proposed (that elements only match
± >>if they are fully in a region), I think that would be taken care of.

Does "fully within a region" really help? Does that mean "fully within a region with that region's style"? But we don't know if the element will fit until we try to fit it, and if we fail we have to go back and recalculate everything that it could affect (most likely the whole region). And we may have to do this multiple times if multiple elements don't fit...

I think we'll want to see implementations without these restrictions first, and then add restrictions for known problems...

Alex

Received on Wednesday, 18 May 2011 20:03:40 UTC