Re: positioning and sizing an element relatively to any other element

His precise list:

1) All I want for Christmas is the ability to position a box relative
to another box that is not the container. Like, say, something like:
position: relative-to #other_box top-right; top: 0; left: 0;, and then
the top-left of my box would be aligned to the top-right of
#other_box. Then I would never have to wrangle with float ever again,
except when I wanted to have some text spill around a box.

2) Then while we're at it, I'd really love to be able to specify the
size of a box (either horizontal or vertical) as being identical to
another box. Maybe something like: width: #other_box and height:
#other_box. Tables do this. They did it in 1996. Now it's 2010, and I
think that this is something we all would love, but without the
tables. So it's something for you to think about; it would really help
us out.

3) Since we're talking about height, it would also be awesome to have
a way to say "this should be the height of its container but no
larger". You'd think height: 100% would do that, but no, that seems to
make the box the height of its content, at least the last time I tried
it (yesterday). That's OK, though, we love you even though you're
eccentric, CSS. I think we just need a little something different,
here.

4) I can't say how much I'd love to be able to vertically center
something in a box. Some of the less-informed members of this little
sit-down here might think that vertical-align has something to do with
vertically aligning things in boxes. But no, no, it doesn't. It was a
bit of a trick that CSS pulled on us, and we understand that there
were some reasons, so we're annoyed, but understanding.

5) While we're at it, wouldn't it be nice to have a single, simple way
to center anything horizontally in its containing box? margin: 0 auto
usually works. I mean, if you wrap the contents in a table so that
they auto-size. (That's a whole other issue, though, possibly solved
by display: table?) Sometimes you have to use text-align: center,
though. That's fun, but not really what we meant. Then sometimes
there's no way at all, which isn't so fun.

6) If you felt really nice, letting me specify z-index on
non-positioned elements and having it actually work would be really
awesome. That's just if you feel like it, though. I know that there's
a lot of other stuff to think about, here, and and I want you to take
your own time to do it, and think about it for yourself.

I'll tackle them in reverse order.

#6 I don't see the problem with.  Just slap a relpos on the element
and you're done, z-index works.  I'd have to ask the dude what the
problem with this is (and I will do that, as soon as I finish this
email).  The only downside is that it's now a container for any
positioned children, but that can be addressed by solving #1.

#4 and #5 are, I think we all recognize, quite necessary.  It's silly
that CSS still doesn't have this ability.  The margin:0 auto trick is
cute, but annoying in multiple ways - you have to either specify the
top/bottom margin or explicitly break it out into a margin-left and
margin-right declaration, you need to give the container a definite
width or else trigger shrinkwrap behavior by setting it as
display:table (this will be fixed by the new width values, of course),
and it doesn't work at all for centering multiple things.  Vertical
alignment doesn't work *at all* without a silly hack (abspos it,
top:50%, margin-top: -[box height here]) that requires a definite
height.

We really need to solve this.  People have been agitating about it for *years*.

#3 is addressed by dbaron's percentage height suggestion, which is on
the agenda this week and high enough up that it should hopefully
actually be discussed.  Let's all review it and make sure we
understand it before the call!

#2 is tricky.  There's the obvious problem that it can cause circular
dependencies.  These can be tracked and broken, but then we'd have to
decide what exactly to do.  We already have the table-* display types
that can cause this in particular circumstances, and I've got some
ideas to generalize that somewhat in a more flexible way, which I'll
write up before the ftf.  I also believe that Template Layout will
address many of these problems, since template ::slots *are* sized and
positioned relative to each other, as specified by the template
strings.

However, I have a use-case that I ran into and which was very annoying
which can't be solved by this.  I had a page of multiple data tables,
separated by headings.  All the tables have the exact same columns, so
I'd like for them all to have the same column widths.  I can't do that
currently, or with any existing suggested method.  I still don't want
the suggested "be as wide as this other element", though, as I want
*all* the cells to participate in the table layout - essentially I'd
like them to be one big table that just happens to be visually chopped
up with headings inserted between.  I can produce an example page for
this if requested.

#1 I agree with completely.  I've often run into annoying problem
where I've made some container be relpos so I could position something
relative to it, but then I want to position another child according to
some *ancestor* of the container, and have to hack things around to
make it work.  There's still circular-dependency issues here, but I
think we can address them, and that it's worthwhile to do so.  (Two
basic situations - positioning an element relative to a descendant
shouldn't work at all.  Positioning cousin elements circularly (A
position-to B, B position-to C, C position-to A) could break with the
element latest in DOM order 'losing' and not being positioned.

I'll ask the dude a few questions, but for a few of these issues, he's
just the latest voice among legions (including mine).

~TJ

Received on Wednesday, 17 March 2010 14:36:25 UTC