Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Having toolbar part of the page flow would simplify a lot of JS, obsolete this whole issue #1440628: [Meta] javascript toolbar/tableheader with url fragment mess. And "fix" this critical #1797438: HTML5 validation is preventing form submit and not fully accessible.
Admin menu has an option to do this, which is I find very handy beside all the JS we can remove thanks to this.
Hopefully, patch soon.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | core-js-toolbar-flow-1797856-8.patch | 2.35 KB | nod_ |
| #2 | core-js-toolbar-flow-1797856-2.patch | 3.8 KB | nod_ |
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedWe have no data to support this, it never came up in testing. But I am intrigued by this, always found it strange and often annoying on intense admin pages.
Comment #2
nod_Quick patch which makes it work. Need some more cleanup probably.
Comment #3
nod_tag
Comment #4
nod_oh and actually,
fixedis crap on mobile.Comment #5
sunSorry, but a strong -1
I do not have data to back up my position, but almost all users expect the administrative toolbar to be sticky.
Where you might be able to make a case is that the core Toolbar is not exclusively designed to be an administrative toolbar (unlike admin_menu). If you want to make that case, then I'll happily let you do so, but I'd kindly request to leave the displace functionality intact.
I also think that the assumption that this would magically fix the displace problem for e.g. sticky table headers & co, is wrong. Whether the toolbar is sticky/fixed or not is irrelevant for the issue that sticky table headers should not overlap the toolbar, and instead appear below it.
Comment #6
nod_I'm asking for feedback here so thanks for joining in :)
I took out the adjustment for the tableheader but the fact is that with or without this patch the fragment thing in the linked issue is still a problem. My problem is not that the sticky header overlap the toolbar (I mean that's working already) but it's more like the fragment thing is messed up. With this patch instead of readjusting the fragment place in all pages, we just need to adjust them if the fragment is pointing to a element inside a table with a sticky header (like the permission page). So that's better. It's not fixing everything it's just fixing most of the things.
The displace thing is still there, you just need to set the TableHeader.offsetTop variable and things will work out well for stickyheaders and all.
Comment #7
nod_Not much feedback so far, anyone else want to chime in?
Comment #8
nod_A really quick and dirty patch to see what it's about.
Also, sooo many position: rules in the CSS it's crazy.
Comment #9
Bojhan CreditAttribution: Bojhan commentedSorry, this was on my follow list. Please use "Needs usability review" that way I prioritise my issues.
I am not sure about removing this, at first I really disliked the toolbar being sticky. But it has significant advantages for editors whom are in a flow of editing content/comments etc, things that often don't take place at the top of the page.
I am all +1 for making it technically better, the sticky headers have been a mess all around. I think we fixed them like 5-10 times now in the D7/D8 cycles.
Comment #10
ry5n CreditAttribution: ry5n commentedJust found out about this. I have mixed feelings: the engineering is always a pain, but I think it would be a net loss for usability. Imagine if your browser tabs scrolled up with the page…
(On the other hand, although it’s not the focus of this issue, I think we could definitely drop sticky table headers. At least we could reduce our “sticky bugfix” budget.)
Comment #11
nod_omg that would be great.
( edit ) #2014309: Sticky table headers default to FALSE
Comment #12
nod_that what happens in no-js mode.