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

Re: Block Model Additions: Sizing Block Sets

From: James Elmore <James.Elmore@cox.net>
Date: Mon, 09 Jul 2007 10:48:12 -0700
Message-ID: <469274DC.4080902@cox.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT