Absolute positioned children in relative positioned table cell

I'm revamping the user interface of our CMS and want to put the
controls for sorting content in its own column. My design entails
having an up arrow at the top of the cell and a down arrow at the
bottom. The rows can vary in height, which complicates things
somewhat.

My first thought was to set the cell that contains the up and down
arrows position: relative and then set the arrow graphics themselves
position: absolute with the top set to 0 for the up arrow and the the
bottom set to 0 for the down arrow. I was expecting I'd run into some
trouble in IE, but ironically it turns out that IE is the only browser
that this functions in as I had expected it to.

I suspect I'm doing something really dumb, but whatever it is that's
wrong just isn't jumping out at me. If anyone else can spot it, or
suggest another approach that'll work cross-browser (including IE6 :
( ), I'd appreciate any help you can offer.

I've built a mockup at http://library.merus.co.uk/newbrowser.html

On 2009-04-15, Gordon <grj.mcvey (AT) googlemail (DOT) com> wrote:

I'm revamping the user interface of our CMS and want to put the
controls for sorting content in its own column. My design entails
having an up arrow at the top of the cell and a down arrow at the
bottom. The rows can vary in height, which complicates things
somewhat.

My first thought was to set the cell that contains the up and down
arrows position: relative and then set the arrow graphics themselves
position: absolute with the top set to 0 for the up arrow and the the
bottom set to 0 for the down arrow. I was expecting I'd run into some
trouble in IE, but ironically it turns out that IE is the only browser
that this functions in as I had expected it to.

Yes, I think that should work, but it doesn't in Firefox. There's sort
of a get-out in the spec if you read it the right way so they could
argue it's not technically wrong...

I suspect I'm doing something really dumb, but whatever it is that's
wrong just isn't jumping out at me. If anyone else can spot it, or
suggest another approach that'll work cross-browser (including IE6 :
( ), I'd appreciate any help you can offer.

You can put another div inside the td, and set it to position: relative.
Then put the absolutely positioned thing inside the div.

It looks like you're setting the heights of the rows, so you can make
that extra div height: 100% (needed to provide the correct reference
point for the arrow at the bottom of the cell).

Don't know if it works in IE.

Gordon wrote:

I'm revamping the user interface of our CMS and want to put the
controls for sorting content in its own column. My design entails
having an up arrow at the top of the cell and a down arrow at the
bottom. The rows can vary in height, which complicates things
somewhat.

My first thought was to set the cell that contains the up and down
arrows position: relative and then set the arrow graphics themselves
position: absolute with the top set to 0 for the up arrow and the the
bottom set to 0 for the down arrow. I was expecting I'd run into some
trouble in IE, but ironically it turns out that IE is the only browser
that this functions in as I had expected it to.

I suspect I'm doing something really dumb, but whatever it is that's
wrong just isn't jumping out at me. If anyone else can spot it, or
suggest another approach that'll work cross-browser (including IE6 :
( ), I'd appreciate any help you can offer.

I've built a mockup at http://library.merus.co.uk/newbrowser.html

http://www.w3.org/TR/CSS21/visuren.html#propdef-position

<quote>
The effect of 'position:relative' on table-row-group, table-header-group,
table-footer-group, table-row, table-column-group, table-column, table-cell,
and table-caption elements is undefined.
</quote>

All bets are specified to be off. You can't do this.

As Ben mentioned, stick a containing div in there.

--
Richard.

On 2009-04-15, rf <rf@z.invalid> wrote:
[...]

http://www.w3.org/TR/CSS21/visuren.html#propdef-position

quote
The effect of 'position:relative' on table-row-group, table-header-group,
table-footer-group, table-row, table-column-group, table-column, table-cell,
and table-caption elements is undefined.
/quote

All bets are specified to be off. You can't do this.

Yes but see also section 10.1 (definition of containing block) which
makes no specific exception for table cells.

The containing block in this case is provided by the nearest positioned
ancestor, i.e. the table cell.

My reading of the spec is that actually trying to _offset_ table cells
with relative positioning is undefined, but that they really ought to
work as containing blocks for positioned descendents.

Offsetting is the effect, establishing a containing block is the
side-effect. The effect may be undefined (explicitly in 9.3.1) but the
side-effect _is_ defined, in 10.1.

But regardless of such verbal quibbles, there's no good reason for a
table cell not to be able to be a containing block.

On Apr 15, 1:48*pm, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2009-04-15, Gordon <grj.mc... (AT) googlemail (DOT) com> wrote:

I'm revamping the user interface of our CMS and want to put the
controls for sorting content in its own column. *My design entails
having an up arrow at the top of the cell and a down arrow at the
bottom. *The rows can vary in height, which complicates things
somewhat.

My first thought was to set the cell that contains the up and down
arrows position: relative and then set the arrow graphics themselves
position: absolute with the top set to 0 for the up arrow and the the
bottom set to 0 for the down arrow. *I was expecting I'd run into some
trouble in IE, but ironically it turns out that IE is the only browser
that this functions in as I had expected it to.

Yes, I think that should work, but it doesn't in Firefox. There's sort
of a get-out in the spec if you read it the right way so they could
argue it's not technically wrong...

I suspect I'm doing something really dumb, but whatever it is that's
wrong just isn't jumping out at me. *If anyone else can spot it, or
suggest another approach that'll work cross-browser (including IE6 :
( ), I'd appreciate any help you can offer.

You can put another div inside the td, and set it to position: relative.
Then put the absolutely positioned thing inside the div.

It looks like you're setting the heights of the rows, so you can make
that extra div height: 100% (needed to provide the correct reference
point for the arrow at the bottom of the cell).

Don't know if it works in IE.

Thanks for the quick reply.

The fixed height for the table rows is just a placeholder for now,
when finished the rows will have a flexible height and a min-height
set. There will also be some CSS hacks in the IS stylesheet to
replicate this behaviour.

I was really hoping to avoid using an extra div but I guess there
might not be much choice. Though maybe a list would be a better
container.

The thing is that it's only IE that this approach works in, every
other browser fails to position the arrows where I want. This leads
me to suspect that IE is doing the incorrect thing here, albeit also
the thing I want it to do.

Ben C wrote:

On 2009-04-15, rf <rf@z.invalid> wrote:
[...]
http://www.w3.org/TR/CSS21/visuren.html#propdef-position

quote
The effect of 'position:relative' on table-row-group,
table-header-group, table-footer-group, table-row,
table-column-group, table-column, table-cell, and table-caption
elements is undefined. </quote

All bets are specified to be off. You can't do this.

Yes but see also section 10.1 (definition of containing block) which
makes no specific exception for table cells.

The containing block in this case is provided by the nearest
positioned ancestor, i.e. the table cell.

Good point.

My reading of the spec is that actually trying to _offset_ table cells
with relative positioning is undefined, but that they really ought to
work as containing blocks for positioned descendents.

My reading is that specifying position: relative; for a td is, in and of
itself, undefined. So the property should be simply ignored, as it appears
to be in the case to hand. If the property is undefined then any side
effects are also undefined, as is actually trying to _offset_ the td.

I guess it comes down to the wording of "the effect of ...".

{damn, I'll have to look at the spec again}

Hmmm. It's odd that the other position values don't specify anything about
table cells. Can one absolutely position them? Never tried :-)

I was expecting something for top: and left: as well but then again would
that mean anything, or rather should it mean anything, to use these for a
td?

A td seems to be a law unto itself. Same for the other table elements.

Offsetting is the effect, establishing a containing block is the
side-effect. The effect may be undefined (explicitly in 9.3.1) but the
side-effect _is_ defined, in 10.1.

Yes. But perhaps 10.1 should specifically state that you cannot establish a
td as a containing block, because as per 9.3.1 you cannot position it, for
example, relative.

Consider also the display: value for at td. It's not block. It's table-cell.
Perhaps what we are really talking about is that elements with display:
table cell; cannot be positioned, at all, given that they already have
"position" in the table.

But regardless of such verbal quibbles,

which we can indulge in for a long time if we are delving into the specs.

there's no good reason for a
table cell not to be able to be a containing block.

Indeed and I have had to resort to stuffing in a containing div in there
myself on occasion:-)

--
Richard.

On 2009-04-15, rf <rf@z.invalid> wrote:

Ben C wrote:
On 2009-04-15, rf <rf@z.invalid> wrote:
[...]
http://www.w3.org/TR/CSS21/visuren.html#propdef-position

quote
The effect of 'position:relative' on table-row-group,
table-header-group, table-footer-group, table-row,
table-column-group, table-column, table-cell, and table-caption
elements is undefined. </quote

All bets are specified to be off. You can't do this.

Yes but see also section 10.1 (definition of containing block) which
makes no specific exception for table cells.

The containing block in this case is provided by the nearest
positioned ancestor, i.e. the table cell.

Good point.

My reading of the spec is that actually trying to _offset_ table cells
with relative positioning is undefined, but that they really ought to
work as containing blocks for positioned descendents.

My reading is that specifying position: relative; for a td is, in and of
itself, undefined. So the property should be simply ignored, as it appears
to be in the case to hand.

I don't think that's what undefined means-- I think it means the browser
can do what it wants, e.g. make demons fly out of the floppy disk drive.

It's probably defined somewhere in some RFC exactly what it does mean.

If the property is undefined then any side effects are also undefined,
as is actually trying to _offset_ the td.

There would actually be no problem with offsetting the tds as well, and
I think if a browser chose to do that it wouldn't be wrong (undefined
means you can do what you like).

[...]

Hmmm. It's odd that the other position values don't specify anything about
table cells. Can one absolutely position them? Never tried :-)

I don't think so, but I can't remember if I've tried. In that case I
would expect the td to be effectively removed from the table as if it
weren't there.

I was expecting something for top: and left: as well but then again would
that mean anything, or rather should it mean anything, to use these for a
td?

Only if you could position them (fixed, absolute or relative).

[...]

Yes. But perhaps 10.1 should specifically state that you cannot establish a
td as a containing block, because as per 9.3.1 you cannot position it, for
example, relative.

No, if they meant that they would say position "applies to everything
except table cells". Instead they say, "applies to all elements".

Consider also the display: value for at td. It's not block. It's table-cell.
Perhaps what we are really talking about is that elements with display:
table cell; cannot be positioned, at all, given that they already have
"position" in the table.

Yes, we are of course talking about that. You can make a td display:
block and then positioning should work on it-- it's just a block.

But regardless of such verbal quibbles,

which we can indulge in for a long time if we are delving into the specs.

there's no good reason for a
table cell not to be able to be a containing block.

Indeed and I have had to resort to stuffing in a containing div in there
myself on occasion:-)

The problem with that though is that the cell may have auto height and
you may want to absolutely position relative to the bottom edge of it
(height: 100% on the div won't work, except in quirks mode, if the
cell has auto height).