Re: [css3-regions] more feedback

Hi Alex,

On 5/16/11 11:21 PM, "Alex Mogilevsky" <alexmog@microsoft.com> wrote:

>± -----Original Message-----
>± From: Vincent Hardy [mailto:vhardy@adobe.com]
>± Sent: Monday, May 16, 2011 12:18 PM
>±
>± > * Issue 1: could inline elements be regions?
>± 
>± Yes, exactly. I think the ability to direct a flow to a container
>element,
>± whatever its type may be (inline or block), is a generic mechanism that
>is
>± independent of layout or pagination in the processing order.
>
>I'll say once more that I am cautious about inline flow containers. It
>adds additional implementation challenges, such as text in one line
>coming from multiple non-contiguous sources, or even multiple documents.
>For example selection behavior can be problematic, as well as editing
>operations on container boundaries... Note that :before/:after can inject
>text inline, and they demonstrate some of these challenges (selection
>support is undefined and inconsistent).

>> We had another exchange on that and will add the suggestion you made to
>>the next revision
>>(http://lists.w3.org/Archives/Public/www-style/2011May/0375.html).

> 
>
>
>± > So for now I prefer to think about regions as always being "pages"
>± linked into a chain, which is filled from a named flow.
>± 
>± I would second what Alan said on this topic.
>
>I agree, he brings up good use cases. Let's at least make sure both
>approaches can be specified. If I want the last page to break content as
>usual (and wait for more pages to be added by script), I have to be able
>to specify that.

>> Understood. So I think that if you know that the last region overflows
>>(thanks to CSSOM View) they you can add more regions.

>
>
>± we could have a property
>± that drives what the behavior should be on the last region.
>
>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.
 
>
>BTW, what should "@media" be in paginated content on screen? I thought it
>would reasonably be "print" if containers were always like pages, but it
>looks more complicated now. Does it need new keywords for media queries?

>> There is the "projection" media type
>>(http://www.w3.org/TR/CSS21/media.html#media-types and
>>http://www.w3.org/TR/css3-mediaqueries/) which is described as:

"Intended for projected presentations, for example projectors. Please
consult the section on paged media <http://www.w3.org/TR/CSS21/page.html>
for information about formatting issues that are specific to paged media."

>> So this is clearly for paginated content shown on screen and that is
>>clearly good for our use cases. Except the name that is pre-tablet :-)

>
>
>± So do you think we should drop the requirement and not have content
>± balancing?
>
>I am strongly for not having any kind of auto balancing across multiple
>regions.

>> Ok. Noted.

>
>
>± > * Issue 4: Generating additional regions.
>± > The most flexible way to add regions is of course script.
>± 
>± I think initially, it is a good way to start. I think your suggestion on
>± the CSSOM View detail your thinking.
>
>I'm glad we agree here.

>> Yes. I'll modify the CSSOM View proposal in the next draft.

>
>
>± > * 2.4: different kinds of flows
>± > I don't understand this section at all. Can you add an example?
>± 
>± Yes, I'll add examples. This section is proposing a terminology for
>flows
>± so that they can fit in a model where region flows and normal flow
>exist.
>
>I think I am beginning to understand why the classification is there...
>Is it to define how multiple content sources are merged in a single flow?
>E.g. perhaps two multicolumn elements forming a single, uninterrupted
>multicolumn flow?

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

>
>It would help to understand what cases are really important. This can get
>complicated, it would be practical to restrict flow concatenation to a
>few simple rules.

>> Right now, the spec. proposes to concatenate in document order and have
>>all the flow elements under an anonymous block element.

>
>± > * 3.2: "content:from(name)"
>± 
>± What about:
>± 
>±     #story1 { flow:news; }
>±     #region1, #region2 { content: from-flow(news); }
>± 
>
>Could also be
>
>     #story1 { flow-to:news; }
>     #region1, #region2 { content: from-flow(news); }
>
>or
>    #story1 { flow-into:news; }
>     #region1, #region2 { from-flow:news; }
>
>(the latter is our current favorite).
>
>Once we get to longer names, using "content" seems excessive. "content"
>is there largely for readability purposes, there isn't really a "content"
>feature that helps with either spec or implementation, is there?

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

>
>± > * Issue 7: what does "content:from()" apply to?
>± 
>± I just hope we are not missing use cases
>± where it would make sense to have it apply to inline elements as well
>± (e.g, inserting a quote in a paragraph or something like that).
>
>Already covered above
>
>
>± > * 3.4: Region flow break
>± >
>± > As I said in a separate thread, until there is a clear definition of
>± "page" we can't say if region break is different from page break. My
>± thinking is that there is no need for separate type there.
>± >
>± > Are there use cases?
>± 
>± I think there are. A page break defines how the main document flow
>breaks.
>± The region break defines how the flow from region to region breaks. So
>you
>± could have regions A, B and C that fit on page 1 and region D and E that
>± fit on page 2. If nothing else is done, we would get a natural page
>break
>± after region C. If there is a page break after region B, we would find
>± only region A and B on page 1, and then C, D and E on page 2. In both
>± cases, the region flow is the same.
>
>You have an illustration of nested flow with breaks. I completely agree
>with that, and with requirement to support any depth of nested regions,
>with their own flows.

>> ok.
>
>As far as the distinction of page vs. region breaks, I am not against it,
>I just want to know what is a "page". If somebody wants to build a reader
>application with paginated view, I don't see why they would consider
>anything other than a region to represent the top level page. Then if a
>'page' is a designated region, we either need to define how that
>designation is done, or say that it is left to UA or script to
>interpret... either way not very specific.
>
>I think there are only two options here:
>    1) Provide a way to declare a region as "page region" or a flow as
>"page flow"
>    2) Not introduce region breaks

>> I'll work on a use case to help our discussion.

>
>± Now, if we do not have page breaks but a region break somewhere in the
>± middle of region B, the flow would continue on region C. But (again if
>± there are only natural page breaks), we would still see region A, B and
>C
>± fit on page 1.
>± 
>± So I think region breaks and page breaks are different because they are
>± used to break different flows, like column breaks and page breaks do.
>
>Actually your example wouldn't change at all if 'page' and 'region'
>breaks were synonyms. Each break has effect  at its level.
>
>The example would be different if you said there is a page break *inside*
>region B. You will want to keep container C empty and continue in
>container D. Right?

>> I'll defer to having a more detailed use case to respond.

>
>± > * Issue 9: random reordering of content at page boundaries sounds
>± questionable.
>± 
>± In our experience, this has turned out to be an important feature, even
>± though not for advertisement :-). It is important to create nicely
>± balanced content.
>
>Have an example?

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

>
>
>± > * @region-style
>± 
>± Well, since I think our common goal in the group is to take our specs.
>to
>± REC, I would like to work with everybody to bring the spec. to a level
>± that is in reach. May be the discussion we have with David on limiting
>the
>± amount of custom styling would make it more possible for implementors?
>
>Limiting the applicable properties is clearly a good start. There is not
>much else we can do in the spec to make implementation less painful. As
>long as we all agree that this is the proper way to define such behavior,
>it deserves to be in the spec. If it blocks getting to REC due to lack of
>implementations it can be dropped at that time... a lot can happen before
>that.


>> ok.

>
>
>± > * Issue 10: I am not sure why run-in is a good example...
>± 
>± It provides stylistic control over the way a header can interact
>± (visually) with its following paragraph. It is a purely visual thing to
>do
>± and cannot be achieved without display:run-in I believe.
>
>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.

>
>± > * Issue 11: how @region-style selector works.....
>± http://lists.w3.org/Archives/Public/www-style/2011May/0311.html
>± Do you mind commenting on the latest on that thread?
>
>Done. I think the current definition is as simple as it can be. The most
>important thing to watch for - any difference in behavior from first-line
>with same content and formatting).

>> Thanks for commenting on the other thread.
>
>± > * CSS OM
>
>We are thinking this:
>
>Property:
>    element.contentOverflow
>Values:
>    none - content ends within this container (value name is not very
>intuitive -- better ideas?)
>    underflow - content ends before this container
>    overflow - content ends after this container
>
>Property:
>    element.contentFragment
>Return:
>    DOMRange (actually it needs to be a collection of ranges, best return
>type TBD)
>
>These two properties should be sufficient to determine what is in what
>container, what containers are empty and whether there is need for
>additional containers in the end.
>
>Also, it may be helpful to have an event to indicate that region layout
>has changed (or that value of either of the above properties is
>different). "onlayoutchanged" maybe. Technically it is not necessary for
>repeated updates but it may help to make as few updates as needed.
>
>Also, it may be desirable to locate region (or regions) showing fragments
>of an element. If such API is included it should be multi-view friendly.

>> I think this is a great proposal and will add that to the draft.


>
>... this is all I have for now ...

Thanks!
Vincent

Received on Wednesday, 18 May 2011 18:37:33 UTC