Re: [css3-regions] more feedback

Hi Alex,

On 5/18/11 1:03 PM, "Alex Mogilevsky" <alexmog@microsoft.com> wrote:

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

Ok. 
>
>How about 'region-overflow' ?

Sounds good. What about:

region-overflow: break | auto

where break would not position elements that do not fit and auto would
break if the region is not the last one and overflow if it is the last.

>
>± >> There is the "projection" media type
>
>Interesting, but I guess it should work. Both is reading on screen...

ok.

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

The classification is not meant specifically for merging content sources.
It is meant to generalize the concept of 'what' a container positions. The
'what' is a 'flow' and there are different types, a named flow being one
of them. Actually, concatenating multiple sources in a single flow is
orthogonal to that classification.

>I would expect that when an element becomes a flow source, its 'float'
>and 'position' properties are ignored.

That is not my understanding. For example:

.illustrations {
    float: left;
    flow: 'sidebar';
}

It still makes sense for the elements in the 'sidebar' flow to float into
the regions that receive the sidebar content. The current draft does not
mandate any restrictions on the flow element's float and position
properties.


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

The current draft says that elements are concatenated in document order.
>
>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.

ok, so I'll revise with:

content: from-flow(<name>);

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

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

I am happy to proceed that way.

Vincent.

Received on Friday, 20 May 2011 01:09:02 UTC