- From: Maury Markowitz <maury@sympatico.ca>
- Date: Thu, 31 Aug 2000 09:11:54 -0700
- 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 selector. > 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. Maury
Received on Thursday, 31 August 2000 09:05:54 UTC