New issue
Advanced search Search tips

Issue 695179 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

'position: sticky' should not be allowed on <thead>, <tr> for CSS 2.1

Project Member Reported by smcgruer@chromium.org, Feb 22 2017

Issue description

The position:sticky spec states that:

"The effect of ‘position: sticky’ on table related elements is the same as for ‘position: relative’."

In CSS 2.1, position: relative is not allowed on <thead> and <tr>:

"The effect of position:relative on table-*-group, table-row, table-column, table-cell, and table-caption elements is undefined."

As such, we should disallow sticky on <thead> and <tr> at the moment.

In CSS 3, position: relative does have a definition for <thead> and <tr> and as such position: sticky is supported. However Blink currently implements CSS 2.1 and the code does not neatly allow for position: sticky support on top of it. (For example, the locationContainer() for LayoutTableCell is wrong for CSS 3).
 
Status: Fixed (was: Assigned)
I'm sorry but I'm really confused. This feature is working just fine in Chrome 56. You say it'd be "difficult to implement" but it's already implemented. Why are you spending extra work to remove a feature you already support?
Apologies, I should have been more clear. You are correct that, in a vacuum, position:sticky on a <tr> in Chrome 56 does work. Unfortunately however this falls apart in the case of nested sticky elements ( issue 672710 ), e.g. if sticky is specified on more than one of the <thead>, <tr>, and <th>, or on any of them and on an ancestor element.

When sticky elements are nested like this, we need to compute the correct offsets on the descendant sticky elements with respect to any sticking shifting done to their ancestors. This is where things start to fall apart for <tr> and <thead>. Tables are weird, and their container() and containingBlock()s are not what one might expect, and Blink only has what support is required for CSS 2.1. CSS 3 specifies how tables work with respect to positioned elements more clearly, so in the future when we have that support we will be able to correctly compute things for nested sticky.

I hope that helps. I understand it's not the best outcome we could have hoped for, and definitely something we want to fix once the Blink support is there, but there is the workaround of just making the <th> sticky instead of the <tr> or <thead>.
I see. That makes sense. "position: sticky" should work fine on <th> then which is all I need it for.

Thanks for the quick response.

Sign in to add a comment