- From: James Aylard <jaylard@pixelwright.com>
- Date: Thu, 29 Mar 2001 17:45:57 -0800
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "ValerieGSharp" <ValerieGSharp@netscapeonline.co.uk>, <www-style@w3.org>, "Tantek Celik" <tantek@cs.stanford.edu>
Ian, > > In that light, I propose (using inexact terminology) that the height > > of a table-cell element, if it contains only replaced inline > > elements, be based on the height of the line boxes of its content, > > and not on any inherited or presumed line-height of the cell. > > The reasons I disagree with this are four fold: > > 1. It removes the possibility to achieve the formatting that Mozilla > currently implements, and which is typographically nicer. Mozilla's approach makes sense if text (or some non-replaced inline element) is present. I don't see why my suggestion would undo Mozilla's formatting for typographic elements. > 2. The behaviour you describe can already be achieved using careful > use of the 'line-height', 'vertical-align' or 'display' properties. But many of these approaches have side-effects in other browsers that make them undesirable, or require additional and potentially more complex coding (such as extensive use of classes or ids on tds). As well, I see these approaches as being unnecessary with a common-sense table-cell implementation. > 3. Treating replaced inline elements in this manner means that the > addition of text (including ) would add whitespace where it > was not expected. ... > How would it be rendered in your model, considering you have no > reference baseline? CSS 2 section 17.5.3 [1] already addresses the baseline question: "The baseline of a cell is the baseline of the first line box in the cell. If there is no text, the baseline is the baseline of whatever object is displayed in the cell, or, if it has none, the bottom of the cell box...." And the "valign" attribute in HTML 4 [2], though far less robust than CSS's "vertical-align", provides some guidance. The introduction of white space by use of seems like a non-issue to me, because of course that is text, and the introduction of text into the cell will potentially change the behavior of the cell (isn't this how HTML tables already work?). Regarding the carriage returns between <img> elements, how are those handled presently? I believe that most browsers ignore them. Anyway, these are questions that would have to be addressed, but they don't seem insurmountable. > As I mentioned before, my interpretation of the CSS2 inline box model > allows for a backwards-compatible rendering if careful use is made of > the 'line-height' and 'vertical-align' properties. (Typically using > values of '0' and 'bottom' respectively, depending on the exact > situation.) What is the benefit of making this the only possibility? My primary concern is that this breaks with traditional UA behavior with regard to tables and images in table cells. Most developers who aren't aware of the intricacies of the box model -- and more precisely, with Mozilla's interpretation of them -- will consider the Mozilla/Netscape treatment of pixel-precise table layouts as simply buggy. You have argued that tables shouldn't be used for such layout. While that is true, to change table behavior in this way ignores the reality that they *are* used extensively for this purpose, and will continue to be for quite some time. The Mozilla interpretation thwarts designers who want to develop standards-compliant pages that are reasonably consistent across browser makes and that degrade gracefully in legacy browsers. I am not convinced that the Mozilla interpretation is correct, but only that it can be defended under rigorous questioning through citations of the CSS 2 recommendation. :) I'm not sure whether the original authors of the box model (and its implications within table cells) are available for comment and clarification of their intent -- but since we're not discussing holy writ, that might be pointless, anyway. The Mozilla interpretation seems to argue for theoretical purity (as defined by its own interpretation), whereas it seems there is room for a little more pragmatic common sense. James Aylard 1. http://www.w3.org/TR/REC-CSS2/tables.html#height-layout 2. http://www.w3.org/TR/html401/struct/tables.html#adef-valign
Received on Thursday, 29 March 2001 20:45:23 UTC