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

[SebastianZ]

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

[tabatkins]

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.

[atotic]

Just FYI: Chrome 91 will fix posiiton:relative for TR/TBODY.

[FremyCompany]

Wonderful @atotic !

[renatodeleao]

For those who end up here from googling, the workaround using transform or any other stacking context creator property (will-change: transform, isolation: isolate) unfortunately does not work in Safari (<=14.0.3 and Technology Preview).

[renyuns]

For those who end up here from googling, the workaround using transform or any other stacking context creator property (will-change: transform, isolation: isolate) unfortunately does not work in Safari (<=14.0.3 and Technology Preview).

In Safari(14.0.1), tr not support position: relative, td supported

[nichita-pasecinic]

So are there any good solution of how to position absolute something in inside a tr (an :after or :before for example) ?
In Chrome works fine with just position property, though the Safari still has the issue

[SebastianZ]

For what it's worth, a related bug report for Safari/WebKit is https://bugs.webkit.org/show_bug.cgi?id=240961.

Sebastian

[Amooryjubran]

The position: relative; issue is still happening with Safari, but it works well on Chrome, Firefox. Opera, and Edge.
I guess I'll have to restructure my code.

Thanks for the link @SebastianZ

[lozcalver]

For those who end up here from googling, the workaround using transform or any other stacking context creator property (will-change: transform, isolation: isolate) unfortunately does not work in Safari (<=14.0.3 and Technology Preview).

If your only issue is absolutely positioned elements overflowing the table-row (e.g. absolutely positioned anchors to make a full row clickable), another possible workaround is to use tr { clip-path: inset(0); }. It causes some strange paint side-effects in Safari, like borders sometimes disappearing, but it does at least clip child elements as expected.

[andylacko]

my only solution is as usual to disable the row highlight on safari 🤷‍♂️

[BillyG83]

I worked on this and found it easier to make a 100% different UI for Safari. None of the fixes above worked for me using Safari Version 15.6

[Techn1x]

Seems you can create a stacked context in Safari 16.5.1 on these elements via transform eg transform: translate(0px). Note I only tried this on tbody elements as that is where I was having the issue, but I bet it'd work on tr's as well.

Everything else still doesn't work, but my god it's something.

[HonzaKopecky]

From my tests and few hours of research, it seems that position: relative works on all major browsers but there are two exceptions:

• Safari on macOS needs the transform: translate(0) hack.
• Both Safari and Chrome on iOS don't work and the hack doesn't help either.

Wrapping the absolute element in a relative one obviously works but then you cannot achieve the goal of the element rendering in context of the row instead of a cell.

[AlexanderDom]

If you apply float on tr, position relative works normally, just need to clean floating for trs

[Loirooriol]

Float blockifies, so the tr stops being a row and you break the table grid. https://drafts.csswg.org/css2/#dis-pos-flo

[AlexanderDom]

Float blockifies, so the tr stops being a row and you break the table grid. https://drafts.csswg.org/css2/#dis-pos-flo

Thanks for your link i know what float does, i propose a solution that work for position problem as like transform solution, i didnt say it was perfect