Welcome to WebmasterWorld Guest from 54.159.246.164

Forum Moderators: not2easy

Message Too Old, No Replies

relative positioning + display as table cell

Firefox doesn't play nicely.

   
6:56 am on Aug 12, 2013 (gmt 0)

10+ Year Member



So, it's pretty common to set a parent container to
position: relative
, and then have some children of that container set to
position: absolute
, and position them relative to the parent container.

My issue occurs when I also set that relatively-positioned parent container to display as table-cell also.

In all the browsers I've tested besides Firefox, up to and including FF 23, there is no issue.

However, Firefox will, once the container is displayed as table-cell, ignore the relative positioning, and the absolute children then search for the next parent (until root) that's position relative (and not set to display as table-cell.)

Here's some code:

<!DOCTYPE html>
<html lang="en">
<head>
<title>Relative positioning + table cell test</title>

<meta charset="utf-8" />

<style type="text/css" media="screen">
div.table-cell,
div.float-cell { position: relative;
display: table-cell;
width: 500px;
background-color: #444;
border: 5px solid #fff;
color: #fff; }

div.float-cell { float: left;
display: block; /* table-cell breaks position: relative; parents */ }

div.abs-pos { position: absolute;
right: 0;
top: 0;
width: 150px;
height: 200px;
background-color: #fff;
border: 5px solid #666;
color: #444;
opacity: 0.7; }
</style>
</head>
<body>

<div id="entirety">

<div id="shell">

<section id="copy" role="main">

<h1>Relative positioning + table cell test</h1>
<p><code>position: relative;</code> alongside <code>display: table-cell;</code> incorrectly loses control over <code>position: absolute;</code> children.</p>
<div class="table-cell">
<p>This is a <code>div</code> set to display as table cell.</p>
<div class="abs-pos">
<p>This is an absolutely positioned <code>div</code> that should be picking up the co-ordinates from its relatively positioned parent, <code>table-cell</code>, but it isn't in Firefox.</p>
</div><!-- end .abs-pos -->
</div><!-- end .table-cell -->
<div class="table-cell">
<p>This is another <code>div</code> set to display as table cell.</p>
</div><!-- end .table-cell -->

<div class="float-cell">
<p>This is a <code>div</code> set to display as a float.</p>
<div class="abs-pos">
<p>This is an absolutely positioned <code>div</code> that is picking up co-ordinates from relatively positioned parent.</p>
</div><!-- end .abs-pos -->
</div><!-- end .float-cell -->
<div class="float-cell">
<p>This is another <code>div</code> set to display as a float.</p>
</div><!-- end .float-cell -->

</section><!-- end section#copy -->

</div><!-- end div#shell -->

</div><!-- end div#entirety -->
</body>
</html>


Now, W3C makes no mention that once an element is set to
display: table-cell;
it should lose its
position: relative;
ness.

So, Firefox is wrong?
7:17 am on Aug 12, 2013 (gmt 0)

WebmasterWorld Senior Member drdoc is a WebmasterWorld Top Contributor of All Time 10+ Year Member



Well, this has been the case for years ... Sadly, no browser is wrong ... nor right.

CSS 2, Visual formatting model, 9.3.1 [w3.org]
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.


The problem here is really that you are mixing two types of layout methods -- relative/absolute position, and table layout.

For what it's worth, I've never seen the need for any of the
table-*
properties. If I want a table, I use a table. Otherwise I use positioning/floats/normal flow as necessary.
7:23 am on Aug 12, 2013 (gmt 0)

10+ Year Member



Well, I want the table-cell so that I can get two matched-height columns.

I also want relative positioning, because I have a badge that I want to stick to the top-right of the element, but the text for this badge should go after the rest of the copy within that column.

I don't want a table, because it's not tabular data.

:)
8:53 am on Aug 12, 2013 (gmt 0)

WebmasterWorld Senior Member drdoc is a WebmasterWorld Top Contributor of All Time 10+ Year Member



What you want can't be done; not the exact way you want it.

But there are plenty of workarounds. You could, for example, put another element on the outside. Assign
position: relative
to the outer element.
9:49 am on Aug 12, 2013 (gmt 0)

WebmasterWorld Senior Member swa66 is a WebmasterWorld Top Contributor of All Time 10+ Year Member



While "two matched-height columns"is something one wants on first looks, it's most often not needed to actually have it. With a background on a parent you most often can achieve what you need without the need to revert to table layout.
11:35 am on Aug 12, 2013 (gmt 0)

10+ Year Member



Assign position:relative to an inner element in the table-cell and keep all the content in that inner element. Then you can absolutely place the element at the top right of that inner element which will be the top right of the table-cell (apart from padding etc).
1:54 pm on Aug 12, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



For what it's worth, I've never seen the need for any of the table-* properties. If I want a table, I use a table. Otherwise I use positioning/floats/normal flow as necessary.


I agree with you and disagree. What I mean is, table properties do not make an element a table element but makes them display as one of the elements. As far as the outline goes, they won't be the same thing. However, I get queasy in the stomach the couple of times I've used that for positioning and always feel like I'm not thinking about it good enough.

There was an article a bit back where someone discussed this very thing and seemed to be convinced that it's just a CSS property, not a table, and you can use it however you want. It just doesn't feel right to me.
4:57 am on Aug 13, 2013 (gmt 0)

10+ Year Member



Hi @swa66, yeah that's the kind of thing I would've done in previous times. However, in order to reduce pageload times, I am reusing this one background image texture in different spots with different widths/heights, and so it should really be on the column itself, to control the bleed.

Hi @DrDoc, @Paul_o_b, yep I thought that was a good way to execute it. It's slightly messier HTML-wise, but the extra div is faster for a browser to render than a new image is.

Thanks all!
7:10 pm on Aug 13, 2013 (gmt 0)

10+ Year Member




There was an article a bit back where someone discussed this very thing and seemed to be convinced that it's just a CSS property, not a table, and you can use it however you want. It just doesn't feel right to me.


You have to separate presentation form content :)

CSS implies no real semantic meaning to a page and the display:table properties are simply a means to perform certain types of layout of which tables were good at - end of story. Html on the other hand is all about content and if you are displaying tabular data you must use an html table.

As far as the CSS display:table-properties go it would have been better if they were called something else and it wouldn't have confused so many people. There is absolutely (no pun intended) nothing wrong in using the display:table properties where the layout requires a certain type of structure that can't be easily accomplished by other means (e.g. equal columns, equal rows etc).

You wouldn't usually use it for a whole layout (although there are cases where you can) but for smaller sections where equal columns are needed then they are perfect especially now that IE7 is dropping under the radar and doesn't need to be supported fully (floats will do for ie7).

CSS is for presentation and its use has no effect on the html structure and applies no real semantics to it. Use whatever properties you need to use to create the layout you want in the most accomplished manner.
7:16 pm on Aug 13, 2013 (gmt 0)

WebmasterWorld Senior Member drdoc is a WebmasterWorld Top Contributor of All Time 10+ Year Member



Very well said!
8:11 pm on Aug 13, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Well, that's what I said. A table property doesn't make an element a table. It might have been better to name it something else, as you said, so it may be the reason I feel queasy.
9:24 pm on Aug 13, 2013 (gmt 0)

WebmasterWorld Senior Member drdoc is a WebmasterWorld Top Contributor of All Time 10+ Year Member



I think the problem, too, is that there's that inherent fear of being accused of "using tables for layout" ...

All I'm saying, is -- before resorting to a
table-*
property, it might be worth considering using an actual table, if the data fits.

Now, if we are talking pure formatting, sure, use whatever CSS fits the bill.