Getting heading links and anchor ids more easily

[vmassol]

Hi devs,

Context:

Content-independent generated ids for Headings and Images

That would be a nice feature for todays strategy too. I always open up the dev console to get the right id or if there is a toc inserted click and jump to the heading and copy it from the adress bar. In principle the ids for headings are guessable more or less. Headings in a language with Umlauts are a hard guess sometimes.

Here’s one usability feature I’d like to discuss: the ability, in view mode, to hover over a heading with the mouse and display an anchor icon, in order to get a link with an anchor or copy the anchor id in the clipboard (so that it can be pasted when editing a page and linking to some heading). Something similar to:

• Creating a Vue Application | Vue.js
• Build Scan® | Develocity

It’s also similar to the Lightbox app which does this for images: https://extensions.xwiki.org/xwiki/bin/view/Extension/Image%20Lightbox%20Application/

Note: one harder part is to support is that we would need to support also this construct:

{{id name="myid"/}}
== some heading ==

which would generate in HTML something like:

<div .../>
<h2>...</h2>

WDYT?

Thanks

[tmortagne]

+1 for the general concept, it seems to be a pretty common feature, and it’s indeed very useful (I can think of quite a few others examples with the same behavior as the 2 you indicated)

[tmortagne]

@vmassol

Note: one harder part is to support is that we would need to support also this construct:

{{id name="myid"/}}
== some heading ==

I’m not sure we need to. Or to me more accurate we could decide to introduce this feature both for the headings and the id macro (since the goal of the id macro is to insert an anchor).

[MichaelHamann]

I don’t think we ever advised to put an id macro before a heading. I think our advice was to put it inside the heading. See, e.g., the examples in the documentation for the numbered reference macro.

How this seems to work is that they put an HTML link inside or before the element to be linked to and display that link when hovering the heading. The Vue documentation seems to be the better example here in terms of accessibility as it manages to support keyboard navigation by just hiding the link visually using an opacity of 0 and showing it with an opacity of 1 when the link is focused.

For this to work in XWiki, I think we would need a way to mark generated content to prevent converting this link back into the XWiki syntax when parsing the HTML from the WYSIWYG editor. Now such a marker is something we could use in other places, too, so this would be good to introduce, anyway.

So +1 from my side for the concept.

[vmassol]

@MichaelHamann

I don’t think we ever advised to put an id macro before a heading. I think our advice was to put it inside the heading. See, e.g., the examples in the documentation for the numbered reference macro.

I can clearly remember several times where we’ve shown this pattern of the id macro before a heading (and even used it ourselves in platform and contrib - I’ve searched and it’s not used anymore in platform, good). Now, fortunately, I don’t think it’s ever been written on xwiki.org anywhere so that makes it easier to deprecate the (bad) practice

One reason you see https://extensions.xwiki.org/xwiki/bin/view/Extension/Numbered%20Reference%20Macro/#HNumberedHeadings is because 1) it’s recent and 2) we cannot have the id macro used outside the figure caption. It just wouldn’t work. It’s also less correct, I agree.

You can see some examples used at https://github.com/search?q=org%3Axwiki-contrib%20"{{id%20name%3D"&type=code

I agree that we don’t need to support the id macro outside of the headings. We might need to support the id macro used inside headings though, as the first element.

@MichaelHamann

Now such a marker is something we could use in other places, too, so this would be good to introduce, anyway.

An example of such a need is Rendering Transformations. I don’t recall but that’s probably already supported somehow (to protect some portion of HTML). Maybe that could be reused.

Thx

[tmortagne]

@MichaelHamann

Now such a marker is something we could use in other places, too, so this would be good to introduce, anyway.

Yes. See Loading....

@vmassol

that’s probably already supported somehow

Nop.