Re: [css3-regions] more feedback

(resending because of formatting error on previous send).

On May 12, 2011, at 5:24 AM, Alex Mogilevsky wrote:

> The regions draft is getting very solid, impressive!

:-)
> 
> Here is some more feedback on the spec
> 
> * Issue 1: could inline elements be regions?
> 
> I think not. But the fact that you are asking this question tells me that you may be thinking of region's ability to redirect content separately from its ability to paginate.

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. What I mean is that it acts on the set of elements that would generate boxes for a container to visually format, and that is really just acting on the 'box generator source', so to speak. It does not change the process of laying out boxes per-say.

> It is an interesting line of thought, and it creates interesting templating possibilities. I thought about it too... but I couldn't come up with any strong use cases where non-paginating regions would enable something that is not possible otherwise. Do you have any?

No, but I think that the model might be more generic if we allowed the flow/content on all elements. 

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

This said, I also understand and agree that there is a commonality between regions and blocks (and column boxes for that matter). They are all chains of areas into which content flows. So I would say that Alan is describing use cases where there there is a need for nested 'flowable area chains' and I agree. 


> 
> * 2.3: positioning recursion, rule 2 -- last container gets all remaining content
> 
> That rule must be optional (and IMO not default). It is not how pages work. If there is more content that fits on current page, it is available for next page, but it doesn't have to become overflow while next page doesn't exist...

The difference here is that pages are 'generated regions' so to speak. In the case of regions, unless we add an option to automatically generate them (and introduce a notion of 'template' or 'master'), we cannot do that. So we need to describe what happens on the last specified region and this was our proposal to address that. This said, we could have a property that drives what the behavior should be on the last region.

> 
> * Issue 3: balancing regions?
> 
> Use case is easy to see -- columns modeled with regions, possibly of unequal width (of course balancing columns of unequal width is another implementation challenge...)
> 
> I can't think of an easy way to define what set of regions need to balance though. And the use case doesn't seem strong enough.

So do you think we should drop the requirement and not have content balancing?

> 
> * Issue 4: Generating additional regions.
> 
> The most flexible way to add regions is of course script. All we need is some way to tell via DOM that there is more content in the flow. I envision a property on element that just says so.
> 
> It has been done before. That's how printing works in IE since 1999: http://msdn.microsoft.com/en-us/library/ms536941(v=VS.85).aspx (that API communicates overflow status via an event... I don't think event is the best way. I vaguely recall that we chose to use an event in IE5.5 partially with obscurity as a goal -- the implementation was not solid enough for general use; and for reasons too complicated to explain here we didn't have a chance to improve it at that time...)
> 
> Generating additional containers without script would be cool, if somebody comes up with syntax that is flexible enough, but I can't think of anything in CSS currently that would naturally extend into some kind of repeat template. Maybe it is just me but I think it is fine to use script here...

I think initially, it is a good way to start. I think your suggestion on the CSSOM View detail your thinking.
> 
> * 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.
> 
> * 3.2: "content:from(name)"
> I am sure you have considered using simply 'flow' for both creating and consuming a flow"
> 
> 	#story1 { flow:news; }
> 	#region1, #region2 { content:flow(news); }
> 
> If you did, what made you decide against it?

We did and it seemed to create confusion if you read the second line separately from the first: are #region1 and #region2 recipients of the flow (news) or are they directed their content to the 'news' flow? For someone not familiar with the spec., it might not be obvious.

> If using the exact same keyword is somewhat non-intuitive, do you think there can be a pair of keywords that are clearly related? Perhaps "to" and "from" ? Hakon has also proposed "position:flow(name)" (http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#named0)...

What about:

	#story1 { flow:news; }
	#region1, #region2 { content: from-flow(news); }

> 
> I know this has already changed a lot, I just have a feeling that there is a perfect name somewhere close...

Yes, naming is tough and so important.

> 
> * Issue 7: what does "content:from()" apply to?
> (similar to Issue 1)
> Applying it to inline doesn't make much sense. Neither does it make sense on <button> or <video> ...
> How about this:
> 	
> 	content:from() applies to non-replaced block elements
> 
> or perhaps any non-replaced elements (converting inline into inline-block first). I had an impression that we try to avoid making one property affect value of another - can somebody comment on this?

I wont comment on the last part, but I am fine with limiting the property to non-replaced block elements. 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).

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

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.

> 
> * Issue 9: random reordering of content at page boundaries sounds questionable. 
> 
> Something like that may be appropriate for advanced floats (http://www.w3.org/TR/css3-gcpm/#page-floats) -- "float: top next page unless-room;" ... that sounds like material for CSS3-Float, and I am not sure I want to comment on priority of that kind of floats (with all sarcasm in place, if complicated float placement helps to pick exactly the right size of advertisement for remaining space on page, it can quickly become a very attractive feature)

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.

> 
> * @region-style
> 

> I like the @ block syntax. Can it be just "@region"?

Yes.

> 
> Still I don't want to implement it. It will be a pain. Expect UA support to be uneven for a while...)

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?

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

> "column" properties seem to be a good candidate for addition (it is very reasonable to have different number of columns in different sized containers, even though columns can naturally adjust to available space). Otherwise it seems like a good idea to stick with whatever works on first-line.

ok.

> 
> * Issue 11: how @region-style selector works.....
> I really hope that whatever @region-style ends up doing, with any combinations of properties or document structure, it will have *precisely* same effect as if applied to big enough first-line (as long as the same set of properties is applicable). Will it?

There is a separate thread on this topic (discussion with David):

http://lists.w3.org/Archives/Public/www-style/2011May/0311.html

Do you mind commenting on the latest on that thread?

> 
> * CSS OM
> 
> We have some ideas (fairly simple) on how to expose regions and their content to DOM. Will share that shortly.

Great.

> 
> One important point to consider is that it makes more sense to access region layout results through regions than through content. For example, consider possibility of multiple views of same content (currently not defined, but feasible). One view may have overflow while another may not.

Yes, good point.

> 
> If layout results are accessed through regions, asking the last region if it has overflow is same as asking the flow if it fits in the regions. But it also adds ability to ask individual pages if they are empty (and possibility deleting unneeded empty pages).

Right,

Thanks,
Vincent.

Received on Monday, 16 May 2011 19:18:45 UTC