- From: Matthew Brealey <thelawnet@yahoo.com>
- Date: Wed, 09 Feb 2000 14:43:12 -0800
- To: www-style@w3.org
- Message-ID: <38A1ED80.6555@yahoo.com>
The spec doesn't seem to define how tables interact with the box model. For example, if we have {margin: 0 25%}, the result is a width of 50% from the non-replaced block model equation, but clearly this doesn't work because that would serve to increase the width of the table beyond MCW, which isn't intended at all. Given that the non-replaced box model can't be used, the following doesn't seem to be defined: TABLE {margin-left: 120%} Now to remove the uncertainty (i.e., because to get this to fit the containing block, a negative margin is required, but because the box model equation doesn't work on tables, we can't use it), the status of margins needs to be defined. I would propose: 10.3.5 Tables in normal flow If 'left' or 'right' are 'auto', their computed value is 0. Width is determined by the browser's table width (or by the fixed layout algorithm when table-layout: fixed) algorithm. If one of the margins is 'auto', its computed value is given by the constraints above. Furthermore, if both margins are 'auto', their computed values are equal. (heavily based on: 10.3.4 Block-level, replaced elements in normal flow If 'left' or 'right' are 'auto', their computed value is 0. If 'width' is specified as 'auto', its value is the element's intrinsic width. If one of the margins is 'auto', its computed value is given by the constraints above. Furthermore, if both margins are 'auto', their computed values are equal.) PS. Why aren't there :ltr and :rtl pseudo-classes (:dir(ltr) and :dir(rtl) seems something of a sledgehammer to crack this particular nut) - otherwise it is not possible to express the different styles required for the two directions.
Received on Wednesday, 9 February 2000 09:41:48 UTC