Safari bug: anchor links stay behind the navbar

[12rambau]

When I type a search in my search bar like for example NumberField in https://sepal-ui.readthedocs.io/en/latest/index.html

and select one of the found anchor (https://sepal-ui.readthedocs.io/en/latest/modules/sepal_ui.sepalwidgets.html?highlight=NumberField#sepal_ui.sepalwidgets.inputs.NumberField) the anchor is placed behind the navbar. Is it possible to add extra padding to the js script ?

It appears this way :

And it would be more useful

this way :

[jorisvandenbossche]

@12rambau I think this is fixed in the meantime on master. See eg https://pydata-sphinx-theme.readthedocs.io/en/stable/demo/generated/pandas.DataFrame.drop.html#pandas.DataFrame.drop vs https://pydata-sphinx-theme.readthedocs.io/en/latest/demo/generated/pandas.DataFrame.drop.html#pandas.DataFrame.drop using our demo docs (link for stable release vs development version)

[12rambau]

For both of them the title was hidden behind the navbar.

As we are entering the horrible zone of device compatibility I use :
MacOS BigSur 11.1
Safari 14.0.2

It works on Firefox 84.0.2 on the latest doc

[jorisvandenbossche]

Hmm. I was using firefox, so there indeed in now works (and didn't work for the stable release). For Chrome it seems to work as well (at least on Ubuntu).

The latest version is using scroll-padding-top for this (#318), and https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padding-top indicates that Safari only has partial support, so that's probably the reason.

For Safari we could maybe keep what was removed in #318 as fallback? (that should work for at least most links)

[drammock]

Unfortunately it is a known bug that Safari doesn't (yet) support the CSS property that we're using to handle this:

https://bugs.webkit.org/show_bug.cgi?id=179379

[drammock]

Using something like

// offsetting html elements with anchor attached to adjust for fixed header
:target {
  &::before {
    // offsetting html anchor titles to adjust for fixed header
    display: block;
    content: '';
    height: var(--header-height);
    margin: calc(-1 * var(--header-height)) 0 0;
    background-color: white;
  }
}

as @jorisvandenbossche suggests would probably work for your specific example, @12rambau, but you should know that it has a drawback: any inline anchors that are targeted (i.e., a mid-sentence citation that is the target of a backreference) will be quite badly broken (they willl break the line, and if they have :before content like a parenthesis or bracket, these will get moved up by the margin amount).

Personally I would hesitate to re-incorporate that behavior into the theme; I think the failure to scroll on safari is less bad than the side-effect for inline targets that I just described... I would recommend individual users to add the above to their site's CSS if (1) they know they won't have any inline target anchors, or (2) they think the scrolling problem is too painful and are willing to accept the breakage to the inline target anchors.

[12rambau]

I think this is a very minor problem. I agree that breaking inline anchor is a big risk and if it's only to save a bug from Safari it's not worth it.

I will let the issue open until a new workaround emerge OR the bug solve itself with a update of safari

[jorisvandenbossche]

Indeed, probaby best to keep it as is in the theme. Now, if you know as a downstream user that you don't have any inline anchors, you can still put the above css snippet in your custom.css.

[pradyunsg]

scroll-padding-top
a known bug that Safari doesn't (yet) support the CSS property that we're using to handle this:

FWIW, the workaround is to use scroll-margin-top. 😉

I first noticed this in https://github.com/squidfunk/mkdocs-material/blob/714a9cc7d1e33b250753c722d87d54cdabc39d3d/docs/changelog.md#516-_-may-9-2020, and this is what Furo does:

https://github.com/pradyunsg/furo/blob/be3efbd3649db0b261dca781d43717442663df51/src/furo/assets/styles/_scaffold.sass#L280-L282

[12rambau]

It seems that the bug is now solved from Safari's side. (At least it's not an issue on my docs any more)