[css3-regions] more feedback

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

So for now I prefer to think about regions as always being "pages" linked into a chain, which is filled from a named flow.

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

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

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

* 2.4: different kinds of flows
I don't understand this section at all. Can you add an example?

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

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

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


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

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

* @region-style

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

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

* Issue 10: I am not sure why run-in is a good example... "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.

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

* CSS OM

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

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.

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

/Alex

Received on Thursday, 12 May 2011 12:31:43 UTC