Docs - add sections and search filtering for community extensions

[scrhartley]

Description

Try to make the community extensions docs table more approachable.

• Add sections so that we can start to break up the big table.
• Add search filtering to help finding appropriate extensions.

Current sections added: Data API, Integrations and Legacy.
Idea for additional section: We could put the Alpine and morphdom morphing extensions in a Morph section, but as there's just the two of them, I was on the fence about this, especially considering that currently the sections are at the end of the table.

WARNING - this doesn't include PR #3259 and will need updating due to the change from markdown to html an table.
Converted to a draft PR until that's been resolved.

Implementation details

• Change table to use html to allow sections and section headers.
• Add Zola shortcode to allow markdown in html
• Upgrade hyperscript (to 0.9.14) so that the search functionality works

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for
  source changes)
• This is either a bugfix, a documentation update, or a new feature that has been explicitly
  approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded

[geoffrey-eisenbarth]

I think this is an awesome addition. I think best practices would be to include a <search> landmark, have a <label>, and use [type=search] though:

<search>
  <label for="extension-filter">Search Extensions:</label>
  <input type="search" id="extension-filter" placeholder="Search Extensions...">
</search>

[scrhartley]

I think this is an awesome addition. I think best practices would be to include a <search> landmark, have a <label>, and use [type=search] though:

<search>
  <label for="extension-filter">Search Extensions:</label>
  <input type="search" id="extension-filter" placeholder="Search Extensions...">
</search>

For the main site search input the label text is hidden.
Should I do something similar? Otherwise the placeholder text seems redundant.

<label for="extension-filter" hidden>Search Extensions:</label>

[geoffrey-eisenbarth]

Yeah, that sounds reasonable. I do know that labels are recommended by ARIA APG even if they are hidden. Typically a placeholder should not serve as a label and the contents of a placeholder are more for providing an example of what to fill in, but 🤷‍♂️

Also thanks for reminding me about the parent context: if the site search uses a <search> landmark (which it should), then they both need [aria-label] attributes. (I can't look at the full context right now bc babies, bedtimes, and mobile devices).

[Telroshan]

That's a very cool enhancement!
(#3259 has been merged btw)

[scrhartley]

Updated ARIA based upon: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/search_role
Marking as "Ready for review".

[scrhartley]

Note:
This PR has the sections at the end and everything thing else is at the start without a section header.
It would be straight forward to add a General/Uncategorized/Misc header for the other extensions if we want to make a different choice about the order of things.

[1cg]

Thank you!