RE: [css3-regions] more feedback

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


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


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

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?


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


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


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

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.

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

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

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

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

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


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


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

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

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

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

Received on Tuesday, 17 May 2011 06:22:17 UTC