Re: width of absolutely positioned, non-replaced elements

> I am writing to question the reasoning behind section 10.3.7 of the CSS2
> spec.  I am of the opinion that there is a flaw in this section which
> may
> have serious negative implications for many web applications.  Let me
> explain why.

This is rather vague. I would like to see an example that is demonstrably
problematic.

> This section states that when the width (or height, as in 10.6.4) of
> said
> element is "auto", the width will extend to the boundaries of it's
> containing block.  The consequence of this is that said absolutely
> positioned elements have no means of accurately representing the
> dimensions
> of their content.  Can someone please explain to me why block-level
> elements
> get to turn "auto" into their intrinsic width/height, but absolutely
> positioned elements do not?

There seems to be something of a misunderstanding here.

Absolutely positioned elements _are_ block-level, and are always so.

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.

If you are talking about static vs. absolutely positioned element, there
is still no difference - intrinsic dimensions are only relevant for
replaced elements (this term will have to be revised in CSS3) such as
images, where the image is intrinsically x by y pixels. This is the same
for absolutely positioned intrinsic elements as static ones.

As regards whether it is a problem that absolutely positioned elements
fill their containing block by default, I would say definitely not.
Because absolutely positioned elements are transparent by default,
although an absolutely positioned block might in fact be covering the
entirety of a page, there will be no way to tell that this is so because
of the fact that absolutely positioned elements are removed from normal
flow.

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').

> I can plainly state that there is a definite need to these elements to
> be
> able to determine the dimensions of their content.  Many applications
> today
> use Javascript and DOM to develop complex widgets and layouts using
> absolute
> positioning only.  

Bad, bad application.

Absolute positioning should  not be used for these purposes. Static
positioning is what is required, because absolute positioning makes an
enormous number of assumptions about the size of the viewport, the size of
the font that the user has, etc.; a correct static positioning
implementation should remove the ever more prevalent abuse of absolute
positioning (which should _never_ be used to layout pages (only for
scripting effects); static positioning is ideally suited to this purpose,
because everything just flows on from where the previous element was).

> These applications will often fill an element with
> text
> and expect the size of the element to be the size of it's content. 
> These
> applications are completely crippled if these elements are incapable of
> representing their intrinsic size.

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.
 

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Friday, 3 March 2000 06:06:32 UTC