Proposal: Add CSS variable for admin-bar height to core.

[nico23]

I saw this is the 2021 theme. Thought it a great use of a CSS variable. Found out it did not work as expected and fixed it in: #52564

Could file this under Plugins/Themes/Toolbar not sure.

I initially thought it was already from core as I stumbled upon it in the devtools. I think it would be great for all plugin and theme developers to establish a variable in core we can use.

The patch I will be adding through GitHub will just add the variables in the admin-bar.css file. However, this will require the use of a , 0px like default when using the variable for CSS to work when the admin bar is not active.

.example-fixed-element {
	position: fixed;
	top: calc(.5rem + var(--wp-admin-bar-height, 0px));
}

It could be made universally usable without a default fallback value with

:root {
   --wp-admin-bar-height: 0px;
}

But because the admin-bar.css only loads when logged in it would make no sense to add it in that file.

Also in theory the variable could actually be used for the admin bar.css. Not sure it that makes sense, there is much more happening than just increasing the height in the media query. In theory the negation of the value and calculating other values in the file could be based on this variable.

There are 7 occurrences of the 32px/64px in the file. And it seems some other values would have to change with it. If it was a changeable value. The value could be like a base to dynamically control all elements sizes in the navbar.

I also do not know if WP has some aggressive backwards combat rules. CSS vars are supported by 95% of used browsers according to can-i-use ​https://caniuse.com/?search=variables.

This adds a variable for the admin-bar height as seen in the 2021 theme but in core for all plugins and themes to utilize.

Trac ticket: https://core.trac.wordpress.org/ticket/52623#ticket

[ryelle]

Thanks for kicking this off with your PR @nico23!

There's some ongoing ​custom property discussion regarding colors, but I think this would be a good, self-contained use case to get support for custom properties into core.

We do support IE11, so in addition to adding the variable, we'll want to add a PostCSS plugin for fallbacks. There are two I know of, and both have drawbacks.

• postcss-custom-properties is one option, but it doesn't support properties that are updated in media queries.
• postcss-css-variables is another - this one does support media queries, but it also has a bug where it generates duplicate styles, so we'd need to also add postcss-discard-duplicates. This is the approach that was used in Twenty Twenty-One.
• Another suggestion?

It's possible we'll drop support for IE11 (see #49696), but the timeline there is up in the air, so it's best to proceed assuming we need to support it.

[desrosj]

In 50602:

Build/Test Tools: Backport GitHub Action and build improvements to the 5.6 branch.

This backports several build and test tool improvements to the 5.6 branch. Most notably, this includes:

• The changes required to allow each workflow to be triggered by the workflow_dispatch event so that tests can be run on a schedule [50590].
• The ability to run PHPUnit tests from src instead of build [50441-50443].
• Splitting single site and multisite tests into parallel jobs [50379].
• Split slow tests into separate, parallel jobs for PHP 5.6 [50444].
• Better branch and path scoping for GitHub Action workflows when running on pull_request [50432,50479].
• Several devDependency updates.

Merges [50267,50299,50379,50387,50413,50416,50432,50435-50436,50441-50444,50446,50473-50474,50476,50479,50485-50487,50545,50579,50590,50592,50598] to the 5.6 branch.
See #50401, #51734, #51801, #51802, #52548, #52608, #52612, #52623, #52624, #52625, #52645, #52653, #52658, #52660, #52667, #52786.

[desrosj]

In 50603:

Build/Test Tools: Backport GitHub Action and build improvements to the 5.5 branch.

This backports several build and test tool improvements to the 5.5 branch. Most notably, this includes:

• The changes required to allow each workflow to be triggered by the workflow_dispatch event so that tests can be run on a schedule [50590].
• The ability to run PHPUnit tests from src instead of build [50441-50443].
• Splitting single site and multisite tests into parallel jobs [50379].
• Split slow tests into separate, parallel jobs for PHP 5.6 [50444].
• Better branch and path scoping for GitHub Action workflows when running on pull_request [50432,50479].
• Several devDependency updates.

Merges [50267,50299,50379,50387,50413,50416,50432,50435-50436,50441-50444,50446,50473-50474,50476,50479,50485-50487,50545,50579,50590,50592,50598] to the 5.5 branch.
See #50401, #51734, #51801, #51802, #52548, #52608, #52612, #52623, #52624, #52625, #52645, #52653, #52658, #52660, #52667, #52786.

[desrosj]

In 50604:

Build/Test Tools: Backport GitHub Action and build improvements to the 5.4 branch.

This backports several build and test tool improvements to the 5.4 branch. Most notably, this includes:

• The changes required to allow each workflow to be triggered by the workflow_dispatch event so that tests can be run on a schedule [50590].
• The ability to run PHPUnit tests from src instead of build [50441-50443].
• Splitting single site and multisite tests into parallel jobs [50379].
• Split slow tests into separate, parallel jobs for PHP 5.6 [50444].
• Better branch and path scoping for GitHub Action workflows when running on pull_request [50432,50479].
• Several devDependency updates.

Merges [50267,50299,50379,50387,50413,50416,50432,50435-50436,50441-50444,50446,50473-50474,50476,50479,50485-50487,50545,50579,50590,50598] to the 5.4 branch.
See #50401, #51734, #51801, #51802, #52548, #52608, #52612, #52623, #52624, #52625, #52645, #52653, #52658, #52660, #52667.

[desrosj]

In 50605:

Build/Test Tools: Backport GitHub Action and build improvements to the 5.3 branch.

This backports several build and test tool improvements to the 5.3 branch. Most notably, this includes:

• The changes required to allow each workflow to be triggered by the workflow_dispatch event so that tests can be run on a schedule [50590].
• The ability to run PHPUnit tests from src instead of build [50441-50443].
• Splitting single site and multisite tests into parallel jobs [50379].
• Split slow tests into separate, parallel jobs for PHP 5.6 [50444].
• Better branch and path scoping for GitHub Action workflows when running on pull_request [50432,50479].
• Several devDependency updates.

Merges [50267,50299,50379,50387,50413,50416,50432,50435-50436,50441-50444,50446,50473-50474,50476,50479,50485-50487,50545,50579,50590,50598] to the 5.3 branch.
See #50401, #51734, #51801, #51802, #52548, #52608, #52612, #52623, #52624, #52625, #52645, #52653, #52658, #52660, #52667.

[desrosj]

In 50606:

Build/Test Tools: Backport GitHub Action and build improvements to the 5.2 branch.

This backports several build and test tool improvements to the 5.2 branch. Most notably, this includes:

• The changes required to allow each workflow to be triggered by the workflow_dispatch event so that tests can be run on a schedule [50590].
• The ability to run PHPUnit tests from src instead of build [50441-50443].
• Splitting single site and multisite tests into parallel jobs [50379].
• Split slow tests into separate, parallel jobs for PHP 5.6 [50444].
• Better branch and path scoping for GitHub Action workflows when running on pull_request [50432,50479].
• Several devDependency updates.

Merges [50267,50299,50379,50387,50413,50416,50432,50435-50436,50441-50444,50446,50473-50474,50476,50479,50485-50487,50545,50579,50590,50598] to the 5.2 branch.
See #50401, #51734, #51801, #51802, #52548, #52608, #52612, #52623, #52624, #52625, #52645, #52653, #52658, #52660, #52667.

[desrosj]

Sorry for the noise above, I just realized I had the wrong ticket number in those commits. Those changesets are not related to this ticket.

Sets up a new custom property --wp-admin--admin-bar--height, and uses it in all the places where the height (value) is used.

If we don't want to change all the CSS in admin-bar.css, we could also just use ​https://github.com/WordPress/wordpress-develop/commit/7ab4b040cdacb4d40984befea6ec6cf2822898d7 & ​https://github.com/WordPress/wordpress-develop/commit/716d654eb1e5ce1563a6569aa6b144e3d997eb55 - add the custom property and use it in the default frontend code.

Themes can use this in their CSS to offset content, and it will inherit the correct size. For example:

{{{css
.some-banner {

top: var(--wp-admin--admin-bar--height);

}
}}}

It would be nice to set this to 0 when there is no admin bar, but the property needs to be on html and the admin-bar class is on body.

Trac ticket: https://core.trac.wordpress.org/ticket/52623

[sabernhardt]

callback-only option: defining variable and removing * html body

[sabernhardt]

We could remove the * html body hack within the callback function while adding modern code. (It was added in [17299]/#16222)

Also, I'm not sure about the benefits of replacing the height value with a variable when link icons have specific width and positioning anyway. That would reduce browser support for subscribers on the front end and add about 120 bytes to the minified stylesheet.

It's very late for 5.8 consideration, but I uploaded another option to allow using the variable within a theme. A quick test worked with a full-height container in Firefox/Windows.
height: calc( 100vh - var(--wp-admin--admin-bar--height, 0px) );

[ryelle]

TIL about the * html body hack - sounds like it's for IE6 and below, so yeah… we can get rid of it 😁

I'm fine with dropping the replacements in admin-bar.css, but I think we should still leave the definition in there, so that it's available in wp-admin too.

[sabernhardt]

defining variable in stylesheet and removing hack from callback function

[sabernhardt]

Clearly I didn't think about using the variable on the admin side, too. It's in the stylesheet for 52623.1.patch​.

I tested the full-height container again in Firefox, as well as with Chromium browsers (Chrome, Edge, Opera).

[desrosj]

Today is 5.8 feature freeze. Unfortunately this one ran out of time.

Punting to 5.9 as there has been good recent momentum.

[ryelle]

@sabernhardt What do you think about simplifying _admin_bar_bump_cb too, like in 52623.2.diff​? This'll use the responsive value from the variable, instead of adding a media query here. If for some (unlikely) reason the variable doesn't exist, it will still fall back to 32px.

I'm happy to go with 52623.1.patch​ if you think this might have other consequences, though.

[sabernhardt]

I would like to avoid adding the CSS variable in the front-end bump callback. Implementing the custom property there would make the toolbar overlap site navigation/content with any Internet Explorer version, Opera Mini, etc.
(The previous patch already creates the same broken layout if someone still uses IE6 to log in to a site, as a customer or subscriber, yet many sites break in other ways with older IE versions.)

This variable would fit well with the scroll padding fix on #46371, however, because that requires a modern browser anyway.

[ryelle]

Okay, I was thinking the admin-bar would fall under the same browser support as wp-admin (so we wouldn't need to support IE). Since it's kind of borderline (admin vs frontend), we'll stick with the current CSS.

[ryelle]

In 51672:

Toolbar: Provide a CSS custom property for the admin bar height.

This new custom property, --wp-admin--admin-bar--height, reflects the admin bar's height and adjusts responsively on smaller screens. It can be used to offset content to avoid overlapping the admin bar, without needing to copy the media query.

This also removes a workaround only needed for Internet Explorer 6 and below.

Props nico23, sabernhardt.
Fixes #52623.

[joyously]

Did you test the removal of that CSS with an iframe? (such as Customizer or embed or new widget screen)

[ryelle]

@joyously The admin bar isn't visible in the Customizer. Are you seeing an issue anywhere in particular?

[joyously]

The CSS that was removed did not target the admin bar. It was * html body so it could affect anything in an iframe. I simply named some places that have iframes.

[ryelle]

Oh, that CSS is a workaround for IE6 and older browsers - in those browsers, * html is (incorrectly) interpreted as html, so it's a way to add browser-specific CSS to the page. In modern browsers, the html element is the root element, so * html doesn't match anything - even in an iframe, because the context of an iframe is restricted to that page (styles from outside don't affect it).

[joyously]

I know the theory. I just asked if you tested it, to make sure.

[sabernhardt]

I have checked iframes now in Windows browsers (Firefox, Edge and Chrome). The body element within an iframe did not have the margin before the commit and still does not.

If the styles had affected iframe contents (in a browser other than old versions of IE), that would have been an unintended extra margin fixed by this change.

Tests:

1. front end - a YouTube video embed within a post, with Twenty Sixteen theme
2. admin - the "View (latest) version details" popup within an outdated theme's Theme Details modal (the iframe contains a WordPress.org page with its toolbar)

Closing as the ticket is closed and an alternative solution committed.

[sabernhardt]

Dev notes published:

• ​New CSS custom property and scroll padding
• ​Bundled themes update