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.

#8 core-js-toolbar-flow-1797856-8.patch2.35 KBnod_
PASSED: [[SimpleTest]]: [MySQL] 56,354 pass(es). View
#2 core-js-toolbar-flow-1797856-2.patch3.8 KBnod_
PASSED: [[SimpleTest]]: [MySQL] 41,697 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Bojhan’s picture

We 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.

nod_’s picture

Status: Active » Needs review
3.8 KB
PASSED: [[SimpleTest]]: [MySQL] 41,697 pass(es). View

Quick patch which makes it work. Need some more cleanup probably.

nod_’s picture

Issue tags: +JavaScript clean-up


nod_’s picture

Issue tags: +mobile

oh and actually, fixed is crap on mobile.

sun’s picture

Sorry, 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.

nod_’s picture

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.

nod_’s picture

Not much feedback so far, anyone else want to chime in?

nod_’s picture

2.35 KB
PASSED: [[SimpleTest]]: [MySQL] 56,354 pass(es). View

A really quick and dirty patch to see what it's about.

Also, sooo many position: rules in the CSS it's crazy.

Bojhan’s picture

Sorry, 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.

ry5n’s picture

Just 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.)

nod_’s picture

omg that would be great.

( edit ) #2014309: Sticky table headers default to FALSE

nod_’s picture

Status: Needs review » Closed (works as designed)

that what happens in no-js mode.