W3C home > Mailing lists > Public > www-style@w3.org > August 2000

Re: Problems understanding positioning

From: Maury Markowitz <maury@sympatico.ca>
Date: Thu, 31 Aug 2000 09:11:54 -0700
Message-ID: <002601c01366$2e6d97a0$7de9fea9@gizifa>
To: <www-style@w3.org>
Cc: "L. David Baron" <dbaron@fas.harvard.edu>
> See the rules for determining the containing block of an absolutely
> positioned element in section 10.1 of CSS2 [1].

  Once again my message appears to be poorly worded.  A better way to ask
the question would be:

  Why does the position depend on a specifically positioned element.  Why
isn't it _always_ it's parent element?

>  (It might have been
> easier if 'absolute' and 'fixed' were values of 'display', relative
> positioning was handled through offset properties, and containing block
> choice was handled some other way, but that's not the way the current
> spec works...)

  I've always wondered about this myself, there's a lot of overlap between
display and position and they appear to be able to be handled by a single

> With absolute positioning you should be able to use the 'right'
> property, assuming 'width' is 'auto'.  It's not as well supported by
> browsers as 'left'.

  Yes, this is my finding. However I should point out that the article body
text is positioned relative - although in retrospect there seems to be no
particular reason for that I suppose.  Why doesn't RIGHT work with relative
positioning?  That doesn't seem to make much sense.

  That said, using RIGHT and absolute positioning has problems in all the
browsers I've used in general, in that they no longer "resize live".  That
is to say that when you resize a browser using tables for layout the
contents of the tables flow in "real time" as you drag. As soon as you use
absolute positioning, that stops working.  Very annoying.

Received on Thursday, 31 August 2000 09:05:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:55 UTC