autolink headers don't get offset [was: parsing markdown footnotes]

[dariah-eric]

autolink headers don't get offset [was: parsing markdown footnotes]

[ttasovac]

Dear Stefan,

I figured out why footnotes were not displaying correctly in Ksenia's resource — she forgot to put the ":" following the footnote number at the end of the resource. I added them and now clicking on the footnote number should take you to the footnote, and there is a link back.

However, footnotes, are still buggy:

• clicking on the footnote number doesn't take you directly to the footnote content because of some miscalculation related to the navbar. For instance, https://campus.dariah.eu/resource/controlled-vocabularies-and-skos#fn-3 should take you directly to footnote 3, but instead of that, we get to the half-covered footnote 5:
  
• the same problem occurs when clicking on the link back: the content that we should be seeing is covered by the navbar
• it would be nice if we could, in addition, display the content of the footnote in a tool tip when hovering over the footnote number
• it would be nice if there was no extra space separating the text and the footnote number

The same misalignment occurs with the TOC. Ksenia's resource is a good test case. Clicking on items in the TOC doesn't take you to the wanted heading because the actual heading remains below the navbar.

Could you please look into this and try to fix both the footnote and the TOC headings?

[ttasovac]

This problem is related to the autolink headers plugin. In gatsby.config.js we use the offsetY param which should precisely take care of the sticky navbars and calculate the offset for headers:

{
  resolve: 'gatsby-remark-autolink-headers',
     options: {
       offsetY: '400',
       icon: false,
     }
},

For some reason, we are using the offsetY of 400px which is too much anyway, but this param doesn't seem to do anything for us. I tried with 100 etc. but still no luck.

@stefanprobst could you please look into this? I'm sure you're very busy but this is a bug affecting the functionality of the live site so we really need to fix this, and I already spent hours trying to figure it out.

[stefanprobst]

scrolling should hopefully be fixed

still todo:

• it would be nice if we could, in addition, display the content of the footnote in a tool tip when hovering over the footnote number

would a title attribute be enough or something more like real tooltip (i.e. like wikipedia)?

• it would be nice if there was no extra space separating the text and the footnote number

could you maybe link a screenshot -- not sure i understand which whitespace where

[stefanprobst]

ok, scroll position handling is not 100% correct yet. i spent some time time on this yesterday, but this turned out to be more complicated than anticipated, so i'll have to come back to this.

• gatsby-remark-autolink-headers will correctly update the scroll position for hash links on initial render in a production build (when configured with offsetY option). however, due to an issue with gatsby-plugin-mdx, for the browser/ssr lifecycles to run it needs to be configured both as subplugin for gatsby-plugin-mdx, and included in the top plugins array with options specified in both places.
• hooking into client side location changes is possible via shouldUpdateScroll lifecycle. gatsby-remark-autolink-headers uses this as well and this works ok
• however, clicking twice on a hash link will only the first time run shouldUpdateScroll, the second click will therefore end up using the browser built-in scroll-to-very-top-without-offset behavior. this is because window.location did not change, and popstate/hashchange events don't fire either. so we have to update the scroll position with an onClick handler <a>s as well
• when using browser back button, we should be using the saved scroll position and not scroll to the element#id position. this we don't do currently -- which means clicking on a footnote link, and then the browser back button will take you to thetop/the element specified in the url fragment, and not to the last scroll position, i.e. the footnote link. so you need to use the explicit backref link for now.

[ttasovac]

Thanks a million, Stefan! This is already a huge improvement.

[stefanprobst]

in the future, we can just use scroll-padding-top, but this needs to wait for proper Safari support

[ttasovac]

I've just noticed that our navigation links in events are still slightly off.

1. Clicking on the number of a session in the navigation sidebar will scroll to this:
   we should scroll exactly to the beginning of the blue border, i.e. we shouldn't show any gray space there
2. clicking on the same session link in the navigation sidebar will take us to a different, also slightly offset place:

If the second issue is the same as what you described above (clicking on the link twice in regular resources), we don't have to worry about it too much at the moment. But it would be great if we could get the first issue resolved — I tried myself but couldn't figure it out.

[stefanprobst]

should be fixed now - can you check pls? thx

[ttasovac]

works for me! thanks a lot Stefan