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

Re: [css3-regions] more feedback

From: Vincent Hardy <vhardy@adobe.com>
Date: Wed, 18 May 2011 11:37:05 -0700
To: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org CSS" <www-style@w3.org>
Message-ID: <C9F9540C.22DE%vhardy@adobe.com>
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
> whatever its type may be (inline or block), is a generic mechanism that
> 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

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

>> 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
> so that they can fit in a model where region flows and normal flow
>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); }
>    #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
> The region break defines how the flow from region to region breaks. So
> 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
> 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
> 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.
> 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
> 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

>> 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
> 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:
>    element.contentOverflow
>    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
>    element.contentFragment
>    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 ...

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

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:40 GMT