Re: Stylings only possible with Tables

Jens Meiert wrote:
>>1. Allow a CAPTION for block elements. (Not strictly CSS, but I'm not
>>subscribed to the HTML list.
> 
> 
> * http://lists.w3.org/Archives/Public/www-html/
> * http://lists.w3.org/Archives/Public/public-html/ (HTML WG)
>
It appears that the HTML5 spec has a proposal to add 'legend' to a few block 
types and limit what can/should be done with it, including requiring the AU to 
display a legend when the designer does not define one. I propose the addition 
of 'caption' (the exact names don't bother me, although caption seems clearer 
than legend) to most / all block elements. If a designer wants a text string 
attached to an element and displayed next to it, the element itself (if it is a 
block) or the innermost containing block could have a caption. No new element 
types need to be defined. No new programming needed in the UA, simply allow the 
<caption> to be displayed for other (block) elements than table.

> 
>>2. Allow designer control over margin collapsing. (Discussed earlier
>>this week.)
> 
> 
> Interesting point. Though I missed the mentioned discussion, I'm not sure if a new property would really make things easier: Is it harder to understand the "collapsing margins" rules [1] or (presumably) three new properties (including a shorthand property) with three new values, like for example
> 
>   margin-collapse: standard|none|inherit
>   margin-collapse-top: standard|none|inherit
>   margin-collapse-bottom: standard|none|inherit
> 
> Would that be helpful? What does it mean for implementations, too?
>
My post about collapsing margins is at: 
http://lists.w3.org/Archives/Public/www-style/2007Jun/0095.html

Several people have expressed interest in allowing control over collapsing 
margins. The current specification REQUIRES collapsing margins vertically and 
PROHIBITS collapsing them horizontally. If this behavior is not what the 
designer wishes, he/she must adjust the margins (e.g., double them vertically or 
halve them horizontally). My proposal was to allow designer control over margin 
collapse: standard/normal behavior; plus no collapse, collapse to minimum size, 
collapse to maximum size. There was even discussion about the possibility of 
collapsing margins completely (turn them off).

As to what this means for implementations, I'm not sure. The current standard 
seems to work fairly well, but there is interest in better designer control. 
Since all (conforming) UAs already collapse margins, modifying the code to use a 
variety of collapsing behaviors means (to me) checking a variable and adding a 
switch/case statement to handle the different behaviors.

> 
>>4. Allow designers to constrain the height/width of sets of blocks.
>>Tables keep all cells in a row the same height and all cells in a
>>column the same width. The table control may even override the
>>designer-set values, based on the width of the table and the contents
>>of the cells. This can (currently) only be done in tables. Several
>>designers have requested a means to perform this magic outside 
>>of tables. If properly specified and implemented, this does not even
>>need to limit cells to a common row or column.
> 
> 
> You can achieve "table-like" visualization (including same height) with the "display" property, for example
> 
>   <div />
>   <div />
> 
>   div { display: table-cell; }
> 
> Also, the cascade [2] "already" defines what declarations are applied (unless I misunderstand "may even override the designer-set values").
>
What I meant was that the table layout algorithms may override the designer-set 
values (for width and height). My suggestion is not that we need better tables, 
or that we should declare display types to be table-cell, but that designers 
would like to have a group (set, collection, etc.) of blocks, possibly not 
related in any other way (including not in the same column/row, not even in a 
table) and apply similar algorithms to make them the same size, based on their 
contents. This ability is only available within a table element and would be 
useful in other layouts.

> 
>>I'm waiting for the screams -- "We've never done it that way before!"
>>I have more thoughts about use cases, standards, and implementation,
>>if any of the above interest anybody.
> 
> 
> Great.
> 
> 
> [1] http://www.w3.org/TR/CSS21/box.html#collapsing-margins
> [2] http://www.w3.org/TR/CSS21/cascade.html#cascade
> 

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

Received on Saturday, 23 June 2007 17:46:56 UTC