RE: region intrinsic size and aspect ratio

I understand the arguments, you have good points and interesting use cases. I will have to take a little time to discuss with more people before I can agree or disagree.

Our initial view of regions was that containers of predefined size, which are filled with  a flow of content. All layout engines I've ever worked on have the same model for pagination or linked containers, it is simple, yet it never been consider limiting.

The model you are proposing involves page containers that change in size when filled with content. That brings additional issues, from circular dependencies of parent layout and content layout to potential security or privacy issues... All these issues should be solvable, I just want to be sure they are understood and it the added benefits are worth it.

I'll get back shortly, hopefully with an opinion.
Alex

From: Vincent Hardy [mailto:vhardy@adobe.com]
Sent: Tuesday, June 28, 2011 9:43 AM
To: www-style@w3.org
Cc: Edward O'Connor; Alex Mogilevsky; David Hyatt (hyatt@apple.com)
Subject: Re: region intrinsic size and aspect ratio

Hi Alex,

Thanks for bringing this up, we had internal discussions about this at Adobe recently too and I'll try to summarize where we stand.

Use cases

We expect regions sizes to be usually defined by specific width/height values. However, there are at least two cases where the region's height needs to shrink-wrap the content:

a. on the last region of a region chain, so that it can accommodate the remainder of the flow.
b. in a pull-quote, were the region should just snuggly shrink-wrap the quote vertically.

Issues with current draft terminology

The current draft, following the suggestion from David and the discussion at the face to face uses the term 'intrinsic' to describe the auto width on regions. I believe this is the incorrect terminology to use if we look at the CSS2.1 definitions:

http://www.w3.org/TR/CSS21/conform.html#defs

"In CSS 2.1 only replaced elements can come with intrinsic dimensions".

and the definition of replaced elements is:

=====

"An element whose content is outside the scope of the CSS formatting model, such as an image, embedded document, or applet. For example, the content of the HTML IMG element is often replaced by the image that its "src" attribute designates. Replaced elements often have intrinsic dimensions: an intrinsic width, an intrinsic height, and an intrinsic ratio. For example, a bitmap image has an intrinsic width and an intrinsic height specified in absolute units (from which the intrinsic ratio can obviously be determined). On the other hand, other documents may not have any intrinsic dimensions (for example, a blank HTML document).

User agents may consider a replaced element to not have any intrinsic dimensions if it is believed that those dimensions could leak sensitive information to a third party. For example, if an HTML document changed intrinsic size depending on the user's bank balance, then the UA might want to act as if that resource had no intrinsic dimensions.

The content of replaced elements is not considered in the CSS rendering model."

=====
Regions do not seem to match the CSS 2.1 definition of replaced content because their content is inside the scope of the CSS formatting model, not outside. Since intrinsic sizes apply to replaced elements and, with the current definition, CSS regions are not replaced elements, then regions do not have an intrinsic size.

Unless we redefine intrinsic size and replaced content, we need to find a different way to characterize the auto sizing of regions.

Options

a. Current definition, alternate terminology

One way forward is to update the terminology and have a paragraph that describes the way the auto value on width is resolved for regions and not call that the intrinsic width. We should have something akin to the CSS 2.1 10.3.4 ('block level replaced elements in normal flow') but with a default of 0 for the width and something akin to 10.6.7 ('auto height for block formatting context roots') for the height.

Cons: this defines a new type of auto width/height computation, specifically for regions.

b. Modify the definition of replaced content to make regions replaced content.

If we do that, then region sizing becomes a known problem and we leverage the existing CSS2.1 specification on replaced content.

Cons: there is no way to shrink-wrap vertically and we do not address the use cases mentioned above.

c. Reconsider model and determine if we need a new model to compute the region's auto width/height

The model for regions is that formatting should be equivalent to having the content segments defined in the respective regions they fall into. So:

#article {
    flow: into(article_flow);
}

#region_1, #region_2 {
    content: from(article_flow);
}

<div id="article"><span id="fits_in_region_1">...</span><span id="fits_in_region_2">...</span></div>
<div id="region_1"></div>
<div id="region_2"></div>

should produce the same visual formatting as:

<div id="region_1"><span id="fits_in_region_1"></span></div>
<div id="region_2"><span id="fits_in_region_2"></span></div>

In terms of processing, when formatting each region in turn, it is as if we were trying to fit in the remainder of the flow in each region. So to layout 'region_1', you proceed as if it had all of the flow content as a child. That will only consume 'fits_in_region_1' though. Then, to layout 'region_2', you proceed as if it had the remainder of the flow.

pro: The advantage of this approach is that it does not introduce any new special specification for region sizing.

For the example that David had in his email (http://lists.w3.org/Archives/Public/www-style/2011May/0293.html):


<div style="position:absolute;border:2px solid red;content:from(article_flow);"></div>


that would mean the auto width/height on this <div> are computed as if we had:


<div style="position:absolute;border:2px solid red"><!-- content from flow 'minus' content consumed by previous regions in flow --></div>


This is the model but an implementation does not need to layout the full flow content in most cases (e.g., when the width and height are specified).


Vincent

From: Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>>
Date: Fri, 24 Jun 2011 19:39:23 -0700
To: "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>>, "David Hyatt (hyatt@apple.com<mailto:hyatt@apple.com>)" <hyatt@apple.com<mailto:hyatt@apple.com>>, Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: Edward O'Connor <eoconnor@apple.com<mailto:eoconnor@apple.com>>
Subject: RE: region intrinsic size and aspect ratio

The answer that intrinsic width and height of a region should be zero is based on the premise that there is no intrinsic size or ratio to use (qualification - I am only talking about regions that are part of a chain of regions).

The same reasoning when applied to replaced elements (like images) led to an choice of arbitrary default size of 300x150.

I think the first question to answer here is - are regions more like regular blocks or more like replaced?

Hyatt's logic is attractive because it if a region is a regular block, same sizing logic applies to any kinds of regions (chained or not). My concern is that 0 is not a useful default.

If regions are more like replaced however, "auto" width will become 300px, which is different from normal box model, which will either mean that auto sizing is less convenient, or that the 300px default kicks in a different point in box model calculations and we'll have a new unique sizing algorithm.

Ideas? I can live with any of the above. I think I would prefer just consider linked regions just "replaced", because
                1) replaced block sizing is well defined
                2) unsized linked regions can only happen by mistake
                3) default non-zero size is more useful for fixing those mistakes

Alex

± -----Original Message-----
± From: www-style-request@w3.org<mailto:www-style-request@w3.org> [mailto:www-style-request@w3.org] On Behalf
± Of Edward O'Connor
± Sent: Friday, June 24, 2011 1:24 PM
± To: www-style@w3.org<mailto:www-style@w3.org>
± Subject: Re: region intrinsic size and aspect ratio
±
± Alex Mogilevsky wrote:
±
± > Since making something a region (setting 'flow-from') takes over the
± > element's content, it should be reasonable to expect that intrinsic
± > size of the region is calculated similar to that of a replaced element
± > or iframe. Unless of course it is a situation where region is sized to
± > content.
± >
± > That means that default region size is 300px by 150px, and if either
± > width or height is not specified it gets its respective intrinsic
± > value (because region does not have an intrinsic aspect ratio).
±
± When this came up before, Hyatt proposed[1] and Vincent agreed[2] that the
± intrinsic size of a region should be 0.
±
±
± Ted
±
± 1. http://lists.w3.org/Archives/Public/www-style/2011May/0293.html
± 2. http://lists.w3.org/Archives/Public/www-style/2011May/0302.html