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

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. 

See also: https://codereview.chromium.org/2786743002/ and Issue 417223

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 :(.

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

Wow, I didn't even notice that the blocking bug had been fixed (woo!). Thanks Rob, this is awesome :)

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.

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.

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

commit 7f7beb7dc8691f39a273aaa3f0915fabe3ceee50
Author: Robert Hogan <robhogan@gmail.com>
Date: Wed Nov 29 18:59:46 2017

Fix position:sticky on nested table parts

Bug: 702927
Change-Id: Ifeaa89a292e96bb66a26507ab85cf4e3a81d42c4
Reviewed-on: https://chromium-review.googlesource.com/786014
Commit-Queue: Robert Hogan <robhogan@gmail.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520181}
[add] https://crrev.com/7f7beb7dc8691f39a273aaa3f0915fabe3ceee50/third_party/WebKit/LayoutTests/external/wpt/css/css-position/position-sticky-table-parts-ref.html
[add] https://crrev.com/7f7beb7dc8691f39a273aaa3f0915fabe3ceee50/third_party/WebKit/LayoutTests/external/wpt/css/css-position/position-sticky-table-parts.html
[modify] https://crrev.com/7f7beb7dc8691f39a273aaa3f0915fabe3ceee50/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp

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.

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

commit 26531bbaff4aac1b026b4f908085d5d5014d9ec0
Author: David Grogan <dgrogan@chromium.org>
Date: Fri Jan 19 21:37:14 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-Commit-Position: refs/heads/master@{#530620}
[modify] https://crrev.com/26531bbaff4aac1b026b4f908085d5d5014d9ec0/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/26531bbaff4aac1b026b4f908085d5d5014d9ec0/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
[modify] https://crrev.com/26531bbaff4aac1b026b4f908085d5d5014d9ec0/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/26531bbaff4aac1b026b4f908085d5d5014d9ec0/third_party/WebKit/Source/core/layout/LayoutTableRow.h

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

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.

No current work is happening by me on sticky for <thead>, dropping to Available.