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 03:09:48 UTC