The Bash entry was really just a half-finished personal note that I never properly edited. It’s probably out of scope too.
Like in the good old commandlinefu.
Just the first example "Device type in JS".
"A coarse pointer does not mean “mobile”, and a fine pointer does not guarantee “desktop”. Ask the browser about input capabilities instead of guessing the device from its user agent."
const input = {
finePointer: matchMedia('(any-pointer: fine)').matches,
coarsePointer: matchMedia('(any-pointer: coarse)').matches,
canHover: matchMedia('(any-hover: hover)').matches,
};
The intended point is that device type is often the wrong thing to detect: a touchscreen laptop may expose both coarse and fine pointers, while a tablet may be connected to a mouse or trackpad. The snippet detects available input capabilities instead, which is usually what the interface should respond to.
I wasn’t particularly careful with the titles, but this one should be "Detect input capabilities". Thanks for the heads-up!
1) You can only use tiny buttons with precise pointers.
2) You can only use hover popups with pointers that can actually hover.
In practice, much of this is too much work and everyone just designs for touchscreens instead. It's rare to find a website that even bothers with using title="" for tooltips because smartphones are a disaster of UI and lack tooltips.
In short: unless the native scroll bar will be wrong, do not under any circumstances hide it.
There are a few specific situations where it can be useful, but I added the caveat precisely because it’s generally not a good practice.
re scrollbars, Can you give an example?
- A swipe/drag carousel with visible arrows or dots, especially a looping carousel where the native scrollbar does not represent a meaningful start and end
- An accordion or expanding panel that animates to reveal all of its content. During the transition, its intermediate height may briefly produce a scrollbar (and a visual flash), even though the fully expanded state does not need one
- Highly visual or experimental interfaces where scrolling is communicated through another control, or where the scrollable area is decorative and scrolling is not required to access the content
For that, there could just be links to the related MDN and/or caniuse.com pages.
Unfortunately he died in 2024, that's why the website is down. His last articles are available at Medium: https://deathshadow.medium.com/
These ones are a good starting point to develop accesible websites:
https://web.archive.org/web/20221117231315/https://cutcodedo... https://web.archive.org/web/20221117231314/https://cutcodedo...
I can’t find a single example; each post-it just shows some code but not the result of it.
If the term is confusing, I’m open to better wording.
Each note has a stable URL that can be shared or bookmarked and can be indexed independently. A dedicated page also leaves room for longer content or links to related notes.
Flip interactions also behave differently on touch devices and require more care around keyboard accessibility. It’s a valid alternative, but I don’t see navigation to a standalone document as something inherently undesirable on the web.