Re: css3 absolute positioning and containing blocks question/suggestion

Someone sent me an e-mail and suggested using position: relative; to
get a containing block of the parent (doh. Why didn't I see that,
Thanks). So that's no longer a very good usage scenario, as it can be
done currently, however, it still applies because for some authors it
is more intuitive to say, position based on element x or element y...
read on.

And now, my long-winded explanation as to why I think the
absolute-containing-block property should be implemented.

I still think that a new property:
'absolute-containing-block'
should be implemented because of the control it would afford authors
to make things seem to be anywhere the author wishes on the page. I'm
thinking this is better material for the advanced layout module now,
if accepted. One thing I think this has the possibility to do is allow
an easy upgrade path for browsers that have flawed (sometimes on
purpose) positioning support (such as positioning all absolute
elements with body as containing block, or always with the parent, or
some other thing) by allowing them to set a default such as "parent"
or "body", but allowing those authors that understand css to override
that default and put things where they wish, not where the browser
thinks they should go.

Some possible usage scenarios (please feel free to shoot my idea with
holes, provided you tell why, and what alternatives there are) :

===Scenario A. (the shorter more generic example)===
An author is trying to position something based on the position of
another element.

The options:
Figure out where in relation to that other element this one is. Won't
work if the element is flowed with page, and changes location. An
absolute position won't work (or at least it not very well)
I think it would be easier to just say, position by element x with
top:-2em, so that it is always 2 lines above it or in some other
direction... I believe some very complex layouts could be easier to
implement with this feature. (thus this would be an advanced-layout
property I think) I think this also has the capability of making it
easier to implement WYSIWYG website editors based on CSS, not on
structural markup like tables. In my mind, the ease of use on a
technology is proportional to the rate of CSS adoption for layout
(note: I have no numbers to back this statement up, it's just that, my
opinion.)

===Scenario B. (the longer more specific example)===
Suppose a page has the following layout
...<body>
<h1 id="page-title">title</h1>
<div id="page-content">content bla bla bla</div>
<div id="site-wide-content">
   <ul id="navigation-list">
      <li>bla</li>
      <li>bla</li>
   </ul>
   <form id="site-login">...</form>
   <span id="disclaimer">bla</span>
</div>
</body>...

This layout is structurally clean, and accessible, at least as far as I can see.
Visually however the author wishes to have the #navigation-list appear
(in visual browsers, assuming there are separate style-rules to
provide for mobile, speech, etc.) on the upper right hand corner of
the #page-content and the rest of the #site-content to be fixed to the
lower right hand corner of the view-port.
Some options on the face might be:

#navigation-list {move-to:#page-content;position:absolute;right:0;top:0;}
/*but this won't allow moving it to elements earlier in the tree
(which makes perfect sense as user-agents can show a page as they
download, without reflowing) so this isn't a good choice*/

#navigation-list {position:absolute;...} 
/*but this won't work either, as the containing block is defined to be
#site-content, which is position: fixed. oh frustration. What about
position:fixed for each individual element in #site-content, but then
we have to make sure there's enough space for each of the elements,
for every language the page is translated to, what a nightmare*/

And then of course there's the scripting, but what about those
browsers that don't support the script I choose, relying on it for the
presentation of my site could cause adverse affects when a browser
that doesn't support the script tries to use the styles I've given
that element, thinking it would be somewhere else. More script?, and
for each additional problem, more script?... what a bulky website
*shivers* I don't like this option. It's not easily updateable and it
doesn't allow css to live up to it's potential.

There's also the option of changing the structure, but then I have to
worry a lot more about making sure where I place an element is
accessible, and that it makes sense for those browsers that don't
support css, and I have to be careful about adding extraneous
structure, because that reduces accessibility, and accessibility is a
must. Also, this is a fairly generic structure and if I can style the
entire thing with a CSS sheet, it'll scale well across the site (in
general)... I really don't want to chane my carefully constructed
structure, and in some cases, I *can't* change the structure, because
say:
it is the output of a program over which I have no control
I am a user creating a user-style sheet for an int(er/ra)net site, or
some site I use regularly, but only use portions of and want to make
it easier for me to find that bit of info I'm always looking up,
making it easier for me to do my job or I "just don't like the layout
of the site" or I'm trying out new styles on an existing website, to
see my stylesheet in action... and a ton of other reasons to use
user-style-sheets (including the multitude of accessibility reasons)

So basically in this case, there are no particularly elegant solutions
(nor will most of my proposed solutions even work, at least not
without a lot of effort or giving up something else in-order to get my
layout) In essence, with the current technology, I would probably end
up giving up on that particular design, sacrificing the site's
usability, due to capabilities. (unless of course I've missed some
other great option.

Using the proposed absolute-containing-block, however, this situation
would be a snap:
#navigation-list
{position:absolute;absolute-containing-block:#page-content;right:0;top:0;}

Thank you for reading my lengthy post,
Jacob

My original message, with some parts left out:
> > As far as I can see (and after a quick search through the mailing list
> > archive) there are no methods for simply changing which block should
> > be used as the containing block. CSS2.1 says
> > (http://www.w3.org/TR/CSS21/visudet.html#containing-block-details) "If
> > the element has 'position: absolute', the containing block is
> > established by the nearest ancestor with a 'position' of 'absolute',
> > 'relative' or 'fixed'..." I believe allowing an author to set an
> > 'absolute-containing-block' or something similar would be extremely
> > beneficial.
> >
> > What this does for the author:
> > Allows absolute positioning based on a different element (say the
> > direct parent, useful in cases such as CSS based menus as well as
> > general layout.)
> >
> > What this means to user-agents:
> > User-agents, would not "move" the element, as in 'move-to' but would
> > base the position of the current element, and all of that elements
> > descendants on the element defined in  'absolute-containing-block'.
> > I'm not sure if there are any other reprecussions, for the user-agent,
> > but I believe this would allow the user-agent to progressively show
> > the document as it loads it, because absolutely positioned objects
> > don't cause re-flow, they are just put on top.
> >
> > To make sure that the user-agent doesn't place the
> > absolutely-positioned element under the absolute-containing-block I
> > think the z-index, when none is defined, should default to the
> > absolute-containing-block's z-index +1 or something similar.
> >
> > If this has already been suggested, great! Please point me to where I
> > can read the discussion, as I did not see anything quite like it in
> > the archives. Otherwise, I hope to see this incorporated (if it, or
> > something similar) isn't already in either the positioning module, or
> > the advanced layout module, As I think it would fit in either module,
> > but fit better in positioning.

Received on Wednesday, 21 September 2005 02:55:30 UTC