Re: Stylings only possible with Tables

Raul Dias wrote:

> On Sat, 2007-06-23 at 16:24 -0700, James Elmore wrote:
> 
>>
>>Raul Dias wrote:
>>
>>>I agree with what you said.
>>>
>>>My point is that removing the phrase below from the 2.1 definition about
>>>% heights (10.5) already provides developers to acomplish this in a
>>>clean way.  Not the best way (no grouping), but a clean path to start
>>>(and the implementation is already ready for current renders).
>>>
>>>	If the height of the containing block is not specified 
>>>	explicitly (i.e., it depends on content height), and this 
>>>	element is not absolutely positioned, the value computes to 
>>>	'auto'.
>>
>>Maybe I'm not understanding, but this would only allow the content height to 
>>control the height of the containing block. 
> 
> Exactly.
> 
> 
>>If the contents of similar blocks 
>>are the same heights, the blocks would have the same heights. But, if the 
>>contents have different heights (the problem several developers have mentioned), 
>>then their heights would not match.
> 
> Sure. Thats what the CSS does now.
> 
> 
>> What seems to be requested is that 
>>developers / designers want some way to make heights / widths match, even when 
>>they are not within the same block and do not have identical content sizes.
> 
> Yes, and the reason for this (considering the same container) is the paragraph a showed before.
> So, as I said earlier, removing that phrase solves this case.
> 
> Consider this:
> <div id="parent">
>  <div id="column" style="float: left">
>    ... column content (e.g. menu) This could be random ...
>  </div>
>  <div id="content">
>    ... random content ...
>  </div>
> </div>
> 
> In this situation, the #content or #column block will dictate the
> #parent height, the heightest one will win.  The other one will be
> always shorter, unless you are extremely lucky (considering you have no
> control over content).
> 
> If the phrase I showed before from CSS21 did not exist, adding
> height:100%; to both #content and #column would solve the problem.
> 
> As you said this wont help for having blocks with the same height if
> they have different containers (parents), but is a more common situation
> where equal columns are needed.  
> 
> I have ressalted this, becasuse the implementation is probably already
> there, most complaint rendering engines when they see a "height: xx%;"
> will check to see if the parent height was explicit specified and
> fallback to "auto" is not.  All is required is to jump over this check.
> 
> Right now the ways to accomplish this:
> - CSS hacks (negative giants paddings/margins) which usually break other
> stuff.
> - Javscript.
> - Fall back to table design.
> 
> 
> -Raul Dias
> 
Thanks for the clarification, I think I understand now. If the CSS developers / 
implementors wish to consider this, I would not object. This falls short of what 
I am requesting, but is at least showing that the need is real and something 
should be done about it. A step in the right direction.

On the other hand, if something similar to my proposal were implemented, your 
example might be handled as:

style {
     .matchHeight { height: max(); }
}

 > <div id="parent">
   <!--  vvvvvvvvvvvvvvvvvv *** Change here *** -->
 >  <div class="matchHeight" id="column" style="float: left">
 >    ... column content (e.g. menu) This could be random ...
 >  </div>
   <!--  vvvvvvvvvvvvvvvvvv *** Change here *** -->
 >  <div class="matchHeight" id="content">
 >    ... random content ...
 >  </div>
 > </div>

Plus dozens or hundreds of other layouts made possible.

I'm trying to recall the reasons the original specification had that requirement 
-- there was some kind of problem where the parent height needed to be set to 
'auto' or things would not work correctly.

-- 
James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net

Received on Sunday, 24 June 2007 00:24:31 UTC