New issue
Advanced search Search tips
Starred by 26 users
Status: Fixed
Owner:
Closed: Dec 2
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
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.
Sign in to add a comment