W3C home > Mailing lists > Public > www-style@w3.org > January 2012

RE: [css3-regions] auto widths and heights of regions

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Fri, 6 Jan 2012 06:29:04 +0000
To: Vincent Hardy <vhardy@adobe.com>, "www-style@w3.org" <www-style@w3.org>
CC: fantasai <fantasai.lists@inkedblade.net>, Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928412DCF676@TK5EX14MBXC214.redmond.corp.microsoft.com>
WRT auto sizing, I think there is a use pattern for regions that was intended in original proposals but is now underemphasized. 

A region "region-overflow:auto" can be used as the *only* region containing a named flow. Also that flow can have little content, or even a single element. Such region become a placeholder for known content.

For example a book cover can have author, title, year etc. as placeholders, carefully arranged by a designer; when the template is matched with content, it all just falls into right place. Magazine pages can use it even more.

Note that placeholders are more powerful than stylesheet. Placeholders and named flows can transcend semantic structure of document, allowing the necessary data to be picked up and shown in desired layout and order, while not having to hide everything else.

I believe Peter Sorotokin's proposal for templates does use this kind of regions.

So, if a region is the only region for a flow, it is not continued from elsewhere and it contains the whole flow, it is quite reasonable to expect that it can size itself as if it just contained the flow. Isn't it?

Current spec doesn't have different behavior for "last region" vs. "only region". For last region, issues with procession model (as explained by Rossen) still apply. Perhaps auto sizing could be allowed for the single-region case. Allowing it for last-region can in fact be a performance problem, not sure if that would be a good idea.

Alex

-----Original Message-----
From: Vincent Hardy [mailto:vhardy@adobe.com] 
Sent: Thursday, January 05, 2012 7:09 PM
To: www-style@w3.org
Cc: fantasai; Witold Baryluk
Subject: Re: [css3-regions] auto widths and heights of regions

Hello,

I will let Rossen comment further because he is the author of the document:

http://wiki.csswg.org/_media/spec/css3-regions/auto-sizing.pdf

which captures most of the discussions we had when trying to resolve the behavior for width:auto and height:auto on regions. I totally agree this is unfortunate, but this is what we worked on and resolved.

I guess we can re-open the discussion, but the conclusion at the time we worked on this was that there was no way around resolving to the intrinsic size the way it is defined in the current draft.

http://www.w3.org/Style/CSS/Tracker/actions/351

Vincent.

From:  Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date:  Tue, 27 Dec 2011 20:43:34 -0800
To:  fantasai <fantasai.lists@inkedblade.net>
Cc:  "www-style@w3.org" <www-style@w3.org>
Subject:  Re: [css3-regions] auto widths and heights of regions


>On 12-26 19:44, fantasai wrote:
>>   # 4.2.1. Auto width on regions
>>   #
>>   # If a region's Œwidth¹ property is computed to Œauto¹, its 
>>resolved value is
>>   # computed based on the region's ::before and ::after generated 
>>content only.
>>   #
>>   # 4.2.2. Auto height on regions
>>   #
>>   # If a region's Œheight¹ property is computed to Œauto¹, its 
>>resolved value is
>>   # computed based on the region's ::before and ::after generated 
>>content only.
>> 
>> Now, I wasn't there when you discussed this with Rossen, but I think 
>>this is  one of the biggest flaws with the Regions proposal as it 
>>stands today.
>> 
>> The inability to auto-size elements to their content restricts 
>>Regions to  fixed-size containers, giving up entirely the flexibility 
>>and robustness of  CSS layout, which by design is able to accommodate 
>>varying font sizes, screen  sizes, and amounts of content. By 
>>forbidding intrinsic sizing, even in the  height, you are restricting 
>>the use of Regions to fixed layout designs, which  are really 
>>considered bad practice for the Web and are not something we should  
>>be designing entire new layout systems around.
>> 
>> It should definitely be possible for the last region to have auto 
>>height. I  assume an auto-height region would just consume all the 
>>content in the flow.
>> (Which will effectively force it to be the last region, actually.) 
>>Imo it  should also be possible for an intermediary region to have 
>>auto height and a  max-height and have that work, too.
>
>+1.
>
>Not only intermediary region could have auto height, but also multiple 
>regions could have it. When you think about it, it opens lots of 
>interesting and usefull possibilities.
>
>How about similar mechanism like in columns? Regions with auto height 
>would then eat as much as needed, and will balance heights of this auto 
>regions (over min-height). This makes height computation slightly 
>harder, but makes regions extreamally flexible to support various 
>amount of content!
>
>This way even multi-columns with fixed number of columns and balanced 
>height of them, can be implemented somehow using regions. This makes 
>sense, because column in multi-column layout is sort of region, and in 
>fact we shouldn't have saprate mechanisms for them, only some syntactic 
>sugar in CSS, to generate multi-column layout using regions easier to 
>use. (Currently this is impossible not only because we do not have auto 
>height, but also because regions needs this empty psedo-elements in 
>HTML...)
>
>It will make implementation slightly more complex (determining correct 
>heights, could be hard, may even need iterative procedure, if widths of 
>all regions are different, but approximate solution based is quite 
>simple to create, and iterating few times for finding optimum should be 
>enough.
>Or maybe some sort of dynamic programming would solve this. I do not 
>know details of multi column balancing to say how it is done, hower it 
>is simpler there due to the same height and same width of each column.
>
>> If there are technical concerns with auto heights, let's solve them;
>
>+1.
>
>
>Regards,
>Witek
>
>--
>Witold Baryluk
>
>
>
>
Received on Friday, 6 January 2012 07:22:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT