- 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