- 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