Native ability to text search tables

[benschwarz]

Following on the back of #799 and #800, I'd like to also propose the addition of table text searching.

Data tables on the web are time and again implemented with sorting, searching and column hiding. There's a huge amount of effort required to implement a performant and accessible table with all these features.

In my mind, the key success criteria for such a feature would include:

• Ability to specify which columns are searchable
• Searches must be performant with large datasets of at least 10K rows

In addition, user input throttling could also be considered, in order to reduce fast visual page shifts as users type.

[LeaVerou]

Since the first post doesn't discuss syntax, here’s a stab at a strawman, with a lot of open questions.

As an overall requirement, I think the search UI should be provided by the user, since auto-generated search UI is unlikely to work for a good chunk of use cases. We should just provide syntax that connects form elements to tables declaratively and sets all necessary parameters.

Idea 1: Table-wide search

One model could be to associate a form control with the whole table, and have that same form control search across multiple columns (all at first, then gradually introduce syntax to customize the matching).

One way to do that could be:

• MVP: a boolean search attribute on <table> that accepts an IDREF pointing to a form control. By default, the search is done on input, potentially throttled by a UA-defined delay (which could depend on number of rows) and searches all columns.
• v1: searchtype (name TBB) attribute on columns ¹ with values auto (same as no value) and none (not searchable)
• v2: searchtype could get more values like start, end, whole, min-numeric, max-numeric etc. We could also have searchhint with a space-separated list of hints, e.g. unique.

Note that due to the inherent reactivity of HTML, authors can implement more complex search UIs by simply changing the searchtype attribute via JS.

Variations:

• A searchtype attribute on the <table> that sets a default for all columns, and a colsearchtype on columns that overrides it.
• The IDL attribute could also accept functions to fully customize how search matching works

Other names: searchmatching, searchable, searchbehavior

Idea 2: Table AND Column search?

While table-wide search is useful, if we could also associate form controls with columns, then we can tackle a lot of the filtering use cases in one fell swoop (see #903). However, we don't want the latter to get in the way of the former: if all we need is a table wide search, that should be easy to specify (in the spirit of Common things should be easy, complex things should be possible).

Note that it's very common to want both a table-wide search field and column-specific filtering, so the feature should not be either or. Example from Coda:

Challenges:

• The challenge in adapting the proposal above to this is that it consists of two components: a search attribute that goes on the <table> and a searchtype attribute that goes on the column. The former could be specified to go either on the table or the column (or both), but how do you specify different metadata for each?
• How to specify the intersection of different types of search? Presumably AND would be a good default. Should OR be possible? Or combinations of both? Probably not MVP, but the syntax should allow future expansion in that direction.
• Filtering requires numeric ranges as well, not just text search.

Footnotes

1. How to specify metadata on columns is an open problem, see https://github.com/openui/open-ui/issues/903#issuecomment-1781248096 ↩

[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.