[css-position][css-tables] position doesn’t apply on <tr> either

[LeaVerou]

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

[Loirooriol]

Your HTML is invalid. The parser places the div element outside the table. That's why it doesn't seem to work.

[FremyCompany]

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)

[FremyCompany]

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.

[Loirooriol]

So a hacky transform: scale(1) or similar should work, but a standard position: relative shouldn't? This is awful.

[FremyCompany]

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.

[LeaVerou]

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.

[SelenIT]

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

[fantasai]

position: sticky on table rows would be quite useful, fwiw.

[SelenIT]

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

[FremyCompany]

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

[FremyCompany]

Reopening since css-position-3 still needs to be fixed.