homepage Welcome to WebmasterWorld Guest from 54.204.127.191
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

    
relative positioning + display as table cell
Firefox doesn't play nicely.
Setek




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

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?

 

DrDoc




msg:4601201
 7:17 am on Aug 12, 2013 (gmt 0)

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.
Setek




msg:4601203
 7:23 am on Aug 12, 2013 (gmt 0)

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.

:)

DrDoc




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

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.
swa66




msg:4601242
 9:49 am on Aug 12, 2013 (gmt 0)

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.

Paul_o_b




msg:4601249
 11:35 am on Aug 12, 2013 (gmt 0)

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).

drhowarddrfine




msg:4601286
 1:54 pm on Aug 12, 2013 (gmt 0)

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.

Setek




msg:4601444
 4:57 am on Aug 13, 2013 (gmt 0)

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!

Paul_o_b




msg:4601593
 7:10 pm on Aug 13, 2013 (gmt 0)


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.

DrDoc




msg:4601595
 7:16 pm on Aug 13, 2013 (gmt 0)

Very well said!

drhowarddrfine




msg:4601610
 8:11 pm on Aug 13, 2013 (gmt 0)

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.

DrDoc




msg:4601628
 9:24 pm on Aug 13, 2013 (gmt 0)

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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved