Toolbar styling is easily disrupted by theme CSS. [#2987665]

Problem/Motivation

Toolbar module has styling intended to give a consistent appearance, no matter which theme is active, so that it appears the same on the website's front end and admin pages.

However, the CSS rules from custom themes can easily leak into the toolbar, breaking the toolbar appearance in unexpected ways.

Specific problems/workarounds encountered so far:

Bartik uses border-bottom to underline links, instead of the usual text-decoration. This has the side effect of adding a border to each toolbar link, so Bartik has extra toolbar CSS to avoid this.
Umami's hover style colours leaked into the toolbar, causing low-contrast text. Details in #2941647: Link hover styles unintentionally applied to administration toolbar.
Toolbar text uses a sans-serif font, but Umami's serif font styles leaked into the toolbar. Details in comment #6 and #9 here, and also comments #40-43 in #2983568-40: Audit and improve focus styles across the Umami theme for logged out users. Umami has encountered this regression several times.

Since two core themes have clashed with toolbar stlying already, it's a safe bet that other themes will encounter problems like these too. The admin-UI initiative has started their theme refresh, so that seems a likely place where this will crop up again.

It would be great if theme maintainers didn't have to worry about this happening so much. Distribution (and profile) maintainers in particular will want to avoid breaking toolbar styles, to remain attractive to users (e.g. many have demo videos/sandboxes, or form the basis of a product).

Proposed resolution

Can we make the CSS in Toolbar module more resistant to problems like this?

Remaining tasks

TBD.

User interface changes

None.

API changes

None.

Data model changes

None.

Original report

This issue was originally about fixing the serif-font problem that Umami encountered. The issue was re-scoped once we realized it was a more general problem that several core themes have run into.

Comment	File	Size	Author
#9	umami-toolbar-edit-button-serif-after-patch-2983568-36.png	64.61 KB	andrewmacpherson
#9	umami-toolbar-edit-button-sansserif-before-patch-2983568-36.png	64.36 KB	andrewmacpherson
#6	toolbar-edit-8.7.x-dev.png	8.52 KB	mairi
#3	toolbar-font-2987665-3.patch	496 bytes	jogordon
	standard-toolbar-edit-button-sansserif.png	1.27 KB	andrewmacpherson
	umami-toolbar-edit-button-serif.png	1.33 KB	andrewmacpherson

Comments

Comment #1

23 July 2018 at 20:01

andrewmacpherson created an issue. See original summary.

Comment #2

jogordon commented 10 December 2018 at 13:00

Working on this at #uoe-d8-contribution

Comment #3

jogordon commented 10 December 2018 at 14:11

Status	File	Size
new	toolbar-font-2987665-3.patch	496 bytes

I'm attaching a patch that should fix the issue with the 'edit' button on the toolbar showing in a serif font.

We are first timers, so please be nice. :-)

Comment #4

jogordon commented 10 December 2018 at 14:13

Status:

Active

» Needs review

Comment #5

eli-t

he/him

English

Manchester

commented 10 December 2018 at 14:54

Status:

Needs review

» Needs work

Thanks for your help @jogordon!

I'm not sure we have the right approach here though - we seem to be resetting the font originally set in Stable in the Umami theme. It would be much better to not override it. Umami theme should not have to know what Stable originally set it too.

Also please check https://www.drupal.org/docs/develop/standards/css/css-formatting-guidelines - we have to comply with these for all css.

Comment #6

mairi commented 10 December 2018 at 15:38

Status	File	Size
new	toolbar-edit-8.7.x-dev.png	8.52 KB

@Eli-T I'm helping @jogordon with this at a contribution day but I'm not able to reproduce the problem in 8.7.x-dev with the latest code. I see the problem with an 8.6.2 installation, but with 8.7.x-dev the Edit link shows in a sans serif font. Could this have been fixed as a side effect of something else? Screenshot attached from 8.7.x-dev instance:
Edit link in 8.7.x-dev

Comment #7

eli-t

he/him

English

Manchester

commented 10 December 2018 at 16:25

@mairi that's really interesting! Potentially this could have been fixed somewhere else. It would be useful to pinpoint where before closing the issue.

Comment #8

eli-t

he/him

English

Manchester

commented 10 December 2018 at 16:53

Quick spin on simplytest.me shows this appears to be fixed in both 8.6.x and 8.7.x

Comment #9

andrewmacpherson commented 10 December 2018 at 17:14

Status	File	Size
new	umami-toolbar-edit-button-sansserif-before-patch-2983568-36.png	64.36 KB
new	umami-toolbar-edit-button-serif-after-patch-2983568-36.png	64.61 KB

I remember seeing this problem much more recently than when I filed it in July. I think I probably saw it when reviewing #2983568: Audit and improve focus styles across the Umami theme for logged out users.

Today I replicated it with the latest code 8,7.x code (commit 4f02a38)...

It seems that this WAS fixed elsewhere at some point, since filing this issue. Here is a screenshot from Firefox 63 on Linux:

It's the same in Chrome 71 on Linux, all fine.
BUT if you apply the latest patch (#36) from #2983568: Audit and improve focus styles across the Umami theme for logged out users, there's a regression. The Manage, Shortcuts, and My account toolbar buttons are all in sans-serif, but the Edit button is now serif. Here is a screenshot from Firefox 63 on Linux:

It's the same problem in Chrome 71 on Linux.

Comment #10

andrewmacpherson commented 10 December 2018 at 17:18

Title:	Toolbar button elements get serif font in when Umami theme is active.	» [PP-1] Toolbar Edit button gets serif font in when Umami theme is active.
Issue summary:	View changes
Status:	Needs work	» Postponed
Issue tags:		+Regression, +Needs issue summary update
Related issues:		+#2983568: Audit and improve focus styles across the Umami theme for logged out users

Propose we postpone this until after #2983568: Audit and improve focus styles across the Umami theme for logged out users has been committed.

Comment #11

andrewmacpherson commented 10 December 2018 at 17:25

If Umami styles keep leaking into the toolbar, it's a safe bet other custom themes run into this too. So perhaps this needs more robust CSS in toolbar module itself?

Comment #12

andrewmacpherson commented 4 January 2019 at 21:48

Status:

Postponed

» Active

This issue can be active again, since #2983568: Audit and improve focus styles across the Umami theme for logged out users is fixed.

Comment #13

andrewmacpherson commented 4 January 2019 at 21:54

Title:

[PP-1] Toolbar Edit button gets serif font in when Umami theme is active.

» Toolbar Edit button gets serif font in when Umami theme is active.

Comment #14

markconroy commented 5 January 2019 at 12:38

Status:

Active

» Closed (outdated)

I'm going to mark this issue as closed, we fixed it as part of #2983568: Audit and improve focus styles across the Umami theme for logged out users and gave credit in that issue.

Comment #15

andrewmacpherson commented 5 January 2019 at 17:45

Title:	Toolbar Edit button gets serif font in when Umami theme is active.	» Toolbar styling is easily disrupted by theme CSS.
Component:	Umami demo	» toolbar.module
Status:	Closed (outdated)	» Active
Issue tags:	-Regression	+Needs issue rescope
Related issues:		+#2941647: Link hover styles unintentionally applied to administration toolbar

Umami keeps running into the problem of styles leaking into the toolbar - both the serif-font problem here, and the colours in #2941647: Link hover styles unintentionally applied to administration toolbar.

So I think it's worth re-scoping this, to see whether the toolbar module CSS can be made more resilient?

Umami isn't the only theme affected - Bartik also has a toolbar styling leak. It uses border-bottom instead of text-decoration for underlining links, so it also has an override to prevent the both toolbar levels getting extra border.

If 2 core themes need overrides to repair the toolbar, we can expect that other themes run into this too. Perhaps the admin-UI initiative's new theme will encounter this too? It would be great if themers didn't have to worry about this (distro/profile maintainers especially).

Comment #16

andrewmacpherson commented 5 January 2019 at 18:38

Issue summary:	View changes
Issue tags:	-Needs issue summary update, -Needs issue rescope

Comment #17

5 January 2019 at 18:38

Version:

8.7.x-dev

» 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Comment #18

5 January 2019 at 18:38

Version:

8.8.x-dev

» 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Comment #19

5 January 2019 at 18:38

Version:

8.9.x-dev

» 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Comment #20

5 January 2019 at 18:38

Version:

9.1.x-dev

» 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Comment #21

5 January 2019 at 18:38

Version:

9.2.x-dev

» 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #22

5 January 2019 at 18:38

Version:

9.3.x-dev

» 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #23

5 January 2019 at 18:38

Version:

9.4.x-dev

» 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #24

pameeela commented 29 September 2022 at 03:05

This happens on pretty much all of our sites! Haven't dug into it at all but found this issue when I eventually decided to try to do something about it. Much of the time, it's only a slight change to the font but in some cases it's quite obvious and very annoying.

If anyone has tips or tricks to avoid it please share :)

Comment #25

longwave

he/him

English

commented 29 September 2022 at 10:05

The off-canvas settings tray now uses all: revert; to avoid styles leaking into it: #3291797: Refactor Drupal 10 settings tray / off-canvas to use modern CSS

Maybe we can use a similar technique in the toolbar?

Comment #26

29 September 2022 at 10:05

Version:

9.5.x-dev

» 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #27

29 September 2022 at 10:05

Version:

10.1.x-dev

» 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #28

29 September 2022 at 10:05

Version:

11.x-dev

» main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.