My further comment will be buried, but its a rip on Chuck Norris facts, and was pretty ... whatever ... "geek culture". That was only proved by Chuck Norris' endorsement of Mike Huckabee back in 2007:
https://www.youtube.com/watch?v=--EGyU57efY
and it never will, because IPv4 has become a defacto reputation system for the exact same reason that IPv6 was created: a limited supply. It wouldn't surprise me to see the continued balkanization of the internet that there is a particular underclass of exclusively IPv6 traffic, but its not going to take over everything because once decentralized systems are now in the hands of a few decisionmakers in the case of, say, email.
If we've concluded that's it's okay to have elements that change/morph, as we seem to with the introduction of things like details, a native tab-like element feels like a glaring omission. Tabs have been a long-standing UI pattern and forcing every site to implement their own is a nightmare for accessibility. (The page you're reading is maybe already in a browser tab.)
I wouldn't be surprised if it turned out less than half of the custom tab interfaces on the web failed from an accessibility standpoint. When considering ARIA guidance, I don't even think it's possible to build an accessible version in HTML alone.
Other people have recognized it's missing. Open UI has a draft spec for it[0] and CSS Tricks has an article from 2001 about Open UI's experiments with sections for tabs[1]. I have no idea what happened on this front, though.
Accordion behavior is discussed in the article in the "Accordions / Expanding Content Panels" section:
> Use the same name attribute on all related details (like radio buttons) to restrict only one open panel at a time
And tabs can be a <details>-based accordion with some creative CSS to adjust the layout (left as an exercise for the reader, but I could write up an example if that would be helpful!)
Yes, the tabs in a tabs pattern should be keyboard navigated using arrow keys (ironically not the Tab key).
Also, the summary for the currently open details element will have the wrong state, 'expanded' instead of 'selected'. And while a set of details can now have a maximum of one open at a time, you can't ensure exactly one is always open (without JavaScript) as the tabs pattern requires.
And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
I left a different comment, but I think this is good. You're example is 3306 and has a useful breakdown. Not everyone has that port memorized by trauma, and not every mysql instance uses that port.
New tools are always welcome, and having a purpose to explain a purpose seems like a good pitch.
Totally. Just to clarify, witr isn’t limited to ports. You can run it directly on a process too, like `witr mysql`. I used the 3306 example to emphasize this use case.
This is great. One of those things that just formats and does all the little niggling things you have to do sometimes. I like that it is simple, and doesn't (thank god) need npm or some other package manager.
to quote the top comment: just show a screenshot of its results, if its useful its fine, being fast is just gravy.
