New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 39 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 417223


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

position: sticky does not work on <thead> or <tr>

Reported by gwhi...@gmail.com, Mar 18 2017 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3045.0 Safari/537.36

Steps to reproduce the problem:
1. Open https://jsfiddle.net/hr5dktah/1/
2. Scroll down past the thead on the inner scroller

What is the expected behavior?
The thead should stick to its parent scroller, thus the innerscroller.

What went wrong?
It does not, it stays in place as though position: sticky was not set.

Did this work before? N/A 

Does this work in other browsers? No
 In Chrome Stable 56 this testcase works where the thead will stick to the scroller. In Canary it does not.

Chrome version: 59.0.3045.0  Channel: n/a
OS Version: 10.0
Flash Version: 

I noticed that there has been some compositor work done for position sticky in the past few weeks. And while I don't think they should be related I thought I'd call attention to them: https://codereview.chromium.org/2733633002/
 
Cc: flackr@chromium.org
Owner: smcgruer@chromium.org
Status: WontFix
This is working as intended as per  issue 695179 .

For tables, position: sticky defers to the position: relative spec. At this time, Blink only supports CSS 2.1 for positioned elements, and the position: relative CSS 2.1 spec says that it does not apply to <thead> and <tr> elements.

Until Blink supports CSS3 positioning, I don't think we can properly support sticky on <thead> and <tr>, as it would require (from memory) changing the definition of container() for those elements (and for <th>).

For a CSS 2.1 compliant workaround, you should be able to apply sticky to the <th> elements and it should work properly.

+flackr as an FYI and in-case he wants to disagree with anything I wrote :).

Comment 2 by gwhi...@gmail.com, Mar 24 2017

Sounds good - this is similar to what we were discussing regarding this as position in general doesn't work on rowgroups/colgroups or columns. Thanks for the info.
I had been looking forward to this, to use it to implement fixed/floating headers for very large tables on wikipedia. Unfortunately, this problem still causes sticky positioning with Chrome to be highly suboptimal.

The problems is that on Wikipedia we have many tables with multi row table headers, and having to target the individual cells with the same (top) offset, causes them to overlap in that case...

Really a shame, considering the fact that this just works on iPhones for years already... I appreciate all the potential problems that developers run into, but please also consider that I just want to stop using JS for shit like this and half-ass implementations for it might as well not exist at all..

Current, partial, implementation of table headers with sticky:
https://en.wikipedia.org/wiki/MediaWiki:Gadget-StickyTableHeaders.css

Example page with 3 tables that could use this behaviour
https://en.wikipedia.org/wiki/List_of_Space_Shuttle_missions?withCSS=MediaWiki:Gadget-StickyTableHeaders.css

Note the 3rd table beneath Flight statistics, has a multirow header.

Note also that with any sticky implementation (including Safari's actually), there is a real problem with borders, which seem impossible to create, in any sane way. 
Blockedon: 417223
Labels: -OS-Windows -Pri-2 OS-All Pri-3
Status: Available
Summary: position: sticky does not work on <thead> or <tr> (was: position: sticky not working on thead)
After the discussion on that code-review I'm re-opening this bug and marking it blocked on Issue 417223. This is so we have a record of why sticky doesn't work or <thead> or <tr>, as well as linking that bug to the consequences of Blink's lack of support for CSS 3.

Sadly I will also have to de-prioritize to P3 since issue 417223 is also P3 :(.
Labels: Hotlist-Interop
Owner: ----
Labels: Update-Quarterly
Cc: smcgruer@chromium.org
Components: -Blink>CSS Blink>Layout
Project Member

Comment 10 by bugdroid1@chromium.org, Nov 17

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ca3ed70409f9945d3f215fb296fd3628e1989a7c

commit ca3ed70409f9945d3f215fb296fd3628e1989a7c
Author: Robert Hogan <robhogan@gmail.com>
Date: Fri Nov 17 13:20:10 2017

Implement position:sticky for table parts

Bug: 702927
Change-Id: I9972f82a8d2b560042b0acbd8484eed5f76f6f2e
Reviewed-on: https://chromium-review.googlesource.com/772412
Commit-Queue: Robert Hogan <robhogan@gmail.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517390}
[modify] https://crrev.com/ca3ed70409f9945d3f215fb296fd3628e1989a7c/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/ca3ed70409f9945d3f215fb296fd3628e1989a7c/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp

Status: Fixed
Wow, I didn't even notice that the blocking bug had been fixed (woo!). Thanks Rob, this is awesome :)
Cc: -smcgruer@chromium.org
Owner: smcgruer@chromium.org
Status: Assigned
I'm opening this up again temporarily to investigate whether this has actually fixed the issue where tables in Blink don't properly specify their containing block. I thought we had a test case for that, but don't immediately see it.
Cc: robho...@gmail.com
Hi smcgruer, do you have an example of what you mean? I'm not aware of tables having issues determining their containing block. Table cells are ambiguous on that front, and each of the browsers has a different opinion on what constitutes a cell's containing block.
The issue was that a sticky table head and row offsets the table cell, but the table cell is contained by the table so it isn't aware that it has already been shifted and gets shifted again. I.e. you can see the issue with http://output.jsbin.com/wutami/quiet

This is indeed still broken.
Status: Fixed
In which Chrome version will the fix land?
64!
Thanks!
So what is the expected behaviour for border collapse here ?

Because when i set sticky to <thead> in these examples:
https://en.wikipedia.org/wiki/List_of_Space_Shuttle_missions?withCSS=MediaWiki:Gadget-StickyTableHeaders2.css

I seem to lose all borders inside of the <thead>.

Forgot to mention, I tested that with Canary 65.0.3284.0
For border-collapse: collapse and position: relative, the expected behaviour (or at least browsers' de facto standard) is that positioned cells with their backgrounds are moved out of the borders grid; visually, this results in the positioned cells losing their borders.

For position: sticky, I think browsers follow the same rule.

The idea is that, if borders are collapsed, the borders grid belongs, so to speak, to the table rather than individual cells.

This is not specific of this bug, it also happens if you set position: relative or sticky on td or th.
Cc: dgro...@chromium.org
Status: Assigned
Project Member

Comment 25 by bugdroid1@chromium.org, Jan 22

Labels: merge-merged-3325
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/45b8832bc8dbabde7ef524cc4d8344db64a8ad68

commit 45b8832bc8dbabde7ef524cc4d8344db64a8ad68
Author: David Grogan <dgrogan@chromium.org>
Date: Mon Jan 22 19:37:02 2018

[css] Revert relpos and sticky table elements

This reverts the logic, but not tests, from:

7f7beb7dc8691f39a273aaa3f0915fabe3ceee50
ca3ed70409f9945d3f215fb296fd3628e1989a7c
842ea8f45240e700e448ae9bcd4ca65dc9596079

The bottom caused netflix to render wrong, the top 2 were built on the
bottom.

Bug: 417223,702927,798164
Change-Id: Icb350aa0ea385937294040ce681345e3314da0e2
Reviewed-on: https://chromium-review.googlesource.com/875015
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#530620}(cherry picked from commit 26531bbaff4aac1b026b4f908085d5d5014d9ec0)
Reviewed-on: https://chromium-review.googlesource.com/879381
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#20}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/45b8832bc8dbabde7ef524cc4d8344db64a8ad68/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/45b8832bc8dbabde7ef524cc4d8344db64a8ad68/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
[modify] https://crrev.com/45b8832bc8dbabde7ef524cc4d8344db64a8ad68/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/45b8832bc8dbabde7ef524cc4d8344db64a8ad68/third_party/WebKit/Source/core/layout/LayoutTableRow.h

Project Member

Comment 26 by bugdroid1@chromium.org, Jan 22

Labels: merge-merged-3282
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/33966f17f033002013ff0bec1c77847c52a64405

commit 33966f17f033002013ff0bec1c77847c52a64405
Author: David Grogan <dgrogan@chromium.org>
Date: Mon Jan 22 20:04:11 2018

[css] Revert relpos and sticky table elements

This reverts the logic, but not tests, from:

7f7beb7dc8691f39a273aaa3f0915fabe3ceee50
ca3ed70409f9945d3f215fb296fd3628e1989a7c
842ea8f45240e700e448ae9bcd4ca65dc9596079

The bottom caused netflix to render wrong, the top 2 were built on the
bottom.

TBR=dgrogan@chromium.org

(cherry picked from commit 26531bbaff4aac1b026b4f908085d5d5014d9ec0)

Bug: 417223,702927,798164
Change-Id: Icb350aa0ea385937294040ce681345e3314da0e2
Reviewed-on: https://chromium-review.googlesource.com/875015
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#530620}
Reviewed-on: https://chromium-review.googlesource.com/879347
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#570}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/33966f17f033002013ff0bec1c77847c52a64405/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/33966f17f033002013ff0bec1c77847c52a64405/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
[modify] https://crrev.com/33966f17f033002013ff0bec1c77847c52a64405/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/33966f17f033002013ff0bec1c77847c52a64405/third_party/WebKit/Source/core/layout/LayoutTableRow.h

Does it mean the bug is *not* fixed in v64. I tested it with the chrome Beta WebView Implementation and it already worked for me in December, but not anymore. 

Can we expect to get it fixed soon? Then I patiently wait for it.
My current understanding is that robhogan@ attempted to fix both relative and sticky positioning on table rows, believing the Blink support to be there. However it turned out that this caused Netflix to render incorrectly (see issue 798164). The fix from robhogan@ was reverted and that revert merged all the way back to M64 to avoid breaking Netflix.

The root bug here to track is issue 417223; until Blink has the proper support for relative postioning for table rows, there isn't much we can do :(. I'm afraid I don't have any idea of whether that'll be fixed soon.
+1 to comment 28. To make more concrete, vygen, you are correct that it worked in December's beta releases but is not fixed in v64 stable.

It's unclear when it will be fixed. In addition to the netflix breakage, we need to check out https://bugs.chromium.org/p/chromium/issues/detail?id=417223#c13 -- we might have broken some collapsed border cases.
Do you think we need to discuss this in the CSSWG? I think this is a feature that most folks creating sticky headers will want so I'd prefer to keep the spec as is and we just update our implementations, did you all reach out to Netflix to have them address the code on their end?


I also think this is a good feature and should stay in the spec. The problem wasn't on Netflix's site; our implementation was broken and netflix.com was the first we heard that exposed it.

I'm not sure when anyone will be able to make a second attempt.
As a web developer, th is work like:
th {
  position: sticky;
  z-index: 1000;
}

But setting on thead is more intuitive, because I want to let the first row sticky.

Sign in to add a comment