58 Bytes of CSS to look great nearly everywhere
jrl.ninja
jrl.ninja
I recommend "Web Design in 4 Minutes" from the CSS guru behind Bulma:
It also doesn't help that so many websites, even personal sites/portfolios these days, have so much markup goop and cruft that makes it quite hard to learn by example :(
Black text on a white background can be harsh on the eyes.
The accent color can be complemented with more subtle shades, to be used on
borders, backgrounds, or even the body text.
Since text is the main content of a webpage, using a custom font gives the
page even more noticeable identity.
Let's enhance our header with a nice background image from Unsplash.
Again, this is a rant. I am just very tired of “designers” doing “pretty” stuff instead of solving a problem. And that problem is an aesthetically pleasing, not-eye-hurting, reasonably dense text.
Keep in mind that paper is not an emissive surface, like an LCD panel is. Black-on-white is fine for e.g. e-ink displays or calibrated brightness (~15-30% on most displays, which is not the default).
Content :: Fonts and Colors :: Advanced :: Allow pages to choose their own fonts
This dingbat crap also hinders accessibility, as you can’t specify alt text like you could for images.
Firefox used to have an optional exception for icon fonts on the "allow custom fonts" switch which I found very sufficient. Not sure when it was removed or why, but that was a big loss.
I don't think "dark theme" is always the right answer, but I think with a new medium, a new basic is worth considering.
However, I've also started to spend more and more time on my eink Android tablet. Video is of course unwatchable, some apps refuse to launch, and scrolling is unpleasant at best. Still, I think the tradeoffs are worth it, especially late at night.
Reflective media like paper behave a little differently than emissive media like an LCD. A normal sheet of paper under normal lighting conditions won't reach the same brightness as an LCD. An LCD is much bigger than any reasonable book and it emits light uniformly across it's entire area (close to impossible for any piece of paper unless it's affixed on a flat plate). Also most paper is not actually very white.
The goal of design isn't to correct the user, but to correct for the user.
But you can't solve brightness problem with just design of a web page: you can't know for sure that all of your users are in the dark, or that their monitors emit some well known amount of light. Unless, of course, you do natural selection thing by making another category of users suffer and, eventually, leave your page because of your design.
And why is it web designer's job to adapt to myriad of real world devices and conditions? Shouldn't DPIs and automatic brightness correction things in hand-held devices and other OS-side tricks handle this problem already?
Then again, what modern designers are correcting for with, say, slick hair-thin fonts? It only adds extra work: now I need to disable these fonts somehow to make page readable. That's almost like calibrating brightness with a piece of paper in the post above.
While I've definitely seen web pages that have gone bonkers with light grey text on an off-white background, a lot of folks seem to greatly overestimate how difficult to read "grey text" is. I've seen folks on HN rail against #444 text -- which even on an #EEE background is over an 8:1 contrast ratio.
That's their eyes against your words, and I'd be far more likely to trust the judgement of their eyes because they are the ones consuming your content.
A lot of designers seem to love ignoring the complaints of their users, forgetting that those users are their audience and pissing them off will quickly make them leave.
I did not take this to mean a non-inverted color scheme is hard. I understood this as pure black on pure white is harsh.
Notice he uses #566b78 as the body color instead of #000000.
While it is an additional HTTP request, it's not necessarily another host. You can perfectly host fonts in your own site
I use gulp-google-webfonts to download fonts to my resource folder and use them from there. Even then I'm careful not to use more than 1 or 2.
I just don't get the HN hatred for downloadable fonts in and of themselves. If you're talking about an extra megabyte or two of JavaScript and unoptimized fonts, okay, but that's a problem of implementation. Why this cranky "it's just the text that matters, stop trying to make it look pretty" mindset?
Many people select fonts where there isn't ambiguity between similar characters like o/O/0 and I/l/1. Reading the home page for the font [ https://concoursefont.com/ ] gives me a headache personally. The lowercase 't' and 'f' fight one another. The 'f' with its flowing curve and the 't' in its rigid straightness makes the text fail to flow well.
My favorite font is guilty of having ambiguous characters as well - and while I'm not personally very bothered by it - I can understand and empathize with the annoyance other people have towards issues like this.
I use Stylus to inject my own stylesheets and force every website to use my chosen fonts - their design be damned. But I also eventually write my own CSS for the site myself if I use it frequently so my opinion is likely invalid as 99.9999999% of users would never do that.
As an aside: I don't use Concourse as a body font; it's not something that strikes me as particularly suitable for long stretches of text. But I think it's fine in headlines. It also has multiple letter variations you can use, and my web site uses the "British" stylistic set, which has a different "f" and "t" (and "l" and a few other characters) from the default used on most of its site.
Unlike you I do have a lot of experience in graphical stuff, specifically finer art. And I do understand more then the average person on color theory.
The thing to keep in mind with all of this is that black isn't black. White isn't white. White and black have tints. You can have cool whites, and cool blacks. You can have warm whites and warm blacks. What you will never have is white whites and black blacks.
Lowering color contrast is a trick that is used in art to make things seem far away or behind the more colorful pieces of art. Part of that is because reduced contrast makes details harder to see, which corresponds in people's minds to distance because distance makes details harder to see. (other factors are going to be things like that atmosphere has it's own colors and these begin to compete and wash out colors at a distance).
High contrast makes it easier to read text. But it needs to be the right type of high contrast.
If you try to pick the blackest black you can and the brightest white then that means you are letting the viewer's monitor dictate what the tinting will be. And mixing colors incorrectly results in a shimmering or 'vibrating' effect in the eyes. So depending on the user's settings it may be easy to read or it could be irritating. Which as a designer isn't going to be something you want.
I have a idea that the author of the "Web Design in 4 Minutes" is extremely good at writing CSS and not so hot at web design. Which are two different things.
I struggled with this problem a lot when I redesigned my website recently. I wanted a pure black background mainly for Amoleds (and because I love it) but couldn’t settle on a text color other than white. The problem I had was due to all those color shifting night modes like f.lux or iOS’s Night Shift. Once I used that on top of a tinted white, the text looked way to colorful which I thought to be distracting.
Once I figured out a good way to let my users change from Night Mode (dark bg) to Day Mode (white bg) without any scripts I plan to implement that as an option.
Rewording, I am tired of "pretty" being an add-on or, worse, the entire product.
Isn’t this due to cost?
I will reiterate my past comment that it is inevitable for many non-English scripts.
AFAIK there is a similar problem for Japanese: MS Mincho/Gothic, MS PMincho/PGothic (this one is too popular that there are several metric-compatible free fonts), MS UI Gothic, Meiryo, Yu Gothic, Hiragino font family and of course Noto Sans CJK.
> But if you don't have a decent font on your machine, how the text is rendered?
Awfully. Imagine that everything is rendered in System or Fixedsys.
I have to disagree with your disagreement. Paper and screens are completely different. Paper is passive whilst screen emit light.
So it's much better to have screens have a dark background and emit the text, so our eyes aren't as strained receiving so much light. It's far easier to see a headlight in the dark for example then during the day.
Whilst for paper, the only reason it's black on white was that we had dark ink which went on light materials. It's a lot harder to find light ink that goes on dark material.
I understand where you're coming from, but I do think it serves an important purpose here.
The language is chosen to underscore the message and ensure virality. The goal was to get the point in front of as many people as possible, and it did that quite well IMO.
I'm not sure that message could have spread as far and wide as it did without that language. Perhaps if FAANG pushed it...
You're right to mention it because in the 2nd step "Centering", I use the same technique: adding a max-width and using auto margins for the left and right sides.
On a side note, this reminds of the "Doing it more vs. doing it better" thread that was here on HN yesterday [1], and how the JS code of "Web Design in 4 minutes" is quite bad… I just wrote those 50 lines directly in the HTML, at the end of the page, and tested it manually a few times. As a result, it is tightly coupled to the markup, and still has lots of bugs. But I imagine that if I had focused on writing "beautiful" code instead, I probably wouldn't have shipped the project in the first place.
Last year I started to build a web app without knowing how to code -- I started not knowing the difference between CSS and JS. You can imagine how confusing the current ecosystem is to beginners. (My co-founder and I taught ourselves to be the technical co-founders). Your tutorial really helped, and I'm using Bulma :).
There's irony in the fact that this website is completely non-functional and no content is displayed when JS is disabled. You'd think a CSS guru would not rely on JS to display text.
The reason people love this website is because the content changes as you learn each concept. The way you "change" content in web development without reloading is through javascript. It is about as close to a perfect use case as you can find.
There is nothing ironic about that.
* I clicked your link * closed the HN tab * was completely blown away by the article * "Reopen closed tab" and up-voted your comment
Your hyperlinks need to work without Javascript.
All the other styles applied on this pages are not part of the snippet. The weight of the titles, the spacing under the paragraphs, etc., are all specified on the page's CSS file but not described in the blogpost itself. [0]
I was expecting something akin to normalize.css[1] which normalize the default styles of your page[2].
There are multiple very lightweight CSS "frameworks" that you should carry around instead of the snippet shown here. We are talking ~5KB. See https://github.com/troxler/awesome-css-frameworks#very-light for a great list.
[0] https://jrl.ninja/etc/post.css
[1] http://nicolasgallagher.com/about-normalize-css/
[2] Normalize CSS aims to make built-in browser styling consistent across browsers. Elements like H1-6 will appear bold, larger et cetera in a consistent way across browsers. You're then supposed to add only the difference in decoration your design needs.
You can shave off 2 more bytes by using em instead of rem. In your use case they are functionally the same. Rem is em relative to the root element. Your <main> pretty much is the root element.
But I think the original is still well into the land of diminishing returns.
I brought up rem vs em because the difference is subtle and if you're byte shaving it's "free" bytes.
As examples, I size page elements in rem, but text elements (usally), in em.
My main, content, article, header, footer, and aside should all generally reference page, and are in rem.
Main body text width, headings (h1 ... h6), super- and sub-scripts, code and pre blocks (often jarringly sized by default) reference the containing unit and should be in em units. Also, generally, figure and table captions, table text, etc.
I prefer to give figure or sub-element (tables, callouts, note boxes, etc.) margins and paddings in em as well.
Granted that is still not much but here I've augmented the 546 byte example to render nearly the same results with only 155 bytes. [2]
I've removed rem units as it's easier for all to understand without them. Pixel units scale just fine across the browsers available these days so there's no need for the mental hurdles and explained calculations. I've left them in the source HTML all the same for the sake of testing. The real feature making sites look good across a ever widening array of pixel densities today is this meta tag that was also used in the example HTML: <meta name="viewport" content="width=device-width"> [3]
Setting a font-family generically on the body tag gives the shortest path to consistent, doesn't-look-like-times-new-roman, font styling possible.
I left the unmentioned line-height in because it's a good default. It adds a little basic spacing between wrapping lines of text.
Styling elements that are children of the article to only have bottom margins gives consistent spacing to all content, and since top margins collapse [4] we can avoid dealing with them all together.
[1]: https://jrl.ninja/etc/post.css
[2]: https://jsfiddle.net/gb0ojdsL/8/
[3]: https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/View...
[4]: https://css-tricks.com/what-you-should-know-about-collapsing...
Anyways, what you've written here is good, and definitely encompasses some things I thought about. Two notes for you:
1. I explicitly preferred Arial and Helvetica over the generic sans-serif is because I found some other popular web safe fonts didn't look nearly as good, for example, Open Sans, mainly due to the large x-height.
2. I don't think rem incurs much cognitive overhead over px, and the main reason is that it scales with the user-adjustable font size. Try changing your browser's font size from 16 to say, 20. You'll notice that with px max-width, # chars per line will decrease a lot, affecting readability. in contrast, rem max-width will scale nicely.
https://www.motherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/
https://evenbettermotherfucking.website/
https://bestmotherfucking.website/
https://thebestmotherfucking.website/
https://perfectmotherfuckingwebsite.com/
https://codepen.io/dredmorbius/pen/KpMqqB
The OP's 58 bytes are a very good start.
Why not target <body> instead? <main> should not have content that is shown on other pages, like headers, footers, and sidebars, but it makes sense to have this CSS affect those areas.
I agree, and making those changes would mean I can switch from main to body in my css. The main complaint I have is then article and main seems redundant. What are your suggestions? Semantic HTML5 is hard :(
If you aren't adding top nav sections or site-wide footers, your current approach is fine.
If you do want to experiment with those, you'll find the (correctly-constrained!) body content looks funny with copyright footers floating in space somewhere to the left or right of the main text.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar...
[1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin...
html {
display: flex;
align-items: center;
justify-content: center;
min-height: 100%;
}
@media screen {
body {
max-width: 40rem;
margin: 1rem;
}
}
I know IE5.5 doesn't allow resizing of the body, but it was fixed in IE6.
If you're using flexbox it's probably not your chief concern anyway.
I don't understand why I'm being forced to scroll when there's all this blank space to the sides.
Even on my laptop, this looks strange to me, a huge wide expanse of nothing, and this little strip of text down the middle of the page.
What's the reasoning behind this?
Lack of multi-column text support on the Web. Optimal readability is around 64 characters per line - more than that hurts quite a bit, especially for long-form text where accurate scanning is more important.
Even IE10, mobile safari, and the gingerbread android browser support it
Arguably, though, a website that’s surrendered to the strip should make some compromise between line length readability and reducing scrolling.
It feels very easy to read. So much clutter has been taken away.
There’s nothing pulling at the edges of your attention and ruining the experience. I quite like it.
Because I write with an overly-large number of asides, I fell in love with the Tufte-styled side/margin notes. The resulting text is much easier to read, since I'm not littering the paragraphs with em-dashes and lengthy parentheticals.
I hope more people rebel against the Medium-looking websites with massive images and huge blocknotes in 30px fonts that may or may not just be a line from the next paragraph or an important point to keep in mind when reading the next paragraph.
#longformrebellion #endthelisticle
Edit: Ah, it's an extension to Python-Markdown that is not enabled by default: https://python-markdown.github.io/extensions/smarty/
[0] https://github.com/Eiriksmal/lawler-dot-io/commit/593d3471e6...
Sorry, if you are into minimalist design I keep getting back there, with 58 bytes less of CSS: https://motherfuckingwebsite.com/
>Yes, this is fucking satire, you fuck
> I'm not actually saying your shitty site should look like this.
Putting Arial before Helvetica :(
[1] https://github.com/dylanaraps/pywal <- just discovered this yesterday during a weekend effort to improve the color combination used by my window manager, ...
Side note - you'd probably like this: https://jrl.ninja/configs
[0] https://refactoringui.com/previews/building-your-color-palet...
#eee = #eeeeee #abc = #aabbcc
It's not very precise, but can be convenient short hand.
::selection { background-color: #ff0; }
Because when f.lux raises the color temperature for the evening it makes it so I can barely see if anything is selected while the normal color works perfectly no matter the temperature I set. At first, I thought it was one of those JS scripts that prevent selection.
Not to mention that you actually have to do the effort to make it incompatible :)
And at least it uses its own recommendations, whereas the OP isn't (it ships way more CSS than the mere 58bytes it talks about)
It's the latter. Being both simple and good is not easy.
I have about twice the amount of CSS, but most of it was to match my personal setup of colors/fonts: https://nadyanay.me/assets/css/style.css
361 characters (yours) vs 615 characters (mine)
Remove the font family and .fav classes and some of the unnecessary border overrides and mine comes out to a more equivalent 319 characters, while still retaining the spacing and color scheme.
1024x768: https://i.imgur.com/NEAenbY.png
320x568: https://i.imgur.com/TdVjnKR.png
3480x1600: https://i.imgur.com/MfhxmRD.png
@media print {
…
}Readability isn't the concern. Show me a book with margins that gigantic.
I think I can't edit the styles in Chrome on Android though. (no dev tools)
This https://imgur.com/a/I3CHas1 is for comparison a screenshot of the mobile HN padding.
As for serif fonts, I would recommend doing what the other comment suggests. To expand on that, if you find that a particular safe web font [1] looks better for your site, you can explicitly prioritize it. For example, I did Arial -> Helvetica -> sans-serif.
Does its use depend on any particular markup in the HTML?
And how far back does it go as a CSS feature?
Modern browsers that support the element will present it as a "main" landmark to assistive technologies. Landmarks (header/banner, footer, main, navigation, etc.) are a useful way for people who use assistive technologies (mostly screen readers for the visually impaired) to get a sense of a page's layout and to move around within a page's contents.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
I personally prefer a bit more so that It looks good on my old crappy phone with far fewer than 600px wide. water.css is great.
What does px mean in CSS? I thought it was pixels but clearly not...
How can you use this vague definition to do anything useful?
I would imagine they simply mean 'it's a pixel, or something as physically large as pixels used to be until we got retina screens' but they can't say that as it doesn't sound technical enough!
I wonder why it doesn't mention the definition of the reference pixel for high resolution devices. Which is the angle you get when you hold a 96dpi image exactly 28 inches from your eye. If your screen is 1.5x further you make the pixel 1.5x bigger, if your screen is 3x closer you make the pixel 3x smaller, etc.
> the default font size for most browsers is 16px
I mean fonts are usually not 16 pixels in size - 16 pixels is a couple of a mm on most screens these days.
body { font-size: medium; }
main, article, content { font-size: 1rem;}
p, li, dd, dt, blockquote { font-size: 1em; }
I'd recommend Water.css for a more through out-of-the box experience that looks great anywhere.
I really like your site. A minimalist website is surprisingly hard to achieve.
And it doesn't look great everywhere. At 375px-wide the line-length of the text is ~35 characters, optimal would be 50--70.
w.r.t line-length, there's another suggestion ITT that said to relax the padding a bit to get a bit more line-length, which I will probably be doing.
iPhone 6/7/8 users still drives a non-negligible amount of conversion on our site. We don't target devices, 375px is a general target for the smallest screen size we'd be likely to encounter.
The site as-is @375px: https://imgur.com/a/zUsywrQ longest line has 43 characters
The site w/o padding @375px: https://imgur.com/a/IR8nFM4 longest line has 53 characters
I thoroughly agree with his statement and just wanted to post this to help emphasize the fact.
> supporting 600px displays at a minimum seems reasonable.
Max-width is just that: maximum width. That CSS is not "supporting 600px displays at a minimum".
https://motherfuckingwebsite.com/
.. and it's followup:
http://bettermotherfuckingwebsite.com/
(Both are SFW sites except for the use of expletives in the URL/title).