RE: Block-level formatting and width in Netscape 6

>>> position: absolute; left: 100% also behaves differently from how
>>> I would expect.

>>I'm not sure if the way Mozilla(*) draws the content of such a box
>>but not its background is correct, but the positioning seems OK.

>>(See also the erratum for section 9.3.2; the original spec would
>>make things far more confusing if followed to the letter.)

>>How would you expect, then?

>>(* or at least, the last nightly I downloaded.)

>Sorry, that is not what I was referring to, I meant that it starts from
>100% at the left edge of the div which means that the div would sit just
>outside the visible portion of the screen which is inconsistent with
>placing of background images and quite useless as far as I am concerned.

Measuring a percentage value for "left:" from the right edge of the screen
is inconsistent with the intuitive behavior when using a pixel value.
left:30px intuitively means start at 30px from the left edge of the screen.
Therefore, left:12% has to measure from the left edge. If you want to
measure from the right edge, use the right: property.
The spec is at http://www.w3.org/TR/REC-CSS2/visuren.html#position-props
By the way, how is this inconsistent with background images? 0% for a
background image is on the left.
See http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-position

>>> Compare this to the behaviour of left: 100% in background images
>>> where the 100% is measured from the right edge

>>I suspect you mean 'background-position'; it's an unrelated use
>>of percentages (there's a lot of that in CSS, eh?) which doesn't
>>use 'left' or 'right'. I suppose it looks similar if you set
>>'background-repeat: no-repeat', but it isn't really. :-)

>>> Similar techniques behave in a much more useful manner in
>>> css-free html (<table width="100%"> for example).

>>I do agree that the CSS way is somewhat less convenient,
>>because it makes it difficult to mix percentages and inflexible
>>units together in the box model (short of using nested elements,
>>which is a bit disappointing for content-style-separation
>>enthusiasts).

>right, exactly what I mean.

See http://www.w3.org/TR/2000/WD-css3-userint-20000216.html#box-sizing for a
new CSS 3 property that would fix this. Also,
http://www.alistapart.com/stories/100/notes.html does a fairly good job of
dealing with this "bug" in the CSS 1 and 2 box model. (It's not really a
bug. Just massively inconvenient)


>>Er... HTML's table borders were damnably ugly, though, eh?

>and that too, but when the old HTML hacks are more practical and as long
>as they continue to exist (presumably forever), I for one will continue
>to use them. 

So will everyone else until good CSS 3 (for the box model fix) browsers are
in wide use. I estimate at least 3-5 years unless the Web Standards Project
is wildly successful.

Jeffrey

P.S. Shouldn't the new box-sizing property be with the rest of the box
model, not with the User interface module?

Received on Wednesday, 18 April 2001 19:04:18 UTC