Make sure in-page anchors are not hidden behind top bars

[afercia]

Moved from ​https://github.com/WordPress/gutenberg/issues/10101

This issue always existed but it's more evident now that the new Block Editor (Gutenberg) supports in-page anchors for headings.

When the admin bar is visible, following a link to an in-page anchor works but the targeted element is hidden behind the WordPress admin bar (see attached screenshot).

Similarly, bundled themes that have a sticky top bar should take care of this.

As mentioned in the Gutenberg GitHub issue, there's a simple CSS technique to address this problem (using the :target selector) and turns out it's already used on wp.org. For example, follow this link: ​https://make.wordpress.org/core/handbook/best-practices/commit-messages/#guidelines

[afercia]

Example of a heading with anchor hidden behind the WP admin bar

[desrosj]

I'm marking this as good-first-bug.

[kingkero]

In the latest Gutenberg master version, Headings and Groups can have anchors. So I added rules for those two via the CSS directive :target. Needs to be in 2 places for each files as the admin bar has different heights for different screens. For smaller screens the bar is not fixed.

[audrasjb]

Don’t hide content anchors with WP Admin Bar

[audrasjb]

Hi,

I refreshed the initial patch.
@kingkero there's no need to update RTL stylesheets since they are generated automatically.

[audrasjb]

Hi @SergeyBiryukov :) Do you think this one is ready be committed in 5.3?

[afercia]

the admin bar has different heights for different screens. For smaller screens the bar is not fixed.

@kingkero good point thanks. Between 782 pixels and 600 pixels, the admin bar is taller (46 pixels vs. 32) and still fixed at the top. We should add a rule also in the related media query.

[afercia]

Testing a bit the patch I'm not fully convinced it's there :) The main concern is that targeted elements will have an altered top margin and padding. This value will likely alter the one provided by the team in use, potentially introducing breakages.

To recap:

• the added spacing should be _additional_ to the one provided by the active theme: not sure how to implement it but I'd recommend to explore a new approach
• with a viewport width of max 600 pixels, the patch shouldn't do anything
• between 600 and 782 pixels the added spacing should be 46 pixels
• above 782, it should be 32 pixels
• maybe consider to use just .entry-content :target to set the rule to any anchor, also the ones manually added within the content

[audrasjb]

This ticket still needs some work and improvements. Moving it to future release.

[dufresnesteven]

The main concern is that targeted elements will have an altered top margin and padding.

What about using something like:

....:target:before {
   content: '';
   display block;  
   height: 32px; // Height of the header
}

It won't collide with element styles.

[kingkero]

Recently we used scroll-padding-top (​MDN, ​caniuse) for a similar scenario.

While it does not have as great support as :target does, it at least solves the problem with the extra space (as there is none). I could work up some examples with that if you're interested.

[thimalw]

Replying to dufresnesteven:

It won't collide with element styles.

Good way of thinking, but unfortunately this still collides with the element styles. Say a theme has a style applied to the :before pseudo element of the target element, then this would cause a problem.

scroll-padding-top as suggested above seems to do the trick. But I'm not sure whether it has enough support to be used in this case.

[sabernhardt]

Should the following two tickets be closed in favor of this one?

• #43452
• #51910 (has scroll-padding-top patch ​PR 782)