- From: Clover Andrew <aclover@1value.com>
- Date: Tue, 17 Jul 2001 17:50:42 +0200
- To: <www-style@w3.org>
Eric Meyer <eric@meyerweb.com>
> Neither does your positioned DIV have a containing block at
> this point, except the root element, whose height would also
> (I think!) be zero.
I think it'd be the size of the viewport - 9.1.2:
The height of the initial containing block may be specified with
the 'height' property for the root element. If this property has the
value 'auto', the containing block height will grow to accommodate
the document's content.
I take this to mean 'grow' from size of the viewport (as mentioned
in the previous paragraph-*) rather than zero; this is what browsers
seem to do with %-height absolutely positioned elements anyway, more
or less. The bug here is that setting 'top: 10%; bottom: 10%' is not
resulting in the same thing as 'top: 10%; height: 80%'.
* - which says that auto-width on the ICB is always simply the
viewport width: the height expands where the width does not.
Such non-orthogonality [not alone in a spec centred on
vertically-scrolling documents] offends me! :-)
> If you really want to test this, try forcing your BODY to be a
> particular size, like so, and also make it a containing block
Unfortunately this doesn't fix it!
> enough theoretical review has popped up in this thread that
> it may stimulate discussion of how CSS positioning really
> works
[engage controversy mode]
IMO it doesn't, really. Work, that is.
It can't hope to reproduce the richness of layout possibilities
that tables managed (except by using the table-something values
of 'display', which results in just as much style-and-content
mixture as tables did): it's particularly bad at specifying
layout where there's a mix of fixed-size blocks, unknown-size
[typically text] blocks and dependent-on-viewport-size blocks.
People are going to start noticing this more and more in the
future, as browser implementations get better and can no longer
be blamed for everything that doesn't work. The current
minimalistic layouts we do with CSS are all very nice, but not
every site can look like that. Even those tend to rely on
nesting divs and putting A content after B content to get
one thing to appear below another. Style and content again.
> and ways in which it might be improved, and that would be
> on-topic for the list.
I'm quite pessimistic here. I can't see a way of improving
the positioning properties without totally breaking backwards
compatibility. People have suggested expressions like
'10%-50px' (which is simple enough) and ways to read the
size of unknown-size elements, like '10%+myel.bottom' (which
would raise implementation complexity horribly). Both ideas
would render dismally on CSS 2 browsers.
A totally different positioning scheme (perhaps similar to
the grid-layout ideas Sam and I brought up on webdesign-l) could
override positioning on supporting browsers, with the older
properties continuing to work on browsers that didn't recognise
the newer scheme. But let's face it, there'd be no momentum
behind trying to replace CSS-P, not after the huge (and ongoing)
effort to get browser manufacturers to support it in the first
place.
--
Andrew Clover
Technical Consultant
1VALUE.com AG
Received on Tuesday, 17 July 2001 11:52:58 UTC