[feat] Add jump links to all component/foundation pages about red-hat-design-system

[dcaryll]

@coreyvickery let's try a horizontal jump link on component pages. It's a lot of links, so we'd have to reduce the padding/font size of the jump links which isn't ideal, but would be a good test for horizontal jump link styles. It would be easier to integrate than vertical jump links. Thinking right below the title bar.

[coreyvickery]

@dcaryll @wesruv

Here's the Spacing page with horizontal jump links, desktop and mobile. I don't know what the status is of the web component, so we may have to use raw code for now. Additional comments welcome here or in the XD.

https://xd.adobe.com/view/2bc4c20e-e89e-4a19-8f6d-172a5a64db36-7e97/

[bennypowers]

See. patternfly/patternfly-elements#1926
TL;DR: before committing to using <pfe-jump-links> for this I'd like to see if we can improve that element's APIs, namely, to allow it to wrap an existing, server-rendered <nav><ul> without special classes or markup

[bennypowers]

@coreyvickery the link above (old as it may be) doesn't appear to have specs for TOC/jump links. Please advise

[coreyvickery]

@markcaron This seems like a quick win for design unless more work is needed on the dev side. Ronnie or Marionne could easily add jump links to the new Footer component page.

[bennypowers]

From Trello:

Hey ok so this looks p. good

We can apply this in the macros which generate sections for pages, which means there should be little or no change to the existing markup.... with one very important exception:

The problem that we're having is that most or all pages have headings that do not follow an incremental heirarchy. meaning that we could have an <h2> followed by an <h4> with no intervening <h3>.

This causes the plugin which scans for headings and generates the table of contents to fail, because it expects a strict heirarchy. We've discovered that this is strictly-speaking allowed under wcag (w3c/wcag#655) but nonetheless causes problems for our table-of-contents generating plugin.

potential solutions:
1 - refactor docs pages to follow strict heading heirarchy
2 - patch the ToC plugin to accept a looser heirarchy
3 - scrap plugin and try something homebrew

If we go with solution (1), we need the content authors to be involved, since we as developers are uncomfortable making content decisions without them (e.g. "this was an h5, should it be an h2 now, or the child of the previous h3, or what?) in other words - we don't know the intended heirarchy. If header styling (e.g. font size and weight) are an issue, we can solve that with css

if we go with (2), we could get stuck in the weeds

(3), similarly we can't give a solid ETA just yet

and many thanks to @brianferry for his help and input on this

@markcaron says:

definitely a good idea! I don't think it has this feature. I could envision something like:

<rh-table-of-contents headings="h2, h3, h4">

Which would nest those as needed.

Kelsey Swanson added on Mar 29

I think that pfe-jump-links is trying to solve too many problems. It has a lot of a11y issues. table of contents is way more useful in general especially for A11y. I recommend we create a table of contents component and possibly remove or really refine pfe-jump-links

[coreyvickery]

@dcaryll @markcaron Still think this is needed given the IA updates to the Component section pages? Maybe it still is on the other long Foundation section pages.

[bennypowers]

@kelsS recently drafted a PoC for a table of content component

[markcaron]

Will revisit having jumping links once new docs IA is complete. This is a good idea.