Re: [css3-regions] Feedback on regions document

Hi David,

On May 11, 2011, at 9:13 AM, David Hyatt wrote:

> Overall I like the direction of this document.  

:-)

> I have two major issues with it.
> 
> (1) The @region-style feature is going to be an implementation nightmare, and I'm not convinced that it is necessary.  


> I think the objects that you'd style differently would typically be known to fit fully in the first region anyway.

In our prototypes and examples, in particular when dealing with multiple orientations and screen sizes, we found that content may not always land where expected. I agree that sometimes there are elements that you would know to fully fit in a given region, but there are cases where, for example, headings or paragraphs may fall into different regions that cannot be easily predicted. 

An example would be a layout of columns with different colors and background. For example, imagine a case where you have alternating white and black columns with text that should be white in black columns and black in white columns. Depending on the width and height of the columns (supposing they are fitted to the screen size for example), more or less content will fill in the columns and it is not possible to know ahead of time which segments of the content will flow into any given column.

> 
> If this feature absolutely must exist, then let's at least limit it to lines.  Browsers have already largely dealt with the consequences of having lines with different styles.
> 
> So instead of
> 
> @region-style <region1_sel> {
>    #article {
>        font-weight: bold;
>        color: #0C3D5F;
>        font-size: larger;
>    }
> }
> 
> I would suggest writing it like:
> 
> #article::region-line(<region1_sel>)
> {
>    font-weight: bold;
>    color: #0C3D5F;
>    font-size: larger;
> }
> 
> This still allows you some nice styling flexibility, and it's forward-compatible in the sense that we can tie it to first-line and just say it works the same way.  It's significantly easier to implement, especially in engines like WebKit that don't waste memory representing split blocks with multiple boxes.

I understand that region styling is an implementation challenge. The current draft actually proposes to limit the number of properties applicable to the same on ::first-line, which is consistent with what you are asking for. There is an issue (Issue 10) asking if the list is too limiting (I guess you answer is no on this question :-) and the examples use more properties, as noted in issue 10. 

So apart from the issue 10 and additional properties in the example, I think the spec. actually has the limitation that you are asking for in terms of applicable properties. 

Regarding the selector syntax, I was suggesting the syntax in the spec. so that we could a) extend the set of applicable properties later and b) apply different properties to different elements in the region. In the spec. example, <h1> color is changed to 'crimson' and <p> text is changed to dark blue when flowing in region_1. If we could only set the region-line properties, then we do not have the flexibility of changing the properties of various elements differently.


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

I understand the preference you express (which I share), but I think we are talking about two different issues:

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.
2. flowing content into regions. This is the primary purpose of the draft.


> What you really want (and I mentioned this in a previous email to the list) is the ability to create anonymous positioned regions.  

> I think a new property is perfect for this.
> 
> #article {
>   flow: article_flow;
>   positioned-regions: region_A, region_B, region_3, region_4;
> }
> 
> You wouldn't need to explicitly specify content: from(article_flow), since the regions are obviously created to hold article_flow content.
> 
> Then each region could be individually referenced using its name with a region pseudo-element (I'm assuming region is replacing the term slot).
> 
> #article::region(region_A) { ... }

We considered something close to this and tried to generalize slots. Here is why we settled on the proposal we are making:

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

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

> 
> I would just cut the flexible box example.  

Sure. The example was there just for illustration purposes. If it does not help, it can/should be taken out.

> I don't think we *have* to make regions compatible with every last layout system we devise,

To the earlier point, the idea is that the issue of positioning regions is something that should be done by existing/upcoming CSS layout schemes. If the target of these layout schemes should be CSS generated boxes, then may be that should be the purpose of a generic 'slot' mechanism in CSS. The draft is written with that mind-set.

So if we do not make it a goal to be compatible with every layout system, then we do not need to fulfill the integration requirements for each.

> especially if that means forcing authors to throw in presentational divs just to represent the regions.  

I do not think the proposal forces authors to use presentational divs. The examples show how it could work with multi-column and grid layout (if we provide a way to get addressable regions from these layouts) which do not require presentational divs. So there are options and I do not think authors are forced one way over the other.

> If regions can work anonymously with grids, multi-column and positioned elements, that gives authors more than enough options.

I agree that it gives options. I think it would be nice to separate out the different issues that are at play too.

Again, thanks for your feedback. 
Cheers,
Vincent.

Received on Wednesday, 11 May 2011 17:46:00 UTC