Re: [css3-regions] Feedback on regions document

On May 11, 2011, at 12:45 PM, Vincent Hardy wrote:

> I understand that region styling is an implementation challenge.

I admit that this is mostly an implementation concern and not a philosophical objection to the feature itself.  first-line is already a bit of a nightmare, and it's way simpler than this.  Having both block and line objects changing style during layout as a result of pagination is going to be really complex as well.  In terms of incremental line layout for example (imagine typing somewhere in region #1 of 50 and having to figure out if the styles of lines and blocks are changing as you push objects to subsequent regions).

There are also situations that are ambiguous.  What happens with an object like <div style="height:10em"> for example if it splits across two regions?  Which font are you going to use to determine the size of the div if the two regions give the div a different font in each?

I just want to make sure before we incorporate a feature like this into a draft that we're aware of just how heavily it will impact implementations.  If you ignore this feature, regions are largely self-contained as far as how they would impact an engine implementation.  If you incorporate region styling into the mix though, then the feature is going to introduce complexity into all core layout paths (blocks, flexboxes, tables, etc.) unless we limit it to lines.  That concerns me.

Assuming we limit the set of applicable properties to the same set as first-line and if we limit the feature to line styling, then the only thing you give up is the ability to have distinct background colors and background images per-region for a block level element.   I'd argue that could even mostly be handled if we allow the regions to render their own backgrounds behind the content that flows into the region.

You'd still be able to control fonts, colors, etc. on all of the lines inside a block element.  All of the examples you use in the current draft would work just fine (with the exception of the one that changes display/border/padding, but those aren't applicable first-line properties).

> 
>> 
>> (2) My second major issue with the document is that I don't believe we should ever allow regions to be explicit DOM elements.  I think regions should always be created anonymously.  The examples for positioned elements and flexible boxes are just clumsy.
>> 
>> <div id="article">...</div>
>>       <div id="region_A"></div>
>>       <div id="region_1"></div>
>>       <div id="region_2"></div>
>>       <div id="region_3"></div>
>>       <div id="region_4"></div>
>> 
>> In this example you define both your real content in the article div, but then you make a bunch of sibling positioned divs that are purely presentational.  
> 
> What the draft tries to convey is that the issue of positioning regions is orthogonal to the issue of flowing content from one region to another. It also expresses what is the requirement for a region to be a possible target for flowing content. So the spec. tries to be agnostic in the way regions get created and was trying to illustrate options.
> 

Right.  I think it's good that it is agnostic regarding how regions are positioned.  I am simply arguing that it's always going to be bad form to have your regions explicitly defined in the DOM.  The whole reason properties like grid-template are being introduced is because we recognize that there's a problem of "presentational divs" polluting documents.  If regions work with the DOM by default, then this will become the de facto way people create them.  It seems harmful to allow this to even happen when we have an opportunity here to get things right the first time.

Multi-column layout is a great example of implicit regions done "the right way."  No presentational divs are required to split a div up into columns.  Why would we allow that to happen just because the region positioning gets a little more complex?  We should be following the multi-column model for all region creation, relying on properties like grid-template, column-width/count (and IMO positioned-regions) to generate these regions via CSS.

> 1. positioning of container elements that can be the recipients of named flows. In other words, positioning regions. The proposed spec. does not address this. It tries to integrate with existing or upcoming layout schemes. In that light, positioned div are an existing solution. Not my favorite one, but it does exist.

I'm arguing that content: from(<name); should be restricted and not applicable to any block element.  That's all.  I think it should be restricted to ::grid-cell, to a multi-column selector (::nth-column) if we choose to introduce one, and to some form of positioning syntax (either implied by a positioned-regions property or specified on a ::region pseudo-element).

> - Binding the flow and positioned-regions on the same element makes it that either we have to limit the named flow to a single element or we have to explain what happens in situations like:
> 
> #article {
>    flow: article_flow;
>    positioned-regions: region_A, region_B;
> }
> 
> #article_2 {
>   flow: article_flow;
>   positioned-regions; region_A, region_C;
> }
> 
> The two articles are in the same flow but directed to different sets of regions.
> 

Yeah, ok, I see the problem.


> - The issue of creating new containing blocks from CSS syntax seems to be more generic than what we do in regions. For example, I think a cell in a grid layout is a similar concept. Shouldn't we address this more generically, as in a 'slots' specification instead of creating a solution specific to CSS Regions?
> 

Yes, I think we should.  The question is whether regions should be allowed on DOM elements before such a mechanism exists.  My concern is that if we allow this, it will be the dominant way to define regions, and if a more generic slot mechanism comes along later, it will be too late.

One thing that's very unclear to me is how regions are sized.  I am not convinced that this can be hand-waved away as some other spec's problem.  For example, if a positioned element that is acting as a region has no height or width specified, how wide is it?  How tall is it?  What is the intrinsic width of such an element?  I see the same issue occurring for grid-cells or flex-boxes as well.  Unless you fix the width of the region prior to flowing content into it, there are a lot of layout questions to answer.

dave
(hyatt@apple.com)

Received on Wednesday, 11 May 2011 20:08:53 UTC