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

Add pre/post config to ToC #8338

Open
uPagge opened this issue Mar 17, 2021 · 22 comments
Open

Add pre/post config to ToC #8338

uPagge opened this issue Mar 17, 2021 · 22 comments

Comments

@uPagge
Copy link

uPagge commented Mar 17, 2021

According to the html5 standard, there must be a title in the nav tag. However, the TOC is generated without the ability to specify this header

It should be like this. This helps visually impaired browsers to read what this section is responsible for.

<nav>
  <h1>Navigation</h1>
  <ol>
    <li></li>
    <li></li>
  </ol>
</nav>

P.S. If you wish, you can make sure that this is done in Google. They add an h tag for the sections while hiding it, since it is only needed for semantic markup.

изображение
изображение

@uPagge
Copy link
Author

uPagge commented Mar 17, 2021

In any case, reference to the standard

https://html.spec.whatwg.org/multipage/sections.html#the-nav-element

Even though there is one example there where the h tag is not used in nav. It is considered best practice to add a title. It would be great if you provided such an opportunity.

@davidsneighbour
Copy link
Contributor

It' the first time I am reading that the standard requires a title tag. It doesn't, and h1 is NOT a title tag. It's the topmost header tag and the standard suggests to have only one in one single document. That's a suggestion. Having an h1 in an automatically created TOC makes no sense for 99% of pages and adding an h1 title to a nav that isn't even the sites main navigation will result not only in SEO issues but issues in all parsers that try to build a structure from your page.

Not sure where you got that from, the only reason I would expect some form of title, but then in form of an title-attribute, would be for a11y if the navigation is not the main navigation.

@uPagge
Copy link
Author

uPagge commented Mar 18, 2021

Perhaps the problem is in my English, please forgive me in advance, as I have to use a translator. An error in translation, it does not require a title, but an h tag. This is optional for the nav, but it is good practice as screen readers will be able to read this section for people with vision problems.

Originally in the html5 spec there was no such thing as h1-h6, there was only an h tag. And the numbering remained only for backward compatibility with html4

If you look at the specification, you will see that more than one h1 tag can be used and the document is considered valid in html5.

image

https://html.spec.whatwg.org/#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements

Problems with parsers arise now, because the nav section does not have an h tag, instead of a heading there is "Untitled Section"

"Not sure where you got that from"

From html5 spec

@davidsneighbour
Copy link
Contributor

Screenreader: aria-title attribute on the nav tag. Sorry, but what you want is really something that might have been thought about 10 years ago but is not part of the "living standard" of HTML. It's a specific use case for your project, I understand, but making it accessible means using aria-attributes on the tags, not adding more tags inside.

@jmooring
Copy link
Member

jmooring commented Mar 18, 2021

Perhaps an approach where one could override the HTML that encapsulates the outer <ul>...<\ul>

Then you could do:

[markup]
  [markup.tableOfContents]
    pre = "<nav id="TableOfContents"><h1>Something</h1>"
    post = "</nav>"

Or set the values to blank if you want to do the encapsulation within a template:

[markup]
  [markup.tableOfContents]
    pre = ""
    post = ""

There's precedent for the pre and post approach with Menu Entry Variables.

@uPagge
Copy link
Author

uPagge commented Mar 19, 2021

@jmooring Oh, thanks a lot, I will definitely try this way

@jmooring
Copy link
Member

This was a suggestion for a software enhancement. It is not an active feature.

@bep bep added this to the v0.82 milestone Mar 19, 2021
@bep
Copy link
Member

bep commented Mar 19, 2021

@jmooring good suggestion. We do also have an issue about exposing the ToC as a data structure, allowing people to have their own templates, but I guess this is a easy improvement.

@nternetinspired
Copy link

I'd suggest that aria-label may be more appropriate in this situation, given that it's addition will not visually affect existing sites. In additon, I would suggest that an ordered list, <ol> is a better choice for a table of contents as the order in which the items are presented does matter, the content author explicitly defined that order and presenting the items in a different order (as you can with an unordered list) would affect the meaning.

💯 should not be an <h1>!

@moorereason moorereason changed the title HTML5 standart | TOC HTML5 standard | TOC Mar 19, 2021
@uPagge
Copy link
Author

uPagge commented Mar 19, 2021

@nternetinspired You are correct about the order, but this can already be changed using configuration.

markup:
  tableOfContents:
    ordered: true

@bep bep changed the title HTML5 standard | TOC Add pre/post config to ToC Mar 19, 2021
@nternetinspired
Copy link

…yes, but I'd argue that the default should semantically correct.

@jmooring
Copy link
Member

...yes, but I'd argue that changing the default would break a lot of sites. Those who want ordered list have already configured their sites accordingly.

@nternetinspired
Copy link

nternetinspired commented Mar 19, 2021

It would fix a lot of sites. Using an unordered list for a table of contents is incorrect. Changing that may lead to some minor visual changes but document structure and accessibility would be improved.

Just my $0.02 and I'm more than happy to leave it at that. As already pointed out, I can correct the semantics of my own sites quite easily, but I believe it would be preferable for those with less experience to not have to. My general preferance will always be for ‘better by default’.

@davidsneighbour
Copy link
Contributor

davidsneighbour commented Mar 19, 2021

Yep, let's leave it at that. There is no such thing as a TOC in HTML. Using a list for an overview of headings is not intended. Be it unordered or ordered. In the current HTML standard the nearest that would come to something like a TOC would be a nav element with subsequent links to the sections of the page. If one of these links would have child-sections then some form of sub-division is required. which could be a div or a list or whatever element you find fitting.

Having the TOC as data structure will solve all these issues and keeps Hugo out of religious conversations (like this one).

@jmooring
Copy link
Member

@davidsneighbour,

I respect the ideas and concerns raised by both @uPagge and @nternetinspired. The title of this issue is "Add pre/post config to ToC" and it has been flagged as a "GoodFirstIssue." If we are going to take a swing at incremental improvement before implementing TOC as a data structure (which has been open for 31 months) then conversations like this are important and healthy.

For the record, I agree with @nternetinspired. If you are going to use list items to display a table of contents, then the list items should be ordered. I just don't want to break existing sites without a really good reason.

Out of curiosity I looked at a few higher-profile Hugo sites (digital.gov, getbootstrap.com, kubernetes.io), and they would all be visually impacted by a <ul> to <ol> TOC change. Of those three sites, digital.gov would see the most change.

Before

image

After

image

@uPagge
Copy link
Author

uPagge commented Mar 19, 2021

In fact, I find it strange that as a developer I cannot influence this area and make it the way I want it.

It seems to me that adding a similar feature is an excellent solution to this problem.

[markup]
  [markup.tableOfContents]
    pre = ""
    post = ""

By default, you can leave it as it is generated now, but give the opportunity to override this behavior.

@nternetinspired
Copy link

Apologies if my comments have ruffled feathers, that was never my intention. I am often direct and tone-of-voice does not easily transfer to type. I should have introduced myself!

Hi 👋 I'm Seth. I try to make user-centric sites, both professionally and in my free time. I love Hugo and I'd like to contribute where I can.

@jmooring Thanks. Agree, there would be a significant, not minor, change visually. My primary concern was a11y and UX.

@bep
Copy link
Member

bep commented Mar 19, 2021

We're not changing the default.

@bep bep modified the milestones: v0.82, v0.83 Mar 21, 2021
@bep bep modified the milestones: v0.83, v0.84 May 1, 2021
IveGotNorto added a commit to IveGotNorto/hugo that referenced this issue Jun 15, 2021
Pre and post allow users to add semantically correct headings to ToC
without breaking existing functionality.

See gohugoio#8338
IveGotNorto added a commit to IveGotNorto/hugo that referenced this issue Jun 17, 2021
Pre and post allow users to add semantically correct headings to ToC
without breaking existing functionality.

See gohugoio#8338
@bep bep added this to the v0.115.0 milestone Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 4, 2023
@bep bep modified the milestones: v0.120.0, v0.121.0 Oct 31, 2023
@Paul-Stern
Copy link

Hello everyone! My name is Paul, I'm a newcomer here and I would like to contribute to this issue. The issue is open but a quick look at the discussion above casts some doubts whether it still needs any work to be done. So is it supposed to make any changes to the project's code about this issue now? I am asking as I was looking for an issue for my first contributions and found this one.

@bep bep modified the milestones: v0.121.0, v0.122.0 Dec 6, 2023
@bep bep modified the milestones: v0.122.0, v0.123.0, v0.124.0 Jan 27, 2024
@bep bep modified the milestones: v0.124.0, v0.125.0 Mar 4, 2024
@bep bep modified the milestones: v0.125.0, v0.126.0 Apr 23, 2024
@bep bep modified the milestones: v0.126.0, v0.127.0 May 15, 2024
@bep bep modified the milestones: v0.127.0, v0.128.0 Jun 8, 2024
@bep bep modified the milestones: v0.128.0, v0.129.0 Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants