Can we have anchors for the bullets in the [help/on-topic] list?

Question

Currently, in EL&U's help center, the on-topic page lists a number of topics we can't address on the site:

But please, don’t ask any questions about the following topics. They are out of scope for this site.

• The meaning of words, or synonyms for words, unless you have first looked them up in a dictionary or thesaurus. See below for suggestions about simple and basic questions.
• Proofreading ("Is this right?", "Are there any mistakes?"), unless a specific source of concern is clearly specified. See below for hints on checking existing texts.
• Writing advice (see Writers.SE instead) or critique requests
• "How to improve my English?" (this is not constructive anyway)
• Translation and non-English languages — please see the translation tag info for details
• Naming, including naming programming variables/classes
• Criticism, discussion, and analysis of English literature
• Jokes that do not rely on the English language

I believe the same structure is used for all the stacks in the exchange.

What I'd like is a way to point askers to specific bullets in that list, ideally with magic link support.

That is, can we give diamond mods the ability to add anchors (<a name="foo"/>) to each bullet in the list? For example, the second bullet above could have the anchor name "proofreading" (actual anchor names, like the text of the help center page itself, can be left up to the discretion of the community and its mods).

As a cherry on top, can we extend magic links to support these tags, like [help/on-topic#proofreading]¹. It would also be really nice if visiting such an anchor had some kind of brief visual highlighting effect, similar to what happens when you visit a link to a specific comment.

This will help us give new users more specific guidance as well as head off enervating debate with more truculent users. It also helps ease the constraint of only having 3 custom off-topic reasons (now I could vote to close with "other: please see [help/on-topic#litcrit]"; see also and combine with the nutty idea in the footnotes).

---

¹ _{And if you want to go really nuts, have such anchored-magic-links expand to the content of the bullet plus the link back to the help center.}

Answer 1

The Help Center pages use the same CommonMark Markdown processor as all other posts on SE. Thus, it's probably better, and easier, to adopt a solution which solves being able to do this generically for all posts. Such a solution should more-or-less automatically work for the Help Center too, due to the shared CommonMark Markdown processor and that each Help Center article has a unique post ID.

General solution: permit id attributes on HTML <a> elements

I agree that having the ability to have an anchor which can be targeted in a URLs would be quite helpful, particularly in Help Center pages, but also questions and answers in general (often very desirable for Meta FAQ entries). From a technical standpoint, it wouldn't be all that difficult to permit id attributes on HTML <a> elements. [The name attribute used to also be a possibility, but that attribute is obsolete on <a> elements as of HTML5.]

id attributes need to be unique on the page

The real trick is that id attribute values should be unique on the page and there could be duplication of the id value supplied in other posts on the page. This potential issue could be easily resolved by permitting the id attribute and having SE's backend software automatically prepend post<ID>- to all such ids. Doing so would eliminate any attribute value conflict between posts, but not any conflict within a post. Fortunately, while duplication is not permitted in HTML id attributes on a page, browsers don't break when there is such duplication, so while it's desirable that the system enforce that such id attributes be unique within a post, it's not critical that uniqueness within a post be assured.

This potential issue may not be as significant for Help Center pages, but there could, conceivably, be a Help Center page which is the combination of more than one post, rather than a single post ID for the entire Help Center page content.

Security issues

There would need to be limits on permitted values which are similar in scope/complexity to what's already applied for other attributes.

Helpful addition: auto-create targetable anchors for headings

It is possible to automatically create targetable anchors for any #, ##, and ### headers. GitHub does this for any user supplied Markdown content by converting the header text into an id, which is prepended with user-content- (example). It would be fairly easy for SE to also do this, but to prepend with post<ID>-.

Potential alternate: proposed extension to URL fragment syntax

There's a proposal to extend the URL fragment syntax to allow specifying arbitrary text on the page to be targeted and highlighted. At the moment, the proposal is only implemented in Chrome 80+, and its derivatives, so there's not universal adoption at this time, nor a guarantee that it will actually become part of the standard. Even so, there will be a substantial portion of users for which such links will work.

These types of links will currently work for Chrome in comments, chat, and the edit preview, but SE's backend CommonMark Markdown processor currently changes the ~ in these fragments into a %7E, which breaks the functionality when such links are included in questions or answers and the post is saved (i.e. it will be fine in the edit preview, but not once posted).

Example link

You can link directly to the bullet point "Naming, including naming programming variables/classes" on the EL&U on-topic page. This link will only work "correctly" in Chrome in the edit preview of this post. It won't work when you are viewing the saved version of this post, because SE's backend processing for posts is converting the ~ to %7E, which breaks the link's extended functionality in Chrome. In other browsers, it will just go to the top of the page, even when editing this answer. Such links do work on SE in Chrome in comments, chat, and in the post's edit preview.

The URL for the above example link is: https://english.stackexchange.com/help/on-topic#:~:text=Naming%2C%20including%20naming%20programming%20variables%2Fclasses. I've added a comment to this post with that link which is fully functional in Chrome just by clicking.

In Chrome, going to the above URL, or clicking on the link in my comment below should result in the page which looks like:

Answer 2

Based on our current roadmap, this isn't work that we will take on, as it doesn't coincide with functional areas that we plan to improve in the near future. We recognize that there's community support for this, but unfortunately, we can't prioritize it at this time.