[Popup] [Tabs] [Details] Global behavior for Navigating into components

[una]

RE: #315

Multiple elements have good use cases for navigating directly to an anchor or text fragment within the component. Examples:

Tabs

Navigate to a specific open tab (i.e. navigate to the 2nd tab in an action bar menu)

Popup

Navigate to a page with a popup open (i.e. cards on a publishing site that tell a story, link to card 2 out of a set of 10)

How might we globalize this behavior for consistency and ease of use between multiple components?

[hidde]

As mentioned in the call yesterday, one thing I feel this behavior should take into account is the nesting of all these kinds of elements:

<a href="#note-1">note 1</a>
<tab>
  <popup>
    <details>
       <summary>Some notes</summary>
       <h2 id="note-1">Note 1</h2>
       <p>…</p>
    </details>
  </popup>
</tab>

If linking to the note-1 fragment would open the popup it is in, it should probably also trigger the opening of other elements that contain it, like any ancestor instances of details and tab, because a rendered popup inside a non-rendered element would still be non-rendered?

Sorry if I'm going outside the scope of this issue, but the same reasoning may apply to other uses cases.

What about non-components that are hidden with hidden/display: none, like when linking to #note-1 in this example:

<a href="#note-1">note 1</a>
<div hidden>
  <div style="display: none">
    <popup>
       <h2 id="note-1">Note 1</h2>
       <p>…</p>
    </popup>
  </div>
</div>

Would authors and users also expect instances of aria-hidden="true" up the tree to be set to “undone” (removed or set to false) when navigating to a fragment inside a popup?

<a href="#note-1">note 1</a>
<div aria-hidden="true">
  <popup>
     <h2 id="note-1">Note 1</h2>
     <p>…</p>
  </popup>
</div>

[gregwhitworth]

During the May 6th call this was discussed and @flackr was actioned to create a proposal for how this would work generically. Do you have any update on this?

[flackr]

Unfortunately I've been completely swamped with other work since then and haven't been able to make the time to properly think through a proposal in this space. The interaction with style in subtrees that don't have their style computed seems like it's going to make things complicated.

I suspect the only way this is going to work is if we ignore whether the popup will eventually be visible and try to open them anyways, since we can't know if they would become visible without opening them.

To this end, when an element is targeted, we should call show (or equivalent) on every ancestor from the root to the element in order. We could stop at the point where the next element's parent is not displayed (i.e. display: none) or at the point where the element itself does not become displayed, or just call show regardless of the resulting style. Ignoring the intermediate computed styles after each show call is likely the most efficient since we may be able to update all of the styles in a single pass.

[gregwhitworth]

@flackr friendly ping on this

[mfreed7]

Just a quick note that these same concerns likely apply to the new approach to popup: #455

In the new proposal, you could have:

<div popup=popup hidden>
   Some hidden text here
</div>

and the user could be following a link to the text fragment "hidden text here". In that case, should the UA remove the hidden attribute and show the popup?

[scottaohara]

this might need to be contingent depending on the popup value. like, i don't think this would make sense for a custom listbox, or even a tooltip. There could be value in a more generic "popup disclosure widget" type component... arguably someone could eventually use a hidden=until-found. But i think there'd need to be some serious author guidance around where this would be appropriate behavior or not.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.