Backporting code from the forked module toc_ng

Thanks. Looks very promising.

>This version takes also profit of new CSS features available to modern browsers like the sticky positioning.

About the sticky positionning I saw you deleted the settings sticky_stop and sticky_stop_padding which allows us to set a selector for stopping to stick the TOC (For example I don't want the TOC to continue to be sticky when scrolling down in a big footer). Does it means that feature has been removed or is handle differently with modern browsers ? If this has been removed, this is a BC break for current users of this module, and i believe we should re-add it.

Anyway your work is awesome. And it would be nice to not have anymore a dependency on a third-party library !

Such improvment need at least a new branch. Just pushed a 3.0.x branch.

The sticky CSS positioning is constrained in the parent container scroll area:

https://elad.medium.com/css-position-sticky-how-it-really-works-54cd01dc...

So most of the time you will have a right or left empty column where the toc would stick, and a footer below would probably take the full width and end the toc container column.

So the toc would never overlap over the footer.

But we could still add back the sticky_stop feature if there is still a use for it.

I test on a project which used intensively toc_js.
I have to change some css properties because the height of the sidebar was only the height of its containing elements, and not the height of the page content. Except this, yes this work fine, only if the toc_js element has also the css rule top: 0 ;(or any value for the top css rule) with the position: sticky;

Also you have still the sticky_offset property (which in theory set the css rule top: STICKY_OFFSET; for the sticky toc_js element) and I see you set this in the rewritten library embedded.

This simplifies the code enormously. Very cool.

I'll give a try on a real project.

Comitting the mr11 on 3.0.x branch with theses slighty changes

- function toc_js_update_8001 not removed (we can't remove this hook_update even if empty because the number 8001 is registered on site which played it)
- toc_js is always dependant of core/once library. Re-added so the dependency

See interdiff

added mably as co-maintener

Thanks @flocondetoile 👍

@mably, before release a new stable version I wonder what are the difference between the existing settings back_to_top and back_to_top_label and the new settings you introduce back_to_toc and back_to_toc_label ?
Looks like they do the same thing but not very sure because lit seems that you kept all of them volontary ?

@mably just given you access on the project (write to VCS, edit project, maintain issues and releases)

For green tests ^^

back_to_top create links to go back to the top of the page, back_to_toc create links that allow to go back to the corresponding link item in the Toc when navigating with the keyboard (A11y), they are visible only when focused using the CSS class visually-hidden-focusable.

OK so thie behavior of the back_to_top has been replaced with the behavior of back_to_toc, and now the back_to_top only send at the first heading.

Does it means that for users actually on 2.x versions, we need to write an update_hook for moving currents settings back_to_top and back_to_top_label in 2.x to back_to_toc and back_to_toc_label new settings ?

Ah, yes, you are right, a hook might be needed to convert 2.x back_to_top to 3.x back_to_toc.

There is a slight difference AFAIR: back_to_top in 2.x was going back to the top of the ToC and back_to_toc in 3.x is going back to the corresponding item in the ToC, not the first one.

No, back_to_top in 2.x was going back to the corresponding item in the ToC, as does back_to_toc in 3.x. And anyway the difference between these two behavior is not really important.

Well in fact I wonder if an update hook is really necessary. In fact you rewrite the back_top_top feature to send user to the top of the page. And do what the feature tell / announce.

In most case, if the TOC is not sticky then the back to top link sent users to the top of the page because the TOC was above the content (A TOC below content is not relevant). And if the TOC is sticky, sending to the corresponding element in the TOC is in fact not really useful, where as sending to the top of the page can be useful.

So I suggest to let existing config as is. And this config which send user to the corresponding element in the TOC in 2x, will send users to the top of the page in 3.x. I think the behavior will be the same. Personnaly I never enabled the back to top feature with a sticky TOC.

Most of the issue backlog have been cleared, I think we may be ready for an alpha release...

Yes.

Only an alpha ? I was thinking at a stable version :-), or at least a beta release. What do you think ?

Let's go for a beta release then ;)

Released as version 3.0.0-beta2.

Automatically closed - issue fixed for 2 weeks with no activity.