@Jack_who_built_the_house I think I'm still a little confused by your proposal, and what this task is.

We have to pick a point on the screen that we assume people are looking at, and when a section first touches that point we consider it active. You can think of it as when the bottom of the previous section is no longer touching that point, but it's the same thing (just said differently).

Also, I'm not sure why we would include the padding/margin around the title? What is that helping with? That is invisible to the person as they are reading the page.

Also, to try to clarify again, regardless of whether or not we use the padding/margin, we still need a fixed point on the screen that serves as the intersection threshold.

In T318106#8246632, @alexhollender_WMF wrote:

We have to pick a point on the screen that we assume people are looking at, and when a section first touches that point we consider it active. You can think of it as when the bottom of the previous section is no longer touching that point, but it's the same thing (just said differently).

You're kind of jumping to a solution here without grasping the alternatives. As I outlined in the task, there are two approaches to when to consider a section active:

1. should the first actually visible section be considered active (so that only whitespace is excluded from the top section),
2. or should we make an assumption about what should be the "right" correspondence between what the user sees on the page and which section is highlighted as active.

"Assuming" something is only one possible solution, and I argue not a good one. UIs should be predictable, which is why we need to avoid assuming things too much, especially when they are fundamentally unknowable like the user's light of sight. As I said in T317661#8244084, trying to guess where the user's light of sight is is a fundamentally flawed task. And cases like this clearly demonstrate it:

It's also quite telling that there's now a discussion in T317661 on "Where do people look on the page, center or top". Exactly to avoid such discussions, it is preferrable to have UIs that do not assume things about the unknowable and just behave predictably.

• "Treat the first visible section as active" is a predictable behavior.
• "Treat the first section with at least one line visible as active" is a predictable behavior; Britannica uses it.
• "Treat the section that is at the center or somewhere closer to the top of the screen as active" is not a predictable behavior, since all the user will grasp is that there is some point on the screen where the highlight makes a step. But in every single occasion that connection will be vague (the user won't count pixels to the top of the viewport or try to calculate its center). This is the kind of thing that so many people get annoyed by in UIs – that computers try to predict where they look, what they want, and so on (but that's a different conversation).

Also, I'm not sure why we would include the padding/margin around the title? What is that helping with? That is invisible to the person as they are reading the page.

Take this screenshot:

But 3 or 4 lines obsiously won't mean much if the threshold is big (which I argue against – see a good demonstration why in T317661#8246217).

I think I kind of understand now why you didn't see what I mean about margins and paddings. You're thinking in terms of the line of sight (that corresponds to a fixed point on the screen), while I'm thinking in terms of what the user sees in general (for example, which is the first visible section).

@Jack_who_built_the_house hmm, I'm still a bit confused and wonder if we're overcomplicating things here. Are you trying to say that people will have an easier time understanding what's happening if the intersection threshold is the top of the screen (because that's more "predictable"), versus a different point (like the middle of the screen, or 100px down from the top)? I think it's just as easy for people to understand: whenever a section's heading gets close to the top of the screen, that section is considered active. And even if it was more predictable to use the top of the screen, the idea behind the original task is that using the top of the screen doesn't match up with people's experience, because they are not looking at the very top of the screen while they are scrolling. If you want to understand it as trading off "predictability" for a solution that hopefully better matches up with people's experience, I think that's an okay understanding (and a fine tradeoff in this case).

Also, to clarify, when you say "Treat the first visible section as active", by "first" do you mean the one that's closest to the top of the screen?

Sorry, I'm quite busy now.

Are you trying to say that people will have an easier time understanding what's happening if the intersection threshold is the top of the screen (because that's more "predictable")

If you're asking whether I suggest to just leave everything as it is—of course no, I thought I made it clear in multiple comments.

You can look at the way I did it in Convenient-Discussions:

1. Open a browser in the Incognito mode (so that no unnecessary user settings are set)
2. Open https://en.wikipedia.org/wiki/Talk:Life?useskin=vector
3. In the console, run mw.loader.load('https://commons.wikimedia.org/w/index.php?title=User:Jack_who_built_the_house/convenientDiscussions.js&action=raw&ctype=text/javascript');

So, as compared to the current behavior in Vector 2022, here the whitespace between sections is included in the lower section (as opposed to the upper, as it is in Vector 2022). Whitespace is this area:

Also, to clarify, when you say "Treat the first visible section as active", by "first" do you mean the one that's closest to the top of the screen?

Here, the first visible section is "Definitions":

(While Vector 2022 treats the section above "Definitions" as active.)

Here, the first visible section is the section above "Definitions", because the last line of the previous section is visible:

As I said, this is not the only possible solution. By Britannica's solution, if the top of the viewport is in the outlined area, the "Definitions" section would still be considered active:

The last line is not fully visible anyway, so we can safely assume the user is not reading it.

Actually, I came across an interesting alternative solution recently. devopedia.org website doesn't shy away from highlighting as active all sections that are currently in the viewport, e.g. https://devopedia.org/linux:

@Jack_who_built_the_house I'm unfortunately still not able to understand how what you are suggesting is different from what we're planning to do in T317661. After we do that work the whitespace above a section will be part of that section from the perspective of the active section highlighting (which seems to be the main thing you're concerned about, though to be honest I'm still a bit confused by your suggestions). As far as I can tell it would make sense to close this task as a duplicate of that one, but feel free to leave it open if that feels more appropriate to you.

I'm confused by your confusion. You're proposing the most straightforward and, may I say, sloppy solution, and when I try my best to describe the problem in general form and go into details you're "not able to understand" 🙄

Can you provide some examples of websites doing what is suggested in T317661? Has this solution been discussed thoroughly within WMF? From my point of view, T317661 is introducing a UX antipattern under the guise of catering to user experience. Sorry. (I've explained why in multiple comments, but basically any connection is lost between what the user sees in the content area and which section is highlighted as active. "whenever a section's heading gets close to the top of the screen" is a vague criterion; users will misjudge often and get annoyed.)

Meanwhile, another possible solution:

• https://developer.chrome.com/docs/devtools/overview/
• https://www.jetbrains.com/help/idea/using-code-editor.html

(the TOC is on the right). The active section is switched as soon as, while scrolling down, the section stops being fully visible and there is a section below it in the viewport.
✅ Predictable
❌ Can take time for the user to figure out the logic

An example of my solution:

• https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics

(Here, sections are wrapped into a <section> element unlike sections in MediaWiki, so it's easier from the technical POV.)

I don't even know what we're talking about anymore. Any website that has a table of contents with highlighted sections does a variation of T317661. Maybe you're caught up on whether the padding comes from the heading element itself, or is a fixed offset, but it's all the same from the experience of the person using it.