- From: James Elmore <James.Elmore@cox.net>
- Date: Fri, 22 Jun 2007 15:53:49 -0700
- 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