Fix the broken anchor links in the headings
The anchor links I introduced looked hideous and didn't really work well, so this is my second attempt.
2 failed tests on run #4528 ↗︎
Details:
| Make changes suggested in #1020 | |||
| Project: datenanfragen/website | Commit: c748ca6cbb |
||
| Status: Failed | Duration: 03:59 💡 | ||
| Started: Jun 10, 2023 11:01 PM | Ended: Jun 10, 2023 11:05 PM | ||
cypress/integration/use-cases/reactor.spec.js • 2 failed tests
| Test | Artifacts | |
|---|---|---|
| Reacting to request responses > Admonition followed by complaint |
Output
Screenshots
Video
|
|
| Reacting to request responses > Free text response |
Output
Screenshots
Video
|
|
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.
In Firefox 110 I can only click them if I approach them from the text, i.e. hovering from right to left. They won't appear if you come from the left which is kinda odd.
They won't appear if you come from the left which is kinda odd.
Either I don't understand what you mean, or I do not have this problem. I haven't updated Firefox to 110, yet, but I doubt that would change anything.
I also get this in Chromium 110/Linux and Firefox 110/Linux. Video: (relevant part at the end) Screencast from 2023-02-27 17-19-43.webm
Same, plus a few other issues. I started working on a fix a few weeks ago but got pretty annoyed (mostly about the alignment) and haven't continued since. :D
Ah, that is what you mean! I don't expect that behavior at all… And yes, the alignment is really annoying, which is why I implemented this in the annoying way I did without breaking the semantics too much.
Am I supposed to do anything here? I don’t really think what you describe is expected behavior and it is certainly annoying to implement.
I don’t really think what you describe is expected behavior
I am convinced that it is. Consider two cases:
- The user hovers over a heading and sees the anchor thingy for the first time. They want to find out what it does but their mouse "slips" from the heading, untoggling the hover state. The intuitive thing to do is to go straight for the thing they wanted to get to anyway (the anchor). That doesn't work.
- The user already knows the anchor thingy and where it is. So they try to hover it directly. That doesn't work.
And honestly, even as someone who does know how the hover state works and why it behaves the way it does, I find it quite annoying to get to the anchor thingy. And you better be careful not to move the mouse too much after you have activated the hover state. Otherwise you have to start again at the heading. Kind of like one of these annoying flash games from back in the day. :P
https://user-images.githubusercontent.com/4048809/222794077-5747fafc-e61c-4c3c-bbd6-aecf2fe87ad3.mp4
Now look at my alternative implementation. The alignment is off (though it really isn't perfect for yours either), but it clearly feels so much more natural:
https://user-images.githubusercontent.com/4048809/222794217-d6b89c04-145a-44ef-854c-750e02608bce.mp4
I do also remember having some accessibility concerns about the markup, but unfortunately I didn't write those down as I had assumed that I would just fix them myself…
Is this PR still up-to-date? The current anchor link look and behave just fine. Did the "v2" release fix them? :D Or am I just used to the ones we called "hideous"? :D
The problem starts with h3s (and smaller):
https://github.com/user-attachments/assets/4fcfaf83-30a4-447c-89e6-a7ddd31927f4
I'm pretty sure that this is still the original problem this PR was supposed to fix.
Ah, thank you, Benni.
@zner0L Seems like we left you on read after your latest commit. Sorry! Do you mind rebasing this on master? 😅
Edit: I just quickly rebased it.