Disclaimer: I am not a graphic designer. I am merely a programmer with an
interest in well-crafted, understandable, and readable text. So, read this as
an outsider rant rather than an informed opinion.
Black text on a white background can be harsh on the eyes.
I have to disagree about the problem here. Black text has been fine since the first printing
press. And if you do want to make a page less in-your-face with regards to
contrast, then it would be much better to dim the background.
After all, the paper we read is mostly this grey-ish, yellow-ish colour.
The accent color can be complemented with more subtle shades, to be used on
borders, backgrounds, or even the body text.
The colours they've used in the syntax highlighting just made everything a
confetti explosion. I am not against syntax highlighting, but it shouldn't be
this colourful, unless you give every identifier a computable colour to make
misprints more noticeable.
Since text is the main content of a webpage, using a custom font gives the
page even more noticeable identity.
Not a big fan of @font-face. Another host to visit. Another asset to download.
My fonts are fine. If I have the font you like, then great! If I don't, please
make it look reasonable with system defaults.
Let's enhance our header with a nice background image from Unsplash.
Let's not. Massive headers are nothing but a waste of space.
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.
You may be wrong or may be right, but all I can say that after looking at the demo the text became significantly more difficult to read after the CSS coloring was applied to it.
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 don't want to sideline a thread on a single point, but I do think there is a difference between the unlit black ink on white paper of years passed, and the modern backlit monitor shining like a bright a flash light in your eyes.
I don't think "dark theme" is always the right answer, but I think with a new medium, a new basic is worth considering.
I'm with you on fonts. So much so that my first Firefox customization on any computer is locking down the font. Every webpage gets the same font, because I like that font and find it readable and I don't see why I should have to look at anything else.
Content :: Fonts and Colors :: Advanced :: Allow pages to choose their own fonts
> Black text has been fine since the first printing press
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).
> Not a big fan of @font-face. Another host to visit. Another asset to download. My fonts are fine. If I have the font you like, then great! If I don't, please make it look reasonable with system defaults.
I will reiterate my past comment that it is inevitable for many non-English scripts.
You don't need to visit another host just because you're using @font-face! The fonts can be stored locally. If you visit my home page, coyotetracks.org, it loads five fonts (bold and italic Concourse, and regular, bold, and italic Equity) for an extra 82.18K -- which, unless you're taking steps to prevent it, your browser is going to cache from that point on. (If you visit another page, you'll probably get the regular version of Concourse, too, for an extra 11.45K.)
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?
> I have to disagree about the problem here. Black text has been fine since the first printing press. And if you do want to make a page less in-your-face with regards to contrast, then it would be much better to dim the background. After all, the paper we read is mostly this grey-ish, yellow-ish colour.
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.
Haha, thanks for sharing this. It's been a while since I wrote that!
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.
Bloody hell, I've been trying to find for this for ages. I knew there was _something_ I'd read that gave a great step by step overview that I knew at the time would be helpful whilst teach beginners, but I couldn't remember what it was called or who wrote it, and it's nearly impossible to search for when the details of it were sketchy ("step by step web design tutorial"??). Just want to say thank you for writing this (and thank you to OP for posting the link)
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 :).
Oh wow, great read... I wish I had seen that earlier. Thanks for sharing! To elaborate, the rabbit hole I remember going down was something like googling "how to center css", then after being confused by a number of horrible incantations, arrived at flexbox then CSS grid, which was slightly less confusing, and then I took some time to really study the basics/fundamentals.
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 :(
Although Jeremy Thomas' design might be more complete, I do like the minimalism of your approach - a few lines that can be dropped into a page to quickly take it from unreadable to a pleasant experience. The only things I'd add are font-family: "San Francisco", "Helvetica", sans-serif;, and perhaps line-height: 1.5.
> I recommend "Web Design in 4 Minutes" from the CSS guru behind 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.
> 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.
I'm sure he could do that by navigating to a new page every time. But the tutorial is about styling one step at a time without getting distracted, and I think that is solid teaching.
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...
I agree, but I found the first half much more useful (so far) than the last half. The second half was honestly a little overwhelming it what it felt like it was assuming about my capabilities. Less of "this small change or some slight variation will help a lot" and more "use your design experience to choose something visually pleasing here", which honestly, the lack of such experience is why I was reading such a guide.
That's really cool and will help me a lot with CSS I think. However, as others have mentioned, the change from black to a gray text color #555 makes things slightly worse and would be better if it were a darker gray. It does make one trust the article less.
It's a cool little snippet but it's nothing more than three run-of-the-mill CSS declarations.
The maximum width is specified, a small padding is applied and the margins around the element are set to automatic so it centers itself horizontally.
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].
[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.
It's 61 bytes because you're using two spaces instead of tabs! :^)
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.
I definitely considered this! But rem feels more predictable and straightforward. I have seen debates on em vs. rem, and there is certainly value with em in websites that have lots of nested and/or discrete responsive components, but for a very simple site, I quite like rem.
Ue rem when your reference is the base page. Use m when the refrerence. is surrounding text.
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.
In my opinion em would be more predictable. With the current configuration, users of this package would only be able to adjust the font size by setting font-size on the html element, but not on the body element or any container elements of the main element, or even the main element itself. That is pretty confusing to me, I think it is a pretty typical expectation that making the font size of a container bigger or smaller should always make everything inside proportionately bigger or smaller.
The author actually loads 10x that much CSS (546 bytes) into the example page! [1]
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.
Haha yes, I mean 58 bytes for layout, not layout + styling.
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.
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.
IIRC, the way browsers interpret margins and widths on the <body> element isn't consistent; and they may not support overriding block properties on the <html> element at all. Or maybe they do now, but that certainly wasn't cross-browser-friendly until very recently.
Oooooh. Good point. Currently, I have header (which has the post title, and date) nested in article, nested in main. Nesting the header inside the article makes sense to me, but you're (and other people on the internet/s.o., as I am now seeing) suggesting that header should be outside main.
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 :(
An earlier screen-reader discussion suggested that <main> is of interest to screen-reader users. I presume that's because it generally doesn't repeat navigation that exists on every page.
From my understanding, a document can have a header, footer, and/or multiple articles[0], with each article potentially having a header/footer specific to the article[1]. Presumably, the article(s) should be contained in a <main>.
The semantics are only suggestions, not hard and fast rules.
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.
Lines should be between 50 and 70 characters for optimal readability. Longer lines take longer to read because you increase the time you spend seeking the beginning of the next line. You can increase line height to compensate, but the seek time improvement is small and the information density decrease is large, and it looks pretty terrible. Columns would be a great solution, but HTML/CSS’s tooling for it has a lot of integration and polish issues, so doing it in a way that’s actually better than the strip is a lot of work.
Arguably, though, a website that’s surrendered to the strip should make some compromise between line length readability and reducing scrolling.
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.
After seeing Gwern's website[0], I immediately knew what design I wanted for my personal site [1]. Tufte's CSS package is much heavier than these three rules, but it achieves the same result: Content designed to maximize readability by removing distracting elements and respecting known typography rules.
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.
Your website is wonderful, I encourage you to share it more! I did some extensive preliminary research looking around at personal sites posted to HN and other places, and am now surprised I hadn't yet stumbled upon yours until now.
Lovely, but if you're making a big deal about quotes and pull-aways in your format, might I encourage you to use proper quotation marks — eg. “The” vs. "The"?
Thank you! Before making this I visited a bunch of personal sites / blogs that had been posted here, and surprisingly very few of them were similar in this regard. I may post about the websites that gave me inspiration in the future. (You may like https://legiblenews.com)
Readit News
I recommend "Web Design in 4 Minutes" from the CSS guru behind Bulma:
https://jgthms.com/web-design-in-4-minutes/
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.
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 don't think "dark theme" is always the right answer, but I think with a new medium, a new basic is worth considering.
Content :: Fonts and Colors :: Advanced :: Allow pages to choose their own fonts
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).
While it is an additional HTTP request, it's not necessarily another host. You can perfectly host fonts in your own site
I will reiterate my past comment that it is inevitable for many non-English scripts.
https://news.ycombinator.com/item?id=19569571
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?
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 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.
Rewording, I am tired of "pretty" being an add-on or, worse, the entire product.
Isn’t this due to cost?
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.
[1]: https://news.ycombinator.com/item?id=19600440
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 :).
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 :(
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.
https://news.ycombinator.com/item?id=6791297
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...
* 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 :(
https://news.ycombinator.com/item?id=18758847
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar...
[1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin...
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.
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?
Arguably, though, a website that’s surrendered to the strip should make some compromise between line length readability and reducing scrolling.
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
https://practicaltypography.com/line-length.html
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
[0] https://www.gwern.net/About
[1] https://lawler.io