Piccalilli is Andy Bell's front-end development site with articles and courses on CSS, JavaScript, and accessible web design.
HN commenters link it for the CUBE CSS methodology, its CSS reset, its Eleventy course, and a series on framework-agnostic design systems.
Here's some of my tips for a handwritten HTML site, since the author wished more tips existed:
- consider using an HTML boilerplate template like this one if you don't know where to start: https://www.matuzo.at/blog/html-boilerplate/
- consider using a CSS template, or a CSS reset, if you don't know where to start with styling. Pico CSS is a good drop-in: https://picocss.com/. Frontend devs always blog about their CSS resets, like this one: https://piccalil.li/blog/a-more-modern-css-reset/. But if you're someone inclined to write their own HTML, then you'll probably also want to write your own CSS. This takes time to learn. Especially learning how to design the page without looking crappy
- I copy my last page as a template whenever writing a new page
- I don't worry about code duplication. If I need to refactor duplicated content, I use search and replace across files in vim (like https://nithinbekal.com/posts/vim-search-replace/). Hopefully your editor/IDE has something similar, and hopefully you're comfortable with regexes
- markdown + pandoc + scripting is a common solution. Technically it's not handwriting HTML at this point -- it's hacking together your own static site generator instead of using an existing framework -- but no biggie
- frontend people have made a lot of live reload tools over time. Here's a couple: https://nitoyon.github.io/livereloadx/ and https://github.com/tapio/live-server. Personally, I've cobbled together something with…
The off-by-x-pixels problem usually only happens when you take the unwise path somewhere.
Following standard practice in regards to layout will help you here:
1. Use `box-sizing` everywhere (should be defined in your css reset file, example: https://piccalil.li/blog/a-more-modern-css-reset/)
2. If you can do something in css or js, do it in css.
3. Don't use pixel values anywhere (this avoid a lot of off-by-x errors when either the math is wrong or a previous assumption is violated by new code somewhere else). Two exceptions: a) The base font size on the root (usually the <html>) element. b) A 1px border, since the box-sizing in step 1 will allow you to take it from the element's block and inline size.
---------------------------------
Also, if you're trying to position text, or an icon inside a button and it seems off, you don't want to be trying to fine-tune the positioning with pixels.
It's always better to address the root cause.
Usually this is `line-height`, `vertical-align` and also the font itself. You can see lots of examples of the font being the issue here: https://tonsky.me/blog/centering/
If you run into this issue, you can look at the font's internal metrics (shown in the link above) to get the exact values you need (Browsers will be able to do this in 2-3 years automatically with `text-box-trim`). Or you could simply switch to a better font that already has the correct values.
Because you honestly don't need to, and shouldn't need to.
CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years.
What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952
Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/
this is pretty awesome! would love to see a few different "sections" like Business, Culture, etc.
Also mixing and matching typography, especially for article headings, would go a long way. See e.g. https://www.nytimes.com/interactive/2016/11/08/us/elections/front-page-election-archive.html
Or for a direct link to (a small) 1984 image: https://static01.nyt.com/newsgraphics/2016/11/01/front-pages/43d39ce787b695fe705257b340b8e25ea2696098/08ELECT-1984-original.jpg
Also maybe making the layout wider and more compact. And maybe, just maybe, picking 1-2 articles to have pictures.
You should probably also use a masonry layout like https://piccalil.li/blog/a-simple-masonry-like-composable-layout/
Using a div instead of a button is just dumb.
However, I was tweaking my app today, after having read this article, and realized I'm using some anchor-links as buttons just because I wanted them to be styled exactly like a link.
Then I tried adding role="button" and of course I couldn't tab over to my link-button. So I added tabindex="0", just like the article tells you not to do, and that allowed me to tab over to it but I still couldn't activate it with spacebar.
So I finally caved and Googled "how do I make a button look just like a link" which brought me to this article: https://piccalil.li/blog/link-button/
And now it behaves properly. Yay a11y.
I also like Unpoly very much.
I'm using it for a new frontend right now. Combined with a thoughtful CSS design like CUBE[1] that utilizes components but also leverages utilities to reduce CSS bloat I am writing mostly Ruby and HTML and very little JS and CSS and it feels great.
It's kind of back to the basics which means that I also do not worry about being on some framework's upgrade & dependency train or the mental health of future application developers/maintainers.
[1]: https://piccalil.li/blog/i-used-tailwind-for-the-u-in-cube-css-and-i-liked-it/