- From: James Elmore <James.Elmore@cox.net>
- Date: Mon, 09 Jul 2007 10:48:12 -0700
- To: www-style@w3.org
Rationale:
A general rule in CSS is ‘the display should be drawn in order as elements are
read from the HTML file’. The <table> element breaks this rule by allowing
elements later in the file to control the sizes of earlier elements. This is to
allow all data cells (<td> or <th> elements) in a row or column to have the same
size; otherwise it would not be a table.
Unfortunately for UA developers and CSS specification writers, this ability (to
let possible later elements control the size of earlier elements) is very useful
to designers of web sites. It has been used (and often overused) since the
<table> element was first defined. It also requires that designers use ‘table’
elements, even when all they want is to control the sizes of a set of elements.
This situation, however, does require that designers use table elements, even
when all they want is automatic control of block sizes. Table elements require
(at a minimum) row and data cell elements, which HTML provides automatically if
the user does not supply them. This means that at least three extra layers of
elements (table, tr, and td / th) are required, even if all the designer wants
is to make a few blocks the same size automatically. This is unnecessary
complexity for the user, for the HTML programmer, and for the UA (HTML and CSS
renderer).
Table elements do provide other abilities, such as simple captioning, border
overlapping, and vertical and horizontal alignment of elements in table data
cells. If the designer wants or needs these other features, using tables as
layout controls can make them available. If the designer does not want these
other features, the extra effort for designers as well as the extra work the UA
has to perform to display the features, even if the designer turns them off,
make tables an unpleasant, but only alternative to forcing element sizes
manually by the designer.
Proposal:
I propose that a new feature be added to CSS that allows users to let CSS
automatically adjust block sizes of a group of elements. This would work
similarly to table rows or columns, but would not require that the elements be
part of some other HTML elements (as tables do).
All that is necessary is for the designer to declare a group of elements and
specify that CSS needs to size them automatically. Width and height should be
separately controllable styles. There is no requirement that the blocks be in
the same row or column, only that CSS must be able to find all the elements in
the block set and determine sizes for each.
This feature could greatly simplify many web site layouts, if applied. As well,
it would provide new abilities not currently available, such as letting elements
in different parts of a web page (not in the same row or column) match sizes.
To guarantee that CSS finds all elements in a block set (so it can determine the
sizes), all the elements to be sized should be in the same class and should be
within a single named (#id) block element. The smaller the element, and the
fewer elements contained within it, the faster CSS can determine the sizes and
complete the display. (It is possible that designers may abuse this feature by
providing an #id for the <body> element and making CSS scan the entire body.
This should be discouraged, but probably can't be eliminated.) If one or more
members of the class are not within the named parent block, they may be sized
without their own sizes being considered.
According to the CSS 2.1 specification
(http://www.w3.org/TR/CSS21/tables.html#auto-table-layout), the only
requirements for automatic table layout are: the size of the parent block must
be known, and the sizes of the child elements (which are to be sized) must be
able to be determined. These requirements are met by declaring the parent (by
#id) and the child blocks (by .class id).
Right now, the only size adjustments I can foresee are setting the sized block
elements to their minimum common size or to their maximum common size. Possibly,
an average value (to set blocks to the average size between their minimum and
maximum sizes) might be added in the future, but I have no details to propose
how that might work.
The minimum size would be the smallest measurement (width or height, depending
on which is being set) of the largest member of the set. For example, if all the
elements have ‘min-width’ values set, select the largest. If some do not have
their min-width specified, determine those intrinsic widths and select the
largest out of the group of min-widths and intrinsic widths. If the calculated
minimum width would cause all the displayed elements to exceed the parent’s
size, they may either be reduced (if the elements are scalable) or the UA may
provide some way to view the elements within the parent (such as scroll bars).
Similar rules apply for minimum height.
The maximum size would be the largest measurement (again, either width or
height) of the set. Use the suggested maximum measurement (max-height or
max-width) or the intrinsic measurement (the actual height or width) of each
element and make them all match the largest. If the calculated maximum
measurement (width or height) would cause all the displayed element to exceed
the size of the containing parent, they may be scaled (if scalable) or the UA
may provide some means of viewing elements which will not fit, such as scroll bars.
To ensure that the block set does, in fact, meet the two requirements listed
above (known parent and known children), I propose the following:
.block_set_1_group { height: max(#parent_1_id); }
.block_set_2_group { width: min(#parent_2_id); }
The ‘max()’ and ‘min()’ functions would find all children with the given class
inside the parent with the given id and calculate the minimum or maximum sizes
of their heights or widths using the rules listed above, then set the height /
width of each of those elements to the calculated size.
--
James Elmore
Received on Monday, 9 July 2007 17:48:25 UTC