Re: [css3-regions] Feedback on regions document

Hi David,

On May 11, 2011, at 1:07 PM, David Hyatt wrote:

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

Yes, and if I try to generalize what you are pointing out, the question is: what is the computed value for an element that spans over multiple regions? (since in your example, we need a computed font-size value to compute the height property). I think this is a similar (same) issue as pointed out in Issue 11 because in boils down to having selectors that match a 'portion' of an element and therefore, different 'portions' of an element have different computed style. Unlike ::first-line, we cannot really model this with a child pseudo element because splits can straddle elements.

So I admit I do not have a good answer for this yet and I think it is the same issue pointed out in Issue 11: how do we describe matching portions of elements?

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

Yes, I realize the impact is significant. 

> 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

This is the standing proposal in the draft, so I think we are on the same page here. As I mentioned in my previous response, the current draft limits the properties to those applicable to first-line and raise an issue asking if that is enough. 

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

Yes, I agree.
> 
> 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).

Yes. So would you be ok with the proposed syntax and my request in the previous email that we still be able to select on elements inside a region?


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

Ah, ok. So you want a more 'guided' solution than what the current draft proposes. I do not have strong feelings about this, except that if we go that route, we should also have a way to do absolute positioning on blocks created through CSS because I think there are use cases that would be hard to achieve with multi-col and grid layout.
> 
>> - 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.

My hope was that by the time CSS Regions are available, we would have multi-col and grid layout widely implemented too and that it would be the default people would turn to. We could also guide/recommend that in the spec. The use of DOM elements would be restricted. 

Now, I assume you envision a way to use multicol, for example, combined with a ::before or something, to totally exclude the use of DOM elements, right?

For example:

<style>

#article {
       flow: "article_flow";
}

body::before {
	display: grid:
	grid-template: "abd"
                                  "acd";
	content: from(article_flow);
}

</style>

<body>
      <div id="article">...</div>
</body>

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

We actually thought about this, and we tried to express it in the spec., but it is done a bit indirectly (in the section about how flow breaking rules (2.3). A container block that does not have a width/height set would behave like any normal container block that flows its normal content. In other words, it would possibly consume all the flow because it would not ever overflow.

So if we had the "article_flow" flow through region A and region B, and region A did not have a width/height set, then it would be able to fit all the boxes in the flow and content would never reach region be. It would behave as if we had had:

<div id="region_A">
	<div id="article">..</div>
</div>

Does that answer your question?

Cheers,
Vincent

Received on Thursday, 12 May 2011 02:00:26 UTC