"there is no use case for extending built-in elements"
aside form elements, picture element, table element, list element, video element, others I'm probably missing
and no, element internals isn't the solution. it requires boatloads of client javascript to replicate built-in behaviour which is exactly the problem we're trying to avoid these days.
@brianleroux we recently built a table component that has configurable column sorting (based on content type), search, filtering and a whole host of other features.
I would prefer to never build something custom like this, just want the primitives to actually meet the requirements of the web
@benschwarz @brianleroux We were discussing this internally just the other day. There's really no reason we shouldn't be able to do this by extending built in table elements as far as I'm concerned. Arguably you can get a lot of the semantics to screen readers via ARIA, but even the ARIA guidelines suggest that using existing HTML elements is better than using ARIA 😅
@colepeters @brianleroux extending elements would probably be better, but also: sortable searchable tables are everywhere, they should be a built in imo
@benschwarz @brianleroux Absolutely — just as with `selectlist`. Surely if we built enough of them (esp. through extending builtins) it'd happen eventually.
@benschwarz @colepeters @brianleroux there's really little point everyone rolling own '<TH sortable=numeric>' progressive enhancement when it could just be part of the spec?
@falken @benschwarz @brianleroux It's how it tends to go. We were all rolling our own dialogs (painfully) until very recently. Authors move much faster than specs.
Although again, with the speed of recent CSS updates, that’s starting to be less of a hard rule; would be great to see the same with HTML.