Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand Section Links documentation and add a section for Custom Anchors #33531

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,11 @@
### A third-level heading
```

![Screenshot of rendered GitHub Markdown showing sample h1, h2, and h3 headers, which descend in type size and visual weight to indicate descending hierarchy level.](/assets/images/help/writing/headings-rendered.png)

Check warning on line 24 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 162 characters long.

When you use two or more headings, GitHub automatically generates a table of contents that you can access by clicking {% octicon "list-unordered" aria-label="The unordered list icon" %} within the file header. Each heading title is listed in the table of contents and you can click a title to navigate to the selected section.

![Screenshot of the README file in the GitHub Docs open source repository with the drop-down menu for the table of contents exposed. The table of contents icon is outlined in dark orange.](/assets/images/help/repository/headings-toc.png)

Check warning on line 28 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 185 characters long.

## Styling text

Expand Down Expand Up @@ -53,7 +53,7 @@

Quoted text is indented, with a different type color.

![Screenshot of rendered GitHub Markdown showing sample quoted text. The quote is indented with a vertical line on the left, and its text is dark gray rather than black.](/assets/images/help/writing/quoted-text-rendered.png)

Check warning on line 56 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 167 characters long.

{% note %}

Expand All @@ -69,7 +69,7 @@
Use `git status` to list all new or modified files that haven't yet been committed.
```

![Screenshot of rendered GitHub Markdown showing the appearance of characters surrounded by backticks. The words "git status" appear in a fixed-width typeface, highlighted in light gray.](/assets/images/help/writing/inline-code-rendered.png)

Check warning on line 72 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 184 characters long.

To format code or text into its own distinct block, use triple backticks.

Expand All @@ -82,7 +82,7 @@
```
````

![Screenshot of rendered GitHub Markdown showing a code block. The words "git status," "git add," and "git commit" appear in a fixed-width typeface, highlighted in light gray.](/assets/images/help/writing/code-block-rendered.png)

Check warning on line 85 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 173 characters long.

For more information, see "[AUTOTITLE](/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks)."

Expand All @@ -96,7 +96,7 @@
The background color is `#ffffff` for light mode and `#000000` for dark mode.
```

![Screenshot of rendered GitHub Markdown showing how HEX values within backticks create small circles of color. #ffffff shows a white circle, and #000000 shows a black circle.](/assets/images/help/writing/supported-color-models-rendered.png)

Check warning on line 99 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 173 characters long.

Here are the currently supported color models.

Expand Down Expand Up @@ -139,6 +139,10 @@

{% data reusables.repositories.relative-links %}

## Custom anchors

{% data reusables.repositories.custom-anchors %}

Comment on lines 139 to +145
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • does only one use/occurrence warrant a reusable?
  • adding that info to any of the previous reusables contextually might actually be better, so it gets added to the about-readme docs and other occurrences of the neighboring content too?
  • or if separate, perhaps add the same chapter with reusable to other place that include the two other reusables, like about-readmes…?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say no. However, that's how all of those sections seem to be formed, so I was just following suit. 🤷‍♂️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: does it need a separate section, or having that contextually appended to some of the existing content would provide more utility and be included with such reusable to all the places they're being currently included?

Copy link
Contributor

@felicitymay felicitymay Aug 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the discussion @janbrasna 👋🏻

does only one use/occurrence warrant a reusable?

Good point. We usually add a reusable file only if we want to use one or more sentences in more than one location.

I think that this content only needs to be included in the Basic writing and formatting syntax article because it's not something that most people will want to do.

So it would be worth moving the content directly into this article and deleting the reusable.

## Images

You can display an image by adding <kbd>!</kbd> and wrapping the alt text in `[ ]`. Alt text is a short text equivalent of the information in the image. Then, wrap the link for the image in parentheses `()`.
Expand Down Expand Up @@ -225,7 +229,7 @@

![Screenshot of Markdown in {% data variables.product.prodname_vscode %} showing how indented bullets align vertically with the first letter of the text lines above them.](/assets/images/help/writing/nested-list-alignment.png)

![Screenshot of rendered GitHub Markdown showing a numbered item followed by a bulleted item nested one level to the right, and another bulleted item nested yet further to the right.](/assets/images/help/writing/nested-list-example-1.png)

Check warning on line 232 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 180 characters long.

To create a nested list in the comment editor on {% data variables.product.product_name %}, which doesn't use a monospaced font, you can look at the list item immediately above the nested list and count the number of characters that appear before the content of the item. Then type that number of space characters in front of the nested list item.

Expand All @@ -246,7 +250,7 @@
- Second nested list item
```

![Screenshot of rendered GitHub Markdown showing a list item prefaced by the number 100 followed by a bulleted item nested one level to the right, and another bulleted item nested yet further to the right.](/assets/images/help/writing/nested-list-example-2.png)

Check warning on line 253 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 203 characters long.

For more examples, see the [GitHub Flavored Markdown Spec](https://github.github.com/gfm/#example-265).

Expand Down Expand Up @@ -383,7 +387,7 @@

`Let's rename \*our-new-project\* to \*our-old-project\*.`

![Screenshot of rendered GitHub Markdown showing how backslashes prevent the conversion of asterisks to italics. The text reads, "Let's rename our-new-project to our-old-project."](/assets/images/help/writing/escaped-character-rendered.png)

Check warning on line 390 in content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md

View workflow job for this annotation

GitHub Actions / lint-content

Images alternate text should be between 40-150 characters

Image alternate text is 177 characters long.

For more information on backslashes, see Daring Fireball's "[Markdown Syntax](https://daringfireball.net/projects/markdown/syntax#backslash)."

Expand Down
25 changes: 25 additions & 0 deletions data/reusables/repositories/custom-anchors.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
Use HTML anchor tags (`<a id="unique-anchor-name"></a>`) to create navigation anchor points to any place in the document.
Copy link
Contributor

@felicitymay felicitymay Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to suggest a few small changes here to align better with the other sections:

Suggested change
Use HTML anchor tags (`<a id="unique-anchor-name"></a>`) to create navigation anchor points to any place in the document.
You can use standard HTML anchor tags (`<a name="unique-anchor-name"></a>`) to create navigation anchor points for any location in the document.


> [!NOTE]
> Custom anchors will not be included in the document outline/Table of Contents.
Comment on lines +1 to +4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the syntax here is more of a general info ("writing on github", i.e. anywhere markdown is supported…), so implying a "document" when that might be post/comment/review is not completely correct. (the reusable gets included in several places/contexts…)

basically headings won't create anchors in comments, while custom named anchors are preserved so can be used as anchors, say even inside collapsed details elements in PR/review etc.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, that's a good catch.

Do you have any thoughts on better wording? I felt the note was important in case people expected the same behavior as octothorpes, but I'm certainly not married to the verbiage.

As a bit of context, one of the things that led me to write this section in the first place is that there are quite a few docs on MS Learn that use anchor tags. I was about to fix some inconsistencies in a couple docs, but it turned into a rabbit hole of following a bunch of anchors and a fair amount of duplicated text.

The place I ultimately landed my focus was on the anchors, partially as something I wanted to both verify and ensure consistency of, since I wanted to fully understand how they were being interpreted and mangled, before getting into the rest of it all. But it wasn't mentioned, so I figured I'd experiment and then document for posterity. 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you e.g. demonstrate the difference between heading links that are not created inside comments, whereas custom anchors are, it'll give you the path to also mention autogenerated ToC for documents won't include them (but in context demonstrating the anchor use is not restricted to just documents but any input that accepts md on the site…)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for opening this discussion, that's a great point that I overlooked.

We could revise this note to be more general - something like:

Any HTML you include in markdown content is rendered directly. If you include custom anchors for headings in a markdown file, the anchors are not recognized as headings by the markdown processor.

Link to custom anchors by using the `id` given to the anchor.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that might get filtered in situations where classes and ids are stripped, but ‹a name="foo"> will still work — not sure whether that's more official, but is definitely preferred, and even the own docs guides use name in examples: https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide#adding-anchors-to-preserve-links

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(IIRC id gets stripped in wikis, so ‹a› name is a must there.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or in some contexts there's id="user-content-foo" prepended to it so it's hard to explain beforehand what the value in given md context would be …

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that might get filtered in situations where classes and ids are stripped, but ‹a name="foo"> will still work — not sure whether that's more official, but is definitely preferred, and even the own docs guides use name in examples: https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide#adding-anchors-to-preserve-links

I did quite a bit of testing to ensure I was documenting actual behavior. The way I wrote it, at least at the time, was what my of course non-exhaustive testing revealed.

Being an undocumented "feature," that's all that was really available for me to do, without being familiar with the pipeline that produces the final rendered content.

My thinking was that, in the course of this PR, a formal behavior could be either gleaned from the source or defined here, to be formally implemented however it is settled upon. Since it's all over the place in other ms learn documents, it seems only fair for it to be documented. 🙂

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding to that thought, I do kinda think a formal spec for the feature and perhaps even exposure of it in the slash menu or something for didcoverability is warranted.

Otherwise, it's effectively an unsafe-for-public-consumption internal abuse of the markup that IMO shouldn't be used in public open source documents at all. Lead by example and all that. 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many systems using many renders and formatting libraries used around the site, so there's no formal spec how that behaves once you start going too much into detail (as every place has its own implementation specifics…) — so it's better to be safe and a bit vague;)

(The "id" behav has changed over the past decade, whereas "name" stays consistent, and is used in style guide docs as an example, that's why I'm offering it as a more stable alternative; also not interfering with the rest of the page if one's not too careful…)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had forgotten that we already have guidance on custom anchors for the GitHub docs site itself 🙈

I agree with @janbrasna that name would be better here. The GitHub docs site is rendered using different process from the content on the GitHub platform, but it will avoid introducing confusion.

The GitHub docs have limited information on the use of HTML in markdown files and fields that accept markdown. My understanding is that this is intentional - we don't want to end up writing an HTML primer, there are lots of those already. However, it sounds as if adding information on custom anchors will be useful to users.

Copy link
Contributor

@felicitymay felicitymay Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Link to custom anchors by using the `id` given to the anchor.
You can link to a custom anchor with the name, `name`, you gave the anchor. The syntax is exactly the same as when you link to an anchor that is automatically generated for a heading.


For example:

```markdown
# Section Heading

Some body text of this section.

<a id="my-custom-anchor-point"></a>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replacing with name to align with the information on contributing to GitHub docs.

Suggested change
<a id="my-custom-anchor-point"></a>
<a name="my-custom-anchor-point"></a>

Some text I want to provide a direct link to, but which doesn't have its own heading.

...more content...

[A link to that custom anchor](#my-custom-anchor-point)
```
Comment on lines +10 to +21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TL;DR the example is somewhat lengthy to just demonstrate the feature (and lack differentiating / demonstrating the implicit header anchors at the same time); maybe someone from the content/triage could suggest something more to the point?

(if not, at least the ellipsis etc. in the dummy content could be typographically correct?)

Copy link
Author

@dodexahedron dodexahedron Aug 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a semi-common issue in that document, as a whole, actually, so I agree and think one or more advanced or details or whatever pages are warranted for various features in that rather large document (including this one).

The github documentation is a bit more monolithic.in a lot of places than other ms learn topics. I don't know if there are any high level goals around consistency between them, organization-wise, but that's just my 2 cents on that specific concept.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would also aid mobile-friendliness. Github doc pages can be VERY heavy on mobile browsers.


> [!TIP]
> Custom anchors are not considered by the automatic naming and numbering behavior of automatic heading links.\
> To avoid ambiguous references, use a unique naming scheme for custom anchors, such as adding a prefix to the `id` attribute value of custom anchors.
Comment on lines +23 to +25
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can probably delete this if we expand the note above as suggested 🤔

55 changes: 55 additions & 0 deletions data/reusables/repositories/section-links.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,58 @@
You can link directly to a section in a rendered file by hovering over the section heading to expose {% octicon "link" aria-label="the link" %}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can link directly to a section in a rendered file by hovering over the section heading to expose {% octicon "link" aria-label="the link" %}.
You can link directly to any section that has a heading. To view the automatically generated anchor in a rendered file, hover over the section heading to expose the {% octicon "link" aria-label="the link" %} icon then click the icon to display the anchor in your browser.


![Screenshot of a README for a repository. To the left of a section heading, a link icon is outlined in dark orange.](/assets/images/help/repository/readme-links.png)

[Headings](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#headings) automatically create anchors which have default names created from the text of the heading, with the following rules:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same ref issue as above — i believe both could be avoided if the addition is somehow blended with the existing content, not creating a specific chapter for it…

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I struggled with that part for quite a while and was expecting something to that effect to be part of the feedback.

I wasn't really sure where was most appropriate to say all this stuff, how best to avoid being repetitive, and whether it necessarily belonged together or not, among other things.

Believe it or not, this version is like ⅓ the length of the original I had written up on my local machine before editing it down for commit. 😅

Plus it was I think one of the final parts I wrote, chronologically, so I'm sure there was a bit of fatigue involved. 😆

I'm not attached to any of the content, as written, so definitely don't hold back for sake of my ego or anything. All I want is a good and slightly more complete document, however it ends up. 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having read the sentence before this line, I think we need to explain about automatically generated anchors earlier.

Suggested change
[Headings](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#headings) automatically create anchors which have default names created from the text of the heading, with the following rules:
If you need to determine the anchor for a heading in a file you are editing, you can use the following rules:


* Generated identifiers are UTF-8 URI fragments.
* See [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 3.5](https://www.rfc-editor.org/rfc/rfc3986#section-3.5).
Comment on lines +7 to +8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I'm curious about what additional information this reference adds for users. Unless you have a good reason for including it, I'd be inclined to delete these two lines.

* All ASCII letters are converted to lower-case.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's too specific to be always true;] Quickly checking, wiki encodes Á (which is ascii) instead of lowercasing it as-is, encoding it as percent/multibyte instead. 🤷

So I'd stay away from referring ASCII, Unicode codepoints, multibyte chars, RFC rules etc. as these can change any day:/ and may differ between readmes/files, Jekyll-built pages, wikis, projects, comments, discussions etc.

* Spaces (UTF-8 codepoint `0x20`) are replaced by hyphens (`-`).
* Leading and trailing whitespace is removed.
* All other whitespace characters are removed.
* Paired formatting markup characters are removed, leaving only their contents (e.g., `_italics_` becomes `italics`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Paired formatting markup characters are removed, leaving only their contents (e.g., `_italics_` becomes `italics`).
* Paired formatting markup characters are removed, leaving only their contents (for example, `_italics_` becomes `italics`).

* Punctuation and other characters not allowed in a URI fragment are removed.
* Other multi-byte UTF-8 characters which are valid in URI fragments are not modified.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felicitymay I believe these two bullets would still refer to the RFC syntax for explanation how the string gets transformed (i.e. what's allowed =to stay, and what's not) so this may need a teeny tiny tweaking if removing #33531 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, I suggest that we provide a set of simple bullets in this article as general guidance, but give the link to the RFC syntax for anyone who wants more detailed information.

* Percent Encoding is not performed.
* See [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 2.1](https://www.rfc-editor.org/rfc/rfc3986#section-2.1) for the definition of Percent Encoding.
Comment on lines +16 to +17
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can omit these bullets because you've already explained how we process characters that would otherwise need to be encoded this way.

Suggested change
* Percent Encoding is not performed.
* See [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 2.1](https://www.rfc-editor.org/rfc/rfc3986#section-2.1) for the definition of Percent Encoding.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to omit as it's not always the case. In wiki the links do not strip any nonASCII chars, but rather do "HTML-safe" i.e. url encode all chars outside of the lower ASCII, both "á" and "ř" get escaped as a multibyte 🤷

* If more than one heading has content which would result in identical output by these rules, unique names for instances after the first identical name are generated by appending a hyphen and an auto-incrementing integer in the order they appear in the rendered document.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Room for simplification here:

Suggested change
* If more than one heading has content which would result in identical output by these rules, unique names for instances after the first identical name are generated by appending a hyphen and an auto-incrementing integer in the order they appear in the rendered document.
* If the automatically generated anchor for a heading is identical to an earlier anchor in the same document, a unique identifier is generated by appending a hyphen and an auto-incrementing integer.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a note based on the caution below:

Suggested change
> [!NOTE]
> If you edit a heading, or if you change the order of headings with "identical" anchors, you will also need to update any links to those headings as the anchors will change.

**Examples**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For accessibility reasons, we don't use bold in this way. It also seems as if we don't tend to use the text "Examples" in this document, so I suggest we delete this line.

Suggested change
**Examples**


A simple heading and a section link pointing to it:

```markdown
# Sample Section

TEXT

A link to that section: [Link Text](#sample-section).
```

A heading containing invalid characters, UTF-8 characters, two consecutive spaces between the first and second words, and formatting markup:

```markdown
# This'll be a _Helpful_ Section About the Greek Letter Θ!

TEXT

A link to that section: [Link Text](#thisll--be-a-helpful-section-about-the-greek-letter-Θ).
```

Multiple headings sharing the same text:

```markdown
### This text is the same
...content of the first section...

# This text is the same
...content of the second section...

Link to the first section: [Name](#this-text-is-the-same).

Link to the second section: [Name](#this-text-is-the-same-1).
```

> [!CAUTION]
> Changing the order of sections having headings with the same name will cause their generated identifiers to change, as well, resulting in links to those sections no longer pointing to the same locations they previously pointed to.\
> Use [Custom anchors](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#custom-anchors) to create anchors that will not be automatically changed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will not pass wrt style guide for l10n issues, inline links are not preferable, see the style guide for examples how to link relevant sections, +autotitle use for easier translations.

Comment on lines +55 to +58
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great point and well worth making.

However, it doesn't qualify as a caution in the user docs because the content includes descriptions of how to delete repositories and cause major problems in an enterprise server version. We keep caution for actions that have permanent implications (see Caution).

I think it would be more helpful to users to add a note earlier in this section about the need for care when linking to autogenerated anchors, so I've added a suggestion there in place of this.

Suggested change
> [!CAUTION]
> Changing the order of sections having headings with the same name will cause their generated identifiers to change, as well, resulting in links to those sections no longer pointing to the same locations they previously pointed to.\
> Use [Custom anchors](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#custom-anchors) to create anchors that will not be automatically changed.

Loading