Input elements overlap sticky tableheader

This occurs because the date module wraps each section in a fieldset and the Seven theme adds position: relative; to the fieldsets. This means that anything inside a sticky enabled table with position: relative; is going to have a z-index issue with the table header. This patch is non-dangerous and fixes this potentially rampant z-indexing issue. RTBC.

Only Bartik and Seven exhibit this behavior...

Actually no, many themes and modules may add position relative to fieldsets or whatever else (some of my D7 themes do this also), so my thinking is this should go into system.base.css.

This is a fairly innocuous change (adding z-index to table.sticky-header), so my thinking is this could basically go strait into D7 and I would also support the patch in #3.

Leaving as needs review because it should have broader testing (I seriously doubt anything is going to break because of this but best to play it really safe at this stage).

+1

The addition of "z-index" also fixes a problem in the Flag module, whose links are by default "position: relative" and thus overlap the sticky table header.

(The comment in the CSS says "However, fieldsets using position: relative still overlap sticky headers." I suggest it be changed to "However, elements that use 'position: relative' (most notably fieldsets) still overlap sticky headers" because the problem isn't specific to fieldsets.)

This is good to go :).
As a few people mentioned we have to fix this in core to overcome problems with position:relative with fieldsets in core and with other elements in contrib.

D8 first. Let's get these fixed on D8 and into D7.

I don't see how something can be RTBC for D8 if it hasn't been tested by the testbot and tried out there....

The code should explain in a comment why z-index 1 and not higher or lower. Table headers do use a higher z-index normally, right? Also, if this quirk applies to certain browsers/versions only, then mentioning those wouldn't hurt either. Place that comment right above the z-index line.

Thanks! Though now you slightly went overboard with those comments.

Attached patch hopefully clarifies why it's extremely helpful and necessary to properly document the non-obvious.

Please do not complain about the syntax of the comment. We don't have a coding standard for CSS comments yet, and it's particularly hard to draw a conclusion, because there are no solid examples, and CSS syntax doesn't make it easy either. If you want to help, see you over in #748810: CSS Coding Standards: Comments. Until that issue is resolved, this comment style made most sense for me in this particular situation.

Drupal is a modular system, but it doesn't have any defined rules for modular element positioning in the viewport.

The default is obviously 0 and regular stacking depends on the markup order in the DOM. A module may add a form element with an advanced layout that should still be rendered below sticky table headers. A theme's layout/design may be based on absolute or relative positioned elements, but sticky table headers should still appear on top. Yet another module may add an absolute or fixed positioned element to the viewport, which always be on top. Some arbitrary examples:

Toolbar uses 600, Overlay uses 500, Contextual links use 999, Administration Menu uses 999, Views UI contextual/admin links use just 50, Autocomplete uses 100.

Using 1 would mean that other potentially positioned elements may still be rendered above sticky table headers when scrolling. Using 100 gives modules and themes sufficient room to position other elements. It's possible that the added comment doesn't sufficiently clarify this, so feel free to re-word it.

It's badly time for designers and themers to have a discussion on setting up formal rules for dividing the viewport into z-axis layers. Otherwise, the only viable solution in a modular system would be usage of JavaScript to apply appropriate z-indexes for all elements, but requiring JS for CSS layout is obviously a bad idea. We should have this discussion as soon as possible (in a separate issue).

#34: drupal.system-sticky-tableheaders.34.patch queued for re-testing.

I don't think the sticky header is there anymore, at least, not in the example from the initial screenshot. Tested in Seven and Claro but the field label is not sticky:

If anyone knows how to get a sticky label, please update the issue with steps to reproduce and set it back to Active.