W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Stylings only possible with Tables

From: James Elmore <James.Elmore@cox.net>
Date: Fri, 22 Jun 2007 15:53:49 -0700
Message-ID: <467C52FD.1000401@cox.net>
To: www-style@w3.org

I'll try and keep this post short. If there is interest in any of my 
suggestions, I can provide more extensive thoughts later.

RATIONALE FOR CHANGES: Many stylings are only possible using tables, or require 
combinations of tables and other (X)HTML elements to achieve. This is in direct 
opposition to the stated intent of CSS and (X)HTML, which (as I understand) is 
to separate the style (format) from the content (data). To provide greater 
control of styles and to separate styling from data, I propose the following 
additions/modification to CSS.

1. Allow a CAPTION for block elements. (Not strictly CSS, but I'm not subscribed 
to the HTML list. Also has CSS ramifications.) I see dozens of possible uses.

2. Allow designer control over margin collapsing. (Discussed earlier this week.)

3. Allow designer control over Border Overlap. (Similar to margin collapsing.) 
This could include border overlap between *parents and *children, to allow 
table-like control of borders for non-table elements.

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.

5. Design new display-models to assist (simplify) layout of web pages. 
Currently, designers must place elements in a flow, a table, or stack (blocks) 
vertically. I would like to open discussion with:
     normal expected inline/block behavior
     ruby   expected ruby behavior
     table  expected table behavior
     flow   all elements, block or inline, would fill in the flow direction
     list   horizontal or vertical stacking of block elements
     grid   simpler than a table; C cols by R rows, where elements are placed
     stack  Z-order: one element is visible at a time; UA provides e.g. tabs?
     tile   non-rectangular elements; may fill non-rectangular areas as well

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.

James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net
Received on Friday, 22 June 2007 22:53:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:29 UTC