Love when I go into a car dealership and get to read all about the different cars. Specially when the cars aren’t actually there. In fact there’s not even a picture of a single car. Yep that’s my jam.
Just to clarify why there aren’t any demos right now: I originally built the site mostly for myself, as a quick reminder for simple things whose syntax is easy to forget.
The use case was simple: I have my editor open, quickly check the site, copy those 2 or 3 lines, and get back to work, already knowing exactly what they do.
Sharing it publicly came later, so demos/screenshots weren’t really part of the original idea.
That said, I’m happy to take the criticism on board, even if I don’t always agree with the delivery :)
There are some good descriptions and hints, but what the site really needs is examples. Just looking at the code doesn't help me much. The descriptions are also mostly so short, that they could just as well be tooltips on the homepage.
The whole premise of the page is a collection of "web tricks worth remembering" and I can't fathom what bash (e.g. `du -hd 1 . | sort -hr`) is doing there.
fwiw I find `*` a lot easier in regular use than all of `-d 1 .`. It doesn't automatically expand to dotfiles but for regular typing, this advice looks like something you'd do if you're a robot or making an alias
Try ncdu, which kind of does this but better. You can quickly traverse a directory tree recursively sorted by size in a simple ncurses interface and even delete files with instant recalculation.
You’re absolutely right, thanks for the feedback. I initially included live examples (mostly through CodePen), but they were taking too much time to maintain, so I stopped.
The Bash entry was really just a half-finished personal note that I never properly edited. It’s probably out of scope too.
Codepen is an awful experience on mobile (and is slow, as you said). But your page is an html page about html tips. Surely you can just embed them in the page itself?
Maybe it's just me, but it seems like a huge waste of time (or to be on a more positive note - potential).
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."
So it doesn't tell me how to identify device type. It doesn't even run the code so I could quickly compare results between my mobile and desktop devices to establish a baseline.
You’re right: it doesn’t identify the device type, so the title is misleading.
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!
The conclusion is wrong. The point of using these media queries is that:
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.
Yeah, that was the first one my eyes went to. The only scenarios I can think of where it is acceptable to hide scrollbars are infinite canvases where you’ll draw your own non-linear ones (and even then be disappointed because they can’t look or behave natively), and things like maps where you remap scrolling to zoom and might want to use a backing invisible scroll area for that rather than consuming scroll events (which are somewhat more limited).
In short: unless the native scroll bar will be wrong, do not under any circumstances hide it.
Sure. I was thinking of fairly narrow cases, not ordinary page scrolling:
- 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
Only time I've seen that work is when making a carousel. Once you're using scroll snap it's already not going to behave the way you'd expect a scrollable container to, so having a different indicator doesn't feel so egregious to me.
They're not really 'tricks' as much of mentions of assorted features of HTML and CSS. You get to discover a similar assortment of things (with much more immediately available detail and many examples) just clicking around MDN.
That’s fair, "tricks" may be overselling it. The website is meant to be a small, opinionated collection of features I want to remember, not a replacement for an authoritative reference like MDN.
I can probably make that positioning clearer.
Neat! I like these opinionated lists, especially when it’s easy to browse and cherry-pick useful stuff. It’d be very good to mention how compatible the features are, though. Especially with newer CSS features, it’s easy to overestimate how ready they are for all browsers.
For that, there could just be links to the related MDN and/or caniuse.com pages.
Best resource for proper HTML+CSS development is Jason Knight AKA deathshadow's CUTCODEDOWN (cutcodedown.com at Web archive) and his articles at Medium and CodePen (user Jason Knight).
The principles are the same: deliver content in an accesible way separating content from presentation, and if needed use javascript to improve usability, not to hijack basic site functionality.
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:
I really hate hiding scrollbars, and I think the warning on that "feature" misses an important point: The scrollbar is not just for scrolling - it also tells you where you are in the document, and roughly how much of it you can see.
Tiny little slider toward the top - oh man, this is going to take a while.
Huge slider - great, quick read.
Slider toward the bottom - almost done!
I'm not sure where the design for this site came from, but I hate that it brings you to a new page to show you something that could have probably fit in the big ass buttons on the first page lol. It took my by surprise the the card didn't flip over to show you the details and instead just navigated to a new page. I'm not a design guy- more of a backend, do everything in a TUI kind of guy- so if I'm caught off guard by a cheap UI/UX decision, then that's a serious problem.
Agree to disagree. I don’t think preferring an in-place reveal makes navigation to a dedicated page a cheap UI/UX decision, it was a deliberate choice.
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.
Wait... there's no demonstrations of any of these "tricks" on the site? Am I looking at a broken version of the site? This could have been a markdown file lol hos is this so high up in HN?
Love when I go into a car dealership and get to read all about the different cars. Specially when the cars aren’t actually there. In fact there’s not even a picture of a single car. Yep that’s my jam.
If only there was a way to render this syntax in the browser.
I agree 100%. Pictures or any sort of visual representation of any kind would only diminish the quality of the whole experience.
The fact is, if you're smart enough you can just eyeball raw css and just see it if you close your eyes.
Oh you're not also gifted? Well I guess you're not special enough for this job then. Maybe you should be flipping burgers instead.
/s
Message received loud and clear.
Just to clarify why there aren’t any demos right now: I originally built the site mostly for myself, as a quick reminder for simple things whose syntax is easy to forget.
The use case was simple: I have my editor open, quickly check the site, copy those 2 or 3 lines, and get back to work, already knowing exactly what they do.
Sharing it publicly came later, so demos/screenshots weren’t really part of the original idea.
That said, I’m happy to take the criticism on board, even if I don’t always agree with the delivery :)
There are some good descriptions and hints, but what the site really needs is examples. Just looking at the code doesn't help me much. The descriptions are also mostly so short, that they could just as well be tooltips on the homepage. The whole premise of the page is a collection of "web tricks worth remembering" and I can't fathom what bash (e.g. `du -hd 1 . | sort -hr`) is doing there.
fwiw I find `*` a lot easier in regular use than all of `-d 1 .`. It doesn't automatically expand to dotfiles but for regular typing, this advice looks like something you'd do if you're a robot or making an alias
It tells you which directory is the largest, including dot directories. You can then cd to the largest and run the exact same command again.
You can find out what's filled your disk just by following it. It's something I regularly do.
I know, as demonstrated by the comment you're responding to giving a tip about how to type that more quickly but with a caveat
Try ncdu, which kind of does this but better. You can quickly traverse a directory tree recursively sorted by size in a simple ncurses interface and even delete files with instant recalculation.
You’re absolutely right, thanks for the feedback. I initially included live examples (mostly through CodePen), but they were taking too much time to maintain, so I stopped.
The Bash entry was really just a half-finished personal note that I never properly edited. It’s probably out of scope too.
Codepen is an awful experience on mobile (and is slow, as you said). But your page is an html page about html tips. Surely you can just embed them in the page itself?
Please keep it, personal notes are worth it. Maybe less navigation or +/- voting, then ranking would help us navigate your site?
Like in the good old commandlinefu.
Silly question, why not just render the html on the pages? e.g. the popover is something I wanted to see
Yeah, it makes perfect sense. It’s definitely on my "I really should do this, but…" list.
Maybe it's just me, but it seems like a huge waste of time (or to be on a more positive note - potential).
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."
So it doesn't tell me how to identify device type. It doesn't even run the code so I could quickly compare results between my mobile and desktop devices to establish a baseline.You’re right: it doesn’t identify the device type, so the title is misleading.
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!
The conclusion is wrong. The point of using these media queries is that:
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.
It has all the hallmarks of just telling an agent to scrape MDN and make a website
It wasn’t, but I’d be curious to know what specifically gave you that impression.
please don't hide scrollbars :)
Yeah, that was the first one my eyes went to. The only scenarios I can think of where it is acceptable to hide scrollbars are infinite canvases where you’ll draw your own non-linear ones (and even then be disappointed because they can’t look or behave natively), and things like maps where you remap scrolling to zoom and might want to use a backing invisible scroll area for that rather than consuming scroll events (which are somewhat more limited).
In short: unless the native scroll bar will be wrong, do not under any circumstances hide it.
If you mean the "Hide scrollbars" note, I agree 100% (:
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.
>There are a few specific situations where it can be useful
re scrollbars, Can you give an example?
An online game for example.
Sure. I was thinking of fairly narrow cases, not ordinary page scrolling:
- 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
Only time I've seen that work is when making a carousel. Once you're using scroll snap it's already not going to behave the way you'd expect a scrollable container to, so having a different indicator doesn't feel so egregious to me.
They're not really 'tricks' as much of mentions of assorted features of HTML and CSS. You get to discover a similar assortment of things (with much more immediately available detail and many examples) just clicking around MDN.
Sure, they're not "tricks", but it's also definitely not the same as what you get randomly browsing formal documentation.
What's the difference?
That’s fair, "tricks" may be overselling it. The website is meant to be a small, opinionated collection of features I want to remember, not a replacement for an authoritative reference like MDN. I can probably make that positioning clearer.
Nothing AI can not fix and add demos in less than a minute for less than a cent
Neat! I like these opinionated lists, especially when it’s easy to browse and cherry-pick useful stuff. It’d be very good to mention how compatible the features are, though. Especially with newer CSS features, it’s easy to overestimate how ready they are for all browsers.
For that, there could just be links to the related MDN and/or caniuse.com pages.
Yes. MDN and caniuse.com are great. See also https://webstatus.dev and https://web.dev/baseline
Best resource for proper HTML+CSS development is Jason Knight AKA deathshadow's CUTCODEDOWN (cutcodedown.com at Web archive) and his articles at Medium and CodePen (user Jason Knight).
How is an archived web site supposed to be a good resource on modern html and css development exactly?
The principles are the same: deliver content in an accesible way separating content from presentation, and if needed use javascript to improve usability, not to hijack basic site functionality.
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...
We plateaued about 10 years ago right?
> Each post-it pairs one useful platform feature with a small example
I can’t find a single example; each post-it just shows some code but not the result of it.
The code is the example. "Demo" is probably a better word for what you're thinking of.
"... that matters" is the new emdash
Not AI, just not a native speaker.
Super neat! Rare to see a genuinly actually useful opinionated list like this.
I'm always googling how to center with CSS.. bookmarked.
What does native mean in this context?
Features built directly into the browser, without requiring a framework or third-party library.
If the term is confusing, I’m open to better wording.
I really hate hiding scrollbars, and I think the warning on that "feature" misses an important point: The scrollbar is not just for scrolling - it also tells you where you are in the document, and roughly how much of it you can see.
Tiny little slider toward the top - oh man, this is going to take a while. Huge slider - great, quick read. Slider toward the bottom - almost done!
Please stop hiding scrollbars!
I'm not sure where the design for this site came from, but I hate that it brings you to a new page to show you something that could have probably fit in the big ass buttons on the first page lol. It took my by surprise the the card didn't flip over to show you the details and instead just navigated to a new page. I'm not a design guy- more of a backend, do everything in a TUI kind of guy- so if I'm caught off guard by a cheap UI/UX decision, then that's a serious problem.
Agree to disagree. I don’t think preferring an in-place reveal makes navigation to a dedicated page a cheap UI/UX decision, it was a deliberate choice.
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.
Does it add time, or break eye-focus?
Wait... there's no demonstrations of any of these "tricks" on the site? Am I looking at a broken version of the site? This could have been a markdown file lol hos is this so high up in HN?
without demos this is mostly useless i think
Nice tips there ! :)
Thank you for sharing, it's very helpful.
what would be cool is an llms.txt that i can feed to use these as most try to use React when they could just use html
Not to be confused with https://http.cat/
Did you know that to have a .cat domain, your content needs some link to the nation of Catalonia? That is why they offer a Catalonian translation.
I often end up there by accident and have a laugh every time.
And yet that site has horizontal scroll bars.