Re: Very bad errors in positioning

On Mon, 20 Mar 2000 11:25:52 -0800, Matthew Brealey
(webmaster@richinstyle.com) wrote:
> 
> <q>
> 'top'
> ...
> This property specifies how far a box's top content edge is offset below
> the top edge of the box's containing block.
> </q>
> 
> This surely must be the worst error in CSS. Firstly, it is not the
> content edge but the margin edge and secondly it is not necessarily the
> top edge of the containing block - if it is a relatively positioned
> element it is an offset relative to its normal position.

The first of these problems is corrected in the CSS2 errata [1].  I
agree that the second should be changed, although it is a bit clearer
in the errata.

> For relatively positioned elements, there are serious problems. Since
> top: x is equivalent to bottom: -x, there are undefined conflicts in CSS
> - what does <div style="top: 50px; bottom: -60px"> do? There are very
> bad problems here that need urgent public resolution.

This is corrected in the errata.

> In addition there are also pretty catastrophic errors relating to the
> way that the horizontal formatting of absolutely positioned elements is
> determined. It is postulated that LHS == width of containing block, and
> yet 

It doesn't say the width property of the C.B.  It says the width.

> To the current rules I would add the proviso that 'If 'bottom' is set to
> auto, then the user agent need not sum the values to the height of the
> containing block (which usually means that the user agent must have
> rendered the whole of the containing block), but may simply render the
> element at the distance specified by 'top' below the top edge of the
> containing block, since the result would be exactly the same.'

CSS doesn't really describe rules for incremental layout.  I think if
it's clear that an element will be in a certain position, there's no
reason it can't be drawn.

[ quote from CSS2 10.6.4 snipped ]

> It is stated here that if 'height' and 'bottom' are both auto, bottom is
> replaced with 0. This is very badly wrong. For example, take <DIV
> style="position: absolute; top: 100px">Some text</DIV>. In this case,
> since 'height' and 'bottom' are both auto, bottom is replaced by 0. This
> leaves the only auto value as 'height', so the conclusion is that the
> height is the height of the containing block - 100px. For a typical
> document that is 10,000 pixels high, this gives a height of 9,900 pixels
> for an element whose height really should only be the height of its
> content (i.e., one line box, assuming that 'Some text' can be formatted
> as a single line).

This is the way the current spec was designed.  However, this is not
compatible with existing implementations, and from what I've heard, the
spec may well be changed.

> In addition, the statement that 'auto' be replaced 'with the distance
> from the top edge of the containing block to the top margin edge of a
> hypothetical box that would have been the first box of the element if
> its 'position' property had been 'static'. (But rather than actually
> computing that box, user agents are free to make a guess at its probable
> position.) The value is negative if the hypothetical box is above the
> containing block.' is also wrong. In particular, the issue of the first
> box of the element does not seem correct - surely it should be the top
> margin edge of the element itself.

Why is it wrong?  It's the intended behavior (although it makes the
spec very complicated because it's accomplished with 'auto').

> Furthermore, the specification is also wrong in that it fails to
> consider margin collapsing. For example, take 
> <div style="margin-bottom: 100px">
> Content
> </div>
> <div style="margin-top: 50px; position: absolute">
> Content
> </div>
> 
> The unambiguous _intent_ is to place the content of the element in the
> same place as it would have been but for the position: absolute
> declaration. The effect, however, is to place the top margin edge at the
> place it would be. The margin edge is here normally:

This should be fixed.  The border edge should be placed in the same
position as it otherwise would have been.

-David

[1] http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html

L. David Baron    Sophomore, Harvard (Physics)    dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.     <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                      <URL: http://www.webstandards.org/css/ >

Received on Monday, 20 March 2000 09:36:59 UTC