Re: [css3-regions] Auto-generation (issue 15186)

On 11/10/2012 21:43, Alan Stearns wrote:
> Issue 15186 [1] in CSS Regions contains this concern:
>
> ---
> If the content poured into the regions take up more space than the
> fixed set of regions can hold, no additional regions will be generated
> automatically.
> ---
>
> I agree that auto-generation of boxes is very useful in many
> circumstances, and I support auto-generation in the multicol,
> page-templates and overflow proposals. But I am going to argue that the
> CSS Regions module does not require auto-generation, for the same reason
> that regular elements do not *require* auto-generation of additional boxes
> to contain their overflow.
>
> When you style a div and its contents in CSS, overflow can happen. There
> are methods for dealing with  overflow. One is to specify height as auto,
> to allow the container to size to its contents. If the height of the
> container must be constrained, you can turn on a scrollbar or (in the
> future) use the proposed overflow:fragments mechanism.
>
> Exactly the same methods are available to region chains. For the simplest
> case of a region chain consisting of a single CSS Region, the situation is
> exactly the same as the div above. You can specify the region's height as
> auto, give it a scrollbar, or use any other available method for dealing
> with overflow. The region can respond to the named flow contents in just
> the same way a normal div responds to its own contents. In considering
> more complicated region chains, it can be useful to begin at the end of
> the region chain and work backwards. If you add one or more regions to the
> beginning of the simplest region chain, nothing has changed. The last
> region in the chain still has all of the normal overflow solutions
> available for the fragment it contains.
>
> So contrary to the concerns in the issue, the draft as it stands can
> handle unexpected changes in content, font usage or user styles in a fixed
> set of regions - in exactly the same way that normal elements handle such
> differences. And by hooking in to the basic workings of CSS in this way,
> region chains can take advantage of new mechanisms such as
> overflow:fragments that are invented. So regions will be compatible with
> future auto-generation mechanisms (such as what's proposed in page
> templates), but it's not required to define an auto-generation mechanism
> in the CSS Regions module itself. The concerns in this issue can be
> addressed by using the methods for dealing with overflow that already
> exist.
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15186

FWIW I agree with this approach.  It seems to me that it's the 
responsibility of the last region in a region chain to figure out what 
to do with too much content, and that has nothing to do with the fact 
that it's a region specifically.

But this does make me wonder what the relationship is between that 
aspect of the model and the aspect raised by Dave Hyatt (quoted and 
discussed near the bottom of [1]) in which regions don't actually 
contain the flow that flows through them.  At the very least, the 
regions spec needs to use clever wording to say that despite the flow 
not being contained by the regions, the flow should be thought of as 
being contained by the regions for the purposes of interpreting other 
specs ('overflow', page templates, multicol etc) which will undoubtedly 
be written with the editorial expectation that content is contained 
rather than merely conducted somehow.

[1] http://lists.w3.org/Archives/Public/www-style/2012Oct/0565.html

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 28 October 2012 08:56:14 UTC