There are several issues for various components that all come down to bad integration with each other. We have:
- toolbar: this adds a fixed element at the top of the page for links,
- tableheader: it allows a table header to stick at the top of the page while we're scrolling over a table,
overlay: adds an iframe on top of the current page to display administrative pages without getting the user lost in admin (it doesn't use AJAX!),
now removed from D8- url fragment: a 30 or so years old technology that allow a link to refer to a specific part of an HTML page using an element's id
Over the year we managed to break pretty much everything at different levels.
toolbar + tableheader: both stick elements on top of the page. Elements which overlaps. instead of fixing this all on the js-side, PHP and a javascript eval got involved to compute the offset required to display tableheader properly under toolbar. #1417378: Remove eval() from tableHeader JavaScript.fixedtableheader + overlay: it works, but not like it should,fixedtoolbar + tableheader + overlay: Since the PHP+eval thing for toolbar did not account for the creation of the overlay module, overlay had to override the function to add it's own value that adds an offset to properly display tableheader under the toolbar, inside the iframe. The fix isn't actually needed — because (for the people who had to deal with this)fixed, using a listener on the 'offsettopchange' event to update the CSS inside the overlay. Some jQuery trickery was needed.topOffset
is always undefined, what is defined is<strong>parent</strong>.Drupal.overlayChild.prevTableHeaderOffset
because it's in an iframe.
#787670: Clean up tableheader.js interesting stuff in there.- tableheader + fragment: the browser will scroll so that the element with the targeted id shows up at the top of the screen. If you have elements set with
position:fixed
the fragment targets is hidden behind. #567754: Wrong anchor adjustment in tableheader.js overlay + fragment: now this is totally broken, since bqq used for ajax bookmarking of admin url uses the # to store the state, it completely override what it was supposed to do and it's not even trying to scoll to the right element. The fragment information is still available but that requires to be processed "by hand" #1129578: Overlay doesn't respect internal anchor links.- toolbar + fragment: this patch is supposed to fix it #546126: Toolbar interferes with anchor links but it does not work.
- Now: toolbar + tableheader + overlay + fragment should be working but right now every piece of the chain is broken somehow.
I didn't really want another meta but we need to take a step back from this mess and come up with a clean solution that doesn't involves PHP.
I think #787940: Generic approach for position:fixed elements like Toolbar, tableHeader should be put back on track and simplified as much as possible, perhaps taking the fragment part to an other issue.
Anyway what is certain is that this all need to be though as a whole and a generic solution needs to be found that allow easy opt-in for contrib while not messing up the 30 years old fragment feature. There are two main issues, fragment focus in the different situations, and having a way to compute an offset for tableheader that doesn't invlove PHP, eval or monkey-patches.
If you feel this would be better as a summary in #787940: Generic approach for position:fixed elements like Toolbar, tableHeader just tell me I'll (or anyone :) update the summary there and close this. I felt like a new thread would scare people less compared to a 2+ year issue with nearly a hundred reply. If this one is closed all the other issues linked here should be closed too.
And seeing the state of this thing, that's a bug, not a feature request.
Related:
Comments
Comment #3
nod_tagging
Comment #3.0
nod_add related
Comment #4
nod_Less obnoxious issue summary.
Comment #5
eigentor CreditAttribution: eigentor commentedOh yeah this is still very much valid.
Evertime I go to the permissions page using a direct link I get reminded of this not working, cause the scrolling does not take toolbar into account.
Comment #6
nod_When there is an error during form validation, an HTML5 browser will focus on the error field, and the toolbar gets in the way.
Comment #7
cosmicdreams CreditAttribution: cosmicdreams commentednod_: I just wanted to point your attention to a possible alternative for sticky table headers: http://updates.html5rocks.com/2012/08/Stick-your-landings-position-stick...
A little internet research didn't uncover any examples that used this technique for tableheaders but it's worth a try.
Comment #8
nod_Indeed, someone pointed it out to me a
couple weeks agolast week (time flies).The current tableheader implementation is doing waaay less work on scroll than it used to do. And we should be using a debounce function for this kind of things anyway. Will definitely be interesting once it's supported by *cough* IE or a decent polyfill is around.
Comment #9
cosmicdreams CreditAttribution: cosmicdreams commentednod_: that was also me. I did a search for a display: sticky polyfill and found this: http://codepen.io/FWeinb/pen/xLakC
I bet there's a better one but this seems pretty concise.
Comment #10
seutje CreditAttribution: seutje commentedSome quick analysis leads me to believe
position:sticky;
doesn't even try to solve the anchor problem, it seems like it's just a conditionalposition:fixed;
with less flexibility on the positioning...Comment #11
evanbarter CreditAttribution: evanbarter commentedI just ran in to the issues with displacement while working on a custom module so I'll start tracking this and see if there's anything I can help out with. I took a look at #787940: Generic approach for position:fixed elements like Toolbar, tableHeader and my brain melted, so maybe we do need to refocus.
Comment #11.0
evanbarter CreditAttribution: evanbarter commented"Without the extreme sarcasm"
Comment #12
nod_1, 2, 3) have been fixed by other patches.
We now have a offsettopchange event, and
data-offset-top
attribute used to compute the total top offset. Interesting code is in tableheader.js.Comment #13
nod_New toolbar, same issues some related changes in the JS though :D
#1846970: [meta] Responsive Toolbar follow-ups
Comment #14
nod_Trying to address 4 and 6 in #1870006: HTML5 validation with table sticky header is misaligned over the toolbar
Comment #14.0
nod_update with current status.
Comment #15
cosmicdreams CreditAttribution: cosmicdreams commentedComment #16
cosmicdreams CreditAttribution: cosmicdreams commentedNow that Overlay is gone, how does is this issue impacted?
Comment #17
nod_Pretty much like that.
A good thing is that tableheader is not much of an issue anymore since it's disabled by default, only the permission table uses it.
Comment #18
LewisNyman CreditAttribution: LewisNyman commentedComment #19
mgiffordComment #20
Manuel Garcia CreditAttribution: Manuel Garcia commentedComment #21
SKAUGHT[removed]
Comment #22
SKAUGHTComment #23
SKAUGHTsorry, i see my cross post may not related in the same way..
Comment #24
SKAUGHTComment #28
nod_Comment #29
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedtagging accessibility, highly relevant to sighted keyboard-only users.
Comment #35
nod_toolbar+tableheader+fragment and the rest is fixed by #1870006-65: HTML5 validation with table sticky header is misaligned over the toolbar.