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

RE: width of absolutely positioned, non-replaced elements

From: Joe Hewitt <joe@joehewitt.com>
Date: Fri, 3 Mar 2000 10:33:39 -0500
To: <www-style@w3.org>
Message-ID: <000101bf8525$da231680$31cfb326@zenimax.com>
> This is rather vague. I would like to see an example that is
> demonstrably
> problematic.

One is on it's way.

> There seems to be something of a misunderstanding here.
> Absolutely positioned elements _are_ block-level, and are always so.

Pardon me.  I meant "inline" or "float" rather than "block-level".

> In addition, absolutely positioned elements do not behave any
> differently
> to static ones - both have their width fill the containing
> block, which is
> the logical and predictable thing to do.

Why is this logical and predictable?  It doesn't seem that way to me.  I
think it would be predictable for said elements to represent their intrinsic
width.  This should be the rule for ALL elements with width/height set to

> If you find a need to give them backgrounds, you can insert a spanning
> inline and apply the background to that (see my recent suggestion for
> LEGEND in the message entitled 'Setting the height of BR').

What you are describing here is not an elegant solution, it is a hack.  You
should not need to insert a spanning inline at all.

> The apparent size of the element will indeed be its intrinsic
> size; the
> actual size, since the element is outside normal flow, will not be
> apparent or necessary to know.

It is EXTREMELY necessary to know the size of elements outside of the normal
flow.  Many scripts will absolutely position elements with arbitrary content
and require knowledge of their size for purposes such as alignment with
other elements.  Please do not tell me I should only use static positioning
in these cases because that is not always practical.

I would be happy to tell you why absolute positioning is completely
necessary for developing widgets and even some page layouts.  Further
details and examples coming soon....
Received on Friday, 3 March 2000 10:30:14 UTC

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