Csswg-drafts: [css-positioning-3] Sticky positioning for table elements

[Nadya678]

https://www.w3.org/TR/css-position-3/#sticky-pos

The sticky will not work with <thead/>, <tr/> (table-rows), <th/> etc. I need it here! For always visible header if i scroll table right or down. Without any script. This will very helpful a big tables.

The effect of position: sticky on table elements is the same as for position: relative

In my opinion this sentence should be removed and the behaviour for all elements (and display values) should be the same.

[SelenIT]

Please refer to the current Editor's draft of the spec since the published version you referred to may be rather outdated.

AFAIK, the spec doesn't say that either relative or sticky position _should_ not work for table internal elements. On the contrary, it specifies their behavior for relative positioning, and implies that sticky positioning for them should behave similarly (i.e. only for table columns and column groups the positioning should be ignored, other table parts should be offset relatively to their normal position in the table, and cells spanning several rows/columns should be shifted as a whole).

So not supporting either relative or sticky positioning for table parts is just a bug of the browsers. It is already marked as fixed for Chrome 65 and Firefox 59.

[Nadya678]

Thank you for clearing the problem. Also MDN refers to old specification.
The table cannot be scrolling box.

table{display:block; overflow:hidden}
tbody{display:table} 
th
{
   position:sticky;
   left:0; 
   top:0; 
   right:0; 
   bottom:0
}

will work for me after implementation?

BTW. position:relative works in Firefox 52 also for table-cell and table-row elements. The Chrome 63 has problem here.

[SelenIT]

Yes, it should work. I just tested this Codepen in Chrome Canary 65, and it worked for me (with both thead and tr elements).

UPD.: with th elements, it works even in the stable Chrome 63.

[Nadya678]

I think the problem is resolved. I have big problems with script version of table headers. The tables are loaded dynamically (XMLHttpRequest) and if the scrollbar appers the header is broken without possibility of use sticky.

But it is sad, the sticky NEVER will be work in IE11 (Windows 7 and Windows 8.1) users cannot upgrade itt to EDGE. They pay for their system but big "no" from M$ to allow them use EDGE. Disguisting policy of M$...

UPD.: with th elements, it works even in the stable Chrome 63.

I know the annoying problem of relative positioned table and table-cells (probably also for sticky) in the same time. It is ONLY correctly displayed but clicks in the gap between cells or above or below the first/last cell if cell contains active elements works very badly. I know solution for it but the functionality is weak tested. I use Chromium 63 for webpage test during development. Only. Firefox is better IMO.

[SebastianZ]

Also MDN refers to old specification.

I've updated the description of sticky on MDN to reflect that it also applies to table-related elements.

But it is sad, the sticky NEVER will be work in IE11 (Windows 7 and Windows 8.1) users cannot upgrade itt to EDGE.

Microsoft offered a free upgrade to Windows 10 for several years (which just ended a few days ago). So people had enough time to make the switch. Anyway, that's off-topic.

Sebastian

[Nadya678]

Microsoft offered a free upgrade to Windows 10 for several years.

The Windows 10 is the greatest evil due to privacy policy of this version of system. Please read the Policy prvacy of the M$ with "More" sections. Better solution is to change IE11 to Moz.

[jonjohnjohnson]

Guessing this issue can be closed now? As far as implementor direction, it seems table elements can use sticky positioning.

[SelenIT]

It seems that for some reason Chrome reverted their changes for fixing position:sticky behavior on thead element.

[tobiu]

I can confirm that position: sticky is broken in Chrome for thead right now.

A quick question if I may: Should position: sticky enable a html table to support sticky column headers (sticked to the top) as well as locked columns (sticked to the left)?

It would be really nice in case there was a way to not use 2 tables and sync their scroll states.

For this use case, the scrollers have 2 issues:
1) there is a gap of around 10px to the bottom and right (this works in FF)
2) it would be nice if the scrollers would honor the "scrollable" area in a better way for tables with sticky items

I just tested it here:
https://codepen.io/anon/pen/XBojGp

[jonjohnjohnson]

@tobiu Here is a screencast of your demo in chrome canary 70.0.3516.0 on my macOS 10.12.6 where it shows an implementor allowing sticky positioned elements nested to share the outermost containing block, enabling an "html table to support sticky column headers (sticked to the top) as well as locked columns (sticked to the left)". This shows that you shouldn't need two synced scrollers I believe?

http://cl.ly/0i1w2P0J3x0Q

[tobiu]

@jonjohnjohnson the demo looks exactly the same to me. If you look close at your video, you will see the scrollbar offset to the bottom and right edge (10-20px i guess), there is no offset for top and left. you do see the full content when you scroll though. This gap is not present in FF.

from an UX perspective it would be nice, if the scrollers would exclude the sticky elements inside tables completely (e.g. the x-scrollbar would start after the last locked column).

Best regards and thx for looking into it!

[jonjohnjohnson]

Oh your first part isn't related to elements using a sticky position scheme. You may want to make another ticket vying "overlay" scrollbars to share the space where both of their tracks meet?

Safari also allows, like you say in firefox, for "overlay" scrollers that don't take up place in the box tree to share that space.

Aside from that, I don't think any implementor would be interested in making scrollbar placement something that is inferred from "stuck" (sticky positioned) elements dimensions/offset. Though, it could be worth starting a topic for the https://drafts.csswg.org/css-scrollbars-1/ spec to support explicitly offsetting the start/end edges of a scrollbars track inside a scrollport? http://output.jsbin.com/qunekib/ is a prime example for that feature, because of how sticky positioned containing blocks behave, an offset "scrollport" has to be faked to allow these nested/sequenced sticky elements.

[tabatkins]

Closing since stickypos does work on internal table elements.

[fantasai]

Follow-up issue in https://github.com/w3c/csswg-drafts/issues/5020