fallback/progressive enhancement

Components this will probably be most relevant to:

• generic-accordion
• generic-tabs
• generic-disclosure

Currently, its ‘recommended’ to use a button for the ‘headers’ or ‘controls’ of an accordion/tabs component. The problem with this is progressive enhancement, or a fallback if JS is not available; in that case, there will be a button, but that button does not really do anything or ‘control’ anything, which can be confusing to a user.

It may make more sense to just simply fall back to some kind of heading or text node (whatever the user should provide) instead.

If the goal of this project is to ‘enhance’ markup with some functionality like keyboard behavior and accessibility, that might be a nice/elegant fallback.

There are a few ways to go about this, but in any case, there needs to be some sort of relation between a ‘header’ and a ‘panel’:

1: custom header/panel elements

pros: has some similarity with the detail & summary elements, will somewhat elegantly fallback cons: the generic- prefix makes it somewhat awkward

<generic-accordion>
  <generic-accordion-header>Shipping information</generic-accordion-header>
  <generic-accordion-panel>Here is some shipping information</generic-accordion-panel>
  
  <generic-accordion-header>Personal information</generic-accordion-header>
  <generic-accordion-panel>Here is some personal information</generic-accordion-panel>
</generic-accordion>

An added benefit of this pattern is that it could potentially improve the stylability (without having to rely on parts) of generic-switch by doing something like:

<label for="switch">some setting</label>
<generic-switch id="switch">
  <generic-track></generic-track>
  <generic-thumb></generic-thumb>
</generic-switch>

2: require custom attributes

cons: this doesn’t really happen anywhere else in HTML (as far as I know)

<generic-accordion> 
  <h2 x-header>Shipping information</h2>
  <div x-panel>
    Here is some shipping information
  </div>
  <h2 x-header>Personal information</h2>
  <div x-panel>
    Here is some personal information
  </div>
</generic-accordion>

3: slots

pros: will just fallback to a h2 and div const: might affect stylability/customization?

<generic-accordion> 
  <h2 slot="header">Shipping information</h2>
  <div slot="panel">
    Here is some shipping information
  </div>
  <h2 slot="header">Personal information</h2>
  <div slot="panel">
    Here is some personal information
  </div>
</generic-accordion>

4: anchors

As I understand Zach Leatherman handles this by requiring the ‘headers’ to be anchor tags that link to the panels: Progressively enhances from <a> with anchor links pointing to content panels.

I guess this would look something like:

<generic-accordion> 
  <a href="#panel-1">Shipping information</a>
  <div id="panel-1">
    Here is some shipping information
  </div>
  <a href="#panel-2">Personal information</a>
  <div id="panel-2">
    Here is some personal information
  </div>
</generic-accordion>

[thepassle]

It seems to me that each component might fit best into different solutions that you proposed. Are you planning on trying to come up with a more consistent approach that would be used for all of them?

It would be nice to have some kind of strategy for every component eventually yeah. But I think it’d have to be on a component to component basis, see what the best solution is for each component, and then potentially align across the board where possible. So thanks for your input! Very valuable 🙂

My current thinking is that just using slots is probably the best way forward to both be able to support a fallback, as well as a nice developer experience.

[Malvoz]

https://github.com/thepassle/generic-components/issues/10#issue-611523936:

Currently, its ‘recommended’ to use a button for the ‘headers’ or ‘controls’ of an accordion/tabs component. The problem with this is progressive enhancement, or a fallback if JS is not available; in that case, there will be a button

Due to :not(:defined) { display: none }, nothing will actually be displayed to the user in browsers that support custom elements (and subsequently the :defined pseudo class) when JS is disabled.

My approach in solving this (for the Maps for HTML Community Group’s custom element) was to include a <noscript> element and reset display: none. FWIW another approach would be to use the scripting @media feature, if browsers decided to implement it. 🤷‍♂️