In the propdef for position, it is listed:
Applies to: | all elements except table-column-group and table-column
However, position doesn't seem to apply on <tr>
either, in every UA I tried (Blink, Gecko, WebKit, Edge). Testcase: http://dabblet.com/gist/4c9499df3f578b75a5a777e058e48adf
Your HTML is invalid. The parser places the div
element outside the table. That's why it doesn't seem to work.
Yep. The table elements are associated with a bunch of really terrible parsing rules in HTML. That being said, even with that fixed, Firefox is the only browser that enables position:relative on table rows.
I don't have a strong opinion on whether to allow this or not in the spec, but it does seem somewhat useful (except that, well, you cannot have an element in a table row that is not a table-cell, so any element you insert in a table-row will create second column in your table whether it is position:absolute or not, which is not what you want in this case)
That being said, the table spec currently says:
The position of table-track and table-track-grouping boxes is ignored if its value is relative. User agents that support transform still need to support making these boxes containing blocks if required by spec.
A table-track is either a table-column or a table-row.
So a hacky transform: scale(1)
or similar should work, but a standard position: relative
shouldn't? This is awful.
I think this was discussed at some point and this was the compromise that had been decided. If it was up to me, the text would say even transform shouldn't work. They do not in Edge, so it's not like this would break the web not to support them on these elements.
Your HTML is invalid. The parser places the div element outside the table. That's why it doesn't seem to work.
I used a <div>
to avoid any <td>
-specific stuff, but same thing happens with <td>
s as well.
In Firefox (at least in Win10), with <td>
it seems to work (forked testcase).
But with positioning <tr>
s and other table parts there is a problem that at least two implementations (Edge and Blink) actually don't generate boxes for them. In my opinion, it's rather a bug, because at least the term "row box" is there in the CSS2.x spec, but because positioning table parts (except fixed/sticky positioning of table headers/footers) is not used very often, there was little attention to this issue (except from Mozilla, where they needed that to fix the old annoying bug with positioning things _in_ the cells).
position: sticky
on table rows would be quite useful, fwiw.
@fantasai and it seems already to work in Chrome 65 and Firefox 59.
By the way, the current behavior of position:relative
for table row differs between browsers that implemented it: in Firefox, the height of the row is the height of the .foo
cell, while in Chrome it is the height of the non-positioned cell (with the bar
text). Which one is correct? For me, the Chrome's behavior makes more sense.
@SelenIT The behavior of Firefox looks identical to Chrome's one here. The difference of rendering is due to Gecko's different method for computing the "outline rect" of an element (they union the rect of the element with all the rects of its descendants, including the position:absolute element, while Chrome and Edge use a the border box directly in cases like this).
Reopening since css-position-3 still needs to be fixed.
Here's an example page where position: relative;
is applied to some table cells in order to position elements inside them on mobile resolutions.
In this case it is expected that the table cells are displayed the same way as if position: static;
was applied (i.e. like in Blink, not like in Gecko):
https://www.gamestar.de/artikel/call-of-duty-modern-warfare-systemvoraussetzungen-auf-dem-pc-geprueft,3350489.html#minimale-systemvoraussetzungen
Reduced example:
data:text/html,<table><tr><th>a</th><th>b</th><th>c</th></tr><tr><td>a</td><td>b</td><td>c</td></tr></table><style>table{border-collapse:collapse;}th,td{border:4px solid black;background-color:wheat;}th{position:relative;}</style>
Sebastian
As far as we can tell, the Position 3 text got fixed as part of our rewrite; the clumsier text from the previous draft is gone. Let us know if we're wrong, otherwise I'm closing this since Tables was fixed earlier.
Most helpful comment
So a hacky
transform: scale(1)
or similar should work, but a standardposition: relative
shouldn't? This is awful.