The future of missing.js

[geoffrey-eisenbarth]

missing.js

The goal of missing.js is to provide a comprehensive collection of common UI widgets and behaviors that:

• don’t expect the website author to use a particular framework or library,
• are small in terms of bandwidth,
• are headless (i.e. don’t include any styling by default) but have optional style sheets with default styling (e.g. missing.css),
• are implemented with simple and well documented code,
• are easy to use, and
• have exemplary accessibility.

To that end, I am creating this discussion to:

1. create a ranked list of desired UI widgets,
2. determine some naming conventions,
3. discuss css implementation details, and
4. discuss js implementation details.

Widget list

Below is a first (and relatively unranked) draft of the widget list; suggestions for additions are greatly appreciated. Names and rankings are subject to change, please speak up if you feel like either should be change and I'll happily edit this post. Once we feel like we have a good list going, we can chunk it up into milestones and open GH issues for them.

ARIA APG Patterns (click to toggle)

1. tabs APG (future: consider features like closing, selecting or reordering)
2. feed APG
3. menu, menu-item, menu-button APG (add context menu support, polyfill commandfor support)
4. toolbar APG
5. tooltip APG (polyfill for anchor positioning?)
6. listbox APG
7. combobox APG OpenUI (utilize <datalist>, support chip input c.f. franken ui)
8. menu-bar, menuitem-radio, menuitem-checkbox APG
9. carousel APG
10. multithumb-slider APG
11. grid APG Adobe
12. tree view APG
13. treegrid APG
14. window splitter APG

Non-APG Patterns (click to toggle)

1. input masking
2. scroll-box element (internals.role = region, tabindex = 0)
3. data table ShadCN
4. multi-select checkbox Roselli
5. close button (for .titlebar in alerts, dialogs, etc)
6. toggle button group: A series of toggle buttons, e.g. bold/italic/underline or flush-left/flush-right/centered/justified. Can be exclusive or multi-selectable.
7. card link: An article where clicking anywhere on the article (that isn’t itself clickable) activates a certain link or button or other action. This can be implemented in css (see “card pseudo element hack”), but a JS implementation would be composable with other components (e.g. a gridlist with cards could activate the cards).
8. progress bar (bare bones native impl as <progress>, but if we wanted to display percentage values, might require more)
9. drop-down navigation
10. mobile-nav expander (can this be done framework agnostic?)
11. calendar/date/time widgets
    a) is <input type=date|time|datetime-local> sufficient?
    b) support non-Gregorian calendars, localization support
    c) date range picker (e.g. booking a hotel)
12. color picker (is <input type=color> sufficient?)
13. scrollspy FrankenUI
14. avatar OpenUI ShadCN
15. bibliography (low on my list bc bibhtml does a wonderful job)

For completeness, here is a list of the remaining ARIA APG Patterns that either have good or partial native HTML support. It should be determined if we want to add implementations of any of them:

Remaining ARIA APG Patterns (click to toggle)

1. accordion: use <details name>
2. alert: use <div role=alert>. Are there other impl details that make this worth promoting? What about role=status and role=alertdialog? Are these different from "toasts" in any ways?
3. alert dialog: use <dialog role=alertdialog>? Implicit role of <dialog> is role=dialog.
4. breadcrumb: js not required, author must:
   a) place it inside a <nav>
   b) give it an accessible name
   c) set aria-current=page if the element representing the current page is a link
   d) note: there is no role=breadcrumb
   e) note: earlier proposal suggested that each “crumb” can open a menu that shows other items on that level of the hierarchy
5. button: use <button>
6. checkbox: use <input type=checkbox>
7. dialog (modal): use <dialog>
8. disclosure (show/hide): use <details>
9. landmarks: use <aside>, <footer>, <header>, <main>, <nav>, <section aria-label>, <form>, and <search>
10. link: use <a>
11. meter: use <meter>
12. radio group: use <input type=radio name>
13. slider: use <input type=range>
14. spinbutton: use <input type=number>. I'm a little iffy on this, does type=number sufficiently cover the pattern? Looking at the APG example, it seems like not.
15. switch: use <input type=checkbox role=switch>. As of writing, this requires significant CSS in order to style as a switch.
16. table: use <table>

Naming conventions

Thanks to deniz, we have two great utility functions for creating behaviors and custom elements. The following is a list of considerations that I think should be nailed down for a large number of the use cases above before implementations are started:

• Are there situations that work better as a behavior than a custom element?
  • Behaviors currently need to be re-initialized for dynamically created elements: this happens for free with custom-elements
  • Custom elements have access to the ElementInternals API, requiring significantly less markup
  • Behaviors don't require dash-separated names, can be hooked directly into the role attribute. Probably more compatible with existing alternative CSS solutions
• Custom elements require dash-separated names, which pretty much ensures that existing CSS styles will not apply to them trivially
  • We started off with aria-tablist, aria-tab, aria-tabpane, aria-feed, aria-menubar, aria-menu, aria-menu-item, but how robust is this?
  • Referencing the list of APG Patterns above, it seems to work fairly well: aria-tooltip, aria-carousel, aria-tree-view|grid, aria-window-splitter
  • We could simplify this as <a-tablist>, <a-menubar>, maybe <an-alert>?
  • The aria- prefix seems a little out of place for non-APG patterns: <aria-input-mask> / <aria-scroll-box> (but <an-input-mask> and <a-scroll-box> could work).
  • Not all custom elements have to have the same prefix, we could distinguish between APG Patterns and other widgets this way
  • We could use some prefix related to "missing", but 1) is <missing-input-mask> too long? and 2) I'm not crazy about any abbreviations to "missing".
• For the sake of the missing.css website / documentation, is there a difference between "Components" section and "ARIA" section? What is the deciding factor on whether a widget gets put in one vs the other? Should these pages be combined at some point?

CSS implementation

Our goal is to allow anyone to style these widgets. How can we best facilitate that?

• No other library is going to have existing CSS rules for e.g. <aria-tab>, whereas they might have rules for <li role=tab>. Do we care about this? Is there something we can do about this, or is it enough to say "we have provided basic styles with plenty of CSS vars for hooking in your own styles, and you're free to write your own style sheets?

• The default CSS display value for custom elements is inline, which is at odds with e.g. <aria-tabpanel> which needs to be display: block. In order to set this in a CSS framework agnostic way, we'd have to set it in the Shadow DOM (which imo is okay). Are there any issues with setting a few very simple CSS styles in the shadow DOM?)

JS implementation

• Components should mutate their child elements as little as possible. They should be able to initialize themselves when the children have already been mutated (i.e. if a live DOM tree is stringified and restored, such as during htmx history restoration).

• Components should emit events liberally for interactions performed on them, so that their behavior can be hooked into.

• Styles (that are not strictly required for functionality) should be published in a CSS style sheet (rather than being embedded in the component, or requiring a dependency like Tailwind). The components should be fully usable without the style sheet, i.e. users should be able to write their own style sheets instead.

• Use of Shadow DOM should be avoided, completely if possible. This is to avoid problems in integrating with other libraries, particularly htmx.

tag(): the cornerstone

Creation of custom elements is facilitated by the excellent tag() function that deniz recently put together. A few thoughts that might help us avoid some more boilerplate:

• Emit events for connectedMoveCallback() and adoptedCallback()
• Add MutationObserver support to the options param? Maybe:

{ observedAttributes: [], observedMutations: ['childList', 'attributes', 'characterData', 'subtree'] }`

• Support "selection follows focus":
  • Only relevant for "composite widgets", can probably be defined as a mixin/subclass similar to focusGroup
  • Tabs, single-select listbox, radio group, and tree list|grid utilize "selection follows focus". So a tab should listen for the focus event and select itself (e.g. display the associated tab)
  • multi-select listbox, menubar, toolbar do not utilize "selection follows focus"
• Support commandfor and command attributes:
  • Even though the actual functionality is not baseline supported yet, doesn't mean we can mimic it (or does it?)
  • syntax: <aria-menuitem commandfor="text-selection" command="--bold-text">.
    • Custom commands must use double dash prefix
    • When the element is "selected" (e.g. click / Enter / Space), dispatch the --bold-text event on #text-selection
    • We can check if (typeof CommandEvent === "function" ) and callback to regular Events
    • This might also be a mixin/subclass

Some other potential base behaviors mentioned by deniz in a previous iteration of this concept. Including them here for the sake of completeness, but we should determine where they fit in the larger picture and if they're still beneficial.

• Light dismiss: Can be composed with other components to “close” the component when the user clicks outside the element. What it means to “close” is defined by the child component.
• Hotkeys: Composable behavior that adds keyboard shortcuts to an element. For an example, see the menus in table rows of https://franken-ui.dev/examples/task — each row has a hotkey to activate an option in the menu. (note: link is dead for me)
• Reorderable: A composable behavior that makes a component’s children reorderable by clicking and dragging. Needs research to figure out if this is possible to implement generically, or needs to be implemented within specific components.
• Hover preview: A card that appears when a card is hovered, showing a snippet of information from the linked page. Most existing implementations seem to be exclusive to visual usage – is it impossible to make this accessible?
• Overflow: A row of items, such that any element that doesn’t fit in the row and would cause it to wrap or overflow will be moved into a separate container (the pane). The pane would usually be the body of a disclosure. TBD: Is it OK to require items to be direct children of the overflow? Otherwise, how should wrappers behave when their descendant items are moved into the pane? Should we duplicate wrappers in the pane? Should we remove them from the overflow when all their children are moved into the pane (and vice versa)?

Next steps

I think that covers all my initial thoughts on this matter. As for next steps:

• Once a naming convention is decided upon and the list of widgets is ordered and settled, I will put together demo pages for every widget so that the syntax can be finalized and we can have something to (manually) test against during development. We will need to decide if this should be a separate branch or just added to dev. Is it possible to hide certain demos from the public docs as releases go out, or should we just add "Under Construction" GIFs?

• We need to figure out a graceful way to deprecate the existing behaviors (or not?)

Looking forward to getting my hands dirty!