Jump Links: ideas for improvement

[bennypowers]

Well hi there!

Today I spent some time working on integrating pfe-jump-links into the rhds (11ty) website.

• Generated a nav list with eleventy-plugin-toc, patching it to allow me to wrap the list in <pfe-jump-links-nav>
• Updated the nunjucks macros already used to define page sections, letting me wrap them in <pfe-jump-links-panel>s
  This gave me some markup that looks like this:

<aside id="toc-aside">
  <pfe-jump-links-nav id="toc-nav" no-header>
    <h2 slot="header">Contents</h2>
    <ul>
      <li><a href="#Overview">Overview</a></li>
      <li><a href="#Sample%20component">Sample component</a></li>
      <li><a href="#Component%20status">Component status</a></li>
      <li><a href="#Demo">Demo</a></li>
      <li><a href="#Style">Style</a>
        <ul>
          <li><a href="#bar">Bar</a></li>
          <li><a href="#logo">Logo</a></li>
          <li><a href="#content">Content</a></li>
          <li><a href="#tray">Dropdown trays</a></li>
        </ul>
      </li>
      <li><a href="#Usage">Usage</a></li>
      <li><a href="#Best%20practices">Best practices</a></li>
      <li><a href="#Behavior">Behavior</a></li>
      <li><a href="#Responsive%20design">Responsive design</a></li>
      <li><a href="#Interaction%20states">Interaction states</a></li>
      <li><a href="#Spacing">Spacing</a></li>
      <li><a href="#Feedback">Feedback</a></li>
      <li><a href="#Foundations">Foundations</a></li>
    </ul>

  </pfe-jump-links-nav>
</aside>
  
<pfe-jump-links-panel id="Overview-panel"
                      scrolltarget="toc-nav"
                      class="section container section--palette-default pfe-jump-links-panel__section">
  <h2 id="Overview" class="section-title">Overview</h2>
  <p>Navigation consists of a menu and utility section meant to help a user orient themselves and move through the website. It’s persistent on every page to ensure a consistent experience across Red Hat’s system of websites.</p>
</pfe-jump-links-panel>

<pfe-jump-links-panel id="Sample%20component-panel"
                      scrolltarget="toc-nav"
                      class="section container section--palette-default pfe-jump-links-panel__section">
  <h2 id="Sample%20component" class="section-title">Sample component</h2>
  <div class="inline-flex centered">
    <img src="/assets/navigation/navigation.svg" alt="Navigation" style="">
  </div>
</pfe-jump-links-panel>

... etc

Which LGTM, but is not working with jump-links

I've identified a few issues that are preventing easy integration:

1. Jump Links, as used, is invisible except at mobile breakpoints. I don't know why
2. jump-links appears to rely on the user setting specific class names on the list items (like sub-nav, has-sub-section, etc). it would be better to not require these, and use the DOM to determine which list items have list children

Those two are (AFAICT) hard blockers to integrating jump links on ux dot (unless, of course, PEBCAK, which is always a possibility). Even if a workaround is found (or intended APIs discovered and used), I still recommend loosening the API requirements here in accordance with the principle "be liberal with what you accept, conservative with what you produce"

Asides from those hard blockers there are a few other things I noticed, and some ideas I'd like to float for improvements:

1. Jump links (v1) strictly requires 2 children, the first being any element, the second being an unordered list. The strictness of this requirement should be relaxed, allowing users to omit the header, and querying for ul or ol
2. there is no anonymous slot, rather the DOM content is copied in. If possible, we should avoid this, even if it means using lots of !important
3. I think it should be possible to remove the <pfe-jump-links-panel> element. We should be able to link directly to headings, and calculate the scroll-spy boundaries via the DOM
4. adding a for attribute on <pfe-jump-links-nav> similarly would let us target specific DOM nodes to scrollspy. this would essentially be the inverse of scrolltarget

[bennypowers]

Paging Drs @wesruv @kylebuch8 @dcaryll @coreyvickery

[zhawkins]

RE:

I think it should be possible to remove the element. We should be able to link directly to headings, and calculate the scroll-spy boundaries via the DOM

While I like this in theory, it would be hard to implement in a CMS environment. We need to make sure we have a very specific way to define sections that should be scanned for headings that are used to build the nav.

The rest I don't really have strong feelings about.

[bennypowers]

it would be hard to implement in a CMS environment.

Can you give me some sample HTML for a difficult page, and any other useful context? That way I'll have a better idea what your needs are.