Hacker News new | past | comments | ask | show | jobs | submit login
58 Bytes of CSS to look great nearly everywhere (jrl.ninja)
797 points by JoshuaRLi on Apr 8, 2019 | hide | past | favorite | 225 comments



Author mentions this took a long time to arrive at.

I recommend "Web Design in 4 Minutes" from the CSS guru behind Bulma:

https://jgthms.com/web-design-in-4-minutes/


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.


Blackest black and whitest white used together will trigger my dyslexia and makes reading almost impossible. Even though I have very mild case of dyslexia! But like you said, slight tint makes wonders. Even in my case.


Assuming I can’t change my background color to anything else than #000000, what kind of text color would you suggest other than #fff to improve readability?

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.


I hate websites with black backgrounds. It makes my eyes swim. I always turn off colour or just skip them.


Thanks for the input. I personally love it, plus it saves energy!

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.


If you insist on a black background (and I think that's less accessible) you should chose a font that is off-white toward yellow. Something like ffffee.


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.


If your monitor is shining like a bright flashlight in your eyes, then you have your monitor's brightness turned up too high. (And/or your room's ambient lighting is too low.) A window with a white background should appear no brighter than a white piece of paper held up next to your monitor. If you use this technique to adjust the brightness of your monitor, you can read black-on-white text all day long and never get eye fatigue. I've been adjusting my displays this way for ~20 years.


I almost agree with you, but the truth is even with almost minimum brightness, I still prefer that background color get slightly darker than pure white (and same in black backgrounds: the text should not be perfect white).


Sort of like the way HN implements it. Grey or something off white tends to be easier on the eyes than pure white.

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.


That's the problem isn't it?

The goal of design isn't to correct the user, but to correct for the user.


> 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.


...and make everyone who has their monitors actually set to a sane brightness and contrast suffer? I'm not going to turn up the brightness (and thus decrease battery life and backlight longevity) just so I can see poorly-contrasted text that someone thought would be a good idea "to correct for the user" who should really be the one adjusting his/her badly set hardware.


I came to say almost the exact same thing. I use dark themes wherever possible, and flux when not, because backlit monitors are not print.

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.


This is why I send interesting articles etc to my kindle to read. It's so much nicer reading longform stuff on eink than a laptop screen. The conversion isn't always right, but it's normally good enough.


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


I'd like to use this too. Currently, my adblocker is blocking fonts, and fontawesome is a nightmare because icons everywhere are missing. How do you handle that?


Sadly, I don't. This breaks a few sites terribly, as I end up with random characters instead of whatever the "awesome" icon was supposed to be. Usually it's obvious enough from context what the icon should have been, and it just looks ugly.


Like this, unfortunately: https://gitlab.com/Darkenetor/userstyles-userscripts/tree/ma...

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.


Keep sending them emails until they change it to SVG. Fonts are not supposed to be (ab)used like this.


It's the user breaking the convention in this case. They're capable of fixing the page if they want to. Spamming the author with emails would simply be harassment.


ActiveX controls used to be conventional too.

This dingbat crap also hinders accessibility, as you can’t specify alt text like you could for images.


Well, icons are not intuitive anyway, so it probably doesn't make difference :)


> 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).


Further, book paper - particularly for non-technical books, where diagrams are rare and reading is done in long, uninterrupted stretches - is often intentionally off-white, to lower the contrast and make it easier on the eyes.


Off-white paper is there for cost-saving reasons, used mostly for cheap romances and thrillers typically sold in airport bookstores. I don't think they even consider readers comfort when choosing it.


Textbooks with glossy, bright white paper are a pain to read under a library light. But they make images look great.


Smartphones tune down brightness in power saving mode (and so do e-ink books). Most websites are barely legible under those conditions, because web designers have been so heavily corrupted by backlight.


> Not a big fan of @font-face. Another host to visit.

While it is an additional HTTP request, it's not necessarily another host. You can perfectly host fonts in your own site


True. But how many actually do that vs. how many just slap a “fonts.google.com” link because “meh”.


I develop on the train to work a lot, where the wifi quality ranges from "can almost stream video" to "in the middle of a field". Whenever I add google fonts to a webapp I'm working on, I really notice it. Lately I've simply not been using them anymore for this reason.


Yeah, which sucks.

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.


> 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.

https://news.ycombinator.com/item?id=19569571


Only Korean? But if you don't have a decent font on your machine, how the text is rendered?


> Only Korean?

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.


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?


What is the username in this image? [ https://i.vgy.me/faxIj4.png ]

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.


I suppose, as selfish as it might be, that I would like people to at least try to see if they can bear to use a web site the way I designed it, perhaps for the same reason a conscientious chef would very likely prefer you to at least try her food before immediately reaching for the salt and pepper.

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.


This was answered in a sibling thread: https://news.ycombinator.com/item?id=19608696.


Most fonts are ugly, see ubuntu.com


Indeed #555 for text is ridiculous.


"Ridiculous" is subjective, but I tend to go by WebAIM's contrast guidelines for web accessibility when looking at text color vs. background color. While #555 text would be lighter than what I'd normally pick, if it's on an #FFF background, it's a contrast ratio of 7.45:1 -- which means it passes the most stringent WebAIM requirement (level AAA for normal text, which is a minimum of 7:1 contrast).

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.


a lot of folks seem to greatly overestimate how difficult to read "grey text" is

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.


Thank you for bringing that up, I had no idea about this contrast ratio thinghy at 7:1, I'll make sure to comply in the future!


Is it accurate to call those numbers contrast ratios when you seem to be ignoring gamma correction?


You can take that up with the maintainers of the WebAIM contrast checker, if you think it horribly biases the results somehow.

https://webaim.org/resources/contrastchecker/


Choosing the absolute minimum acceptable readability is not something to shoot for imho.


> 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.


> Black text on a white background can be harsh on the eyes.

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.


>I am just very tired of “designers” doing “pretty” stuff instead of solving a problem

Rewording, I am tired of "pretty" being an add-on or, worse, the entire product.


> Black text has been fine since the first printing press.

Isn’t this due to cost?


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.

[1]: https://news.ycombinator.com/item?id=19600440


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)


Thanks for shipping it!

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.

There is nothing ironic about that.


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.


If you search for "motherf--ing website" you also have many examples of a very simple but readable website. (I hate the edgy language though.)

https://news.ycombinator.com/item?id=6791297


> (I hate the edgy language though.)

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...



Once the text goes to gray, it is objectively harder to read.


This is the best CSS/design tutorial I've seen, thank you for sharing.


That is an interesting format. It's encouraging to see small, incremental changes to the style sheet result in so vast improvements in legibility.


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.


For me it started being less legible after the font change to Arial and kept going downhill from there.


At the point where the contrast of the text was reduced, I was off the hook. I'd rather do that the way OP did, by changing the background to a pleasant pastel. Either way, I'm impressed with the format.


This is a wonderful tutorial. I wish back worked though.


Agreed. I keep wanting to compare the differences between two steps.


Thanks for sharing this.

* I clicked your link * closed the HN tab * was completely blown away by the article * "Reopen closed tab" and up-voted your comment


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.


The text just becomes harder and harder to read the more it progresses.


Wow, that's nearly definition of a great tutorial.


As the contrast keeps getting lower that page keeps getting harder to read. We don't all have super bright macbooks turned to full brightness.


> What is the first thing you need to work on?

Your hyperlinks need to work without Javascript.


Looks promising for a Web Development quicky.


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].

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.


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.


When fully minified, it's actually 47 bytes: main{max-width:38rem;padding:2rem;margin:auto}

But I think the original is still well into the land of diminishing returns.


Agreed, but OP isn't serving minified content.

I brought up rem vs em because the difference is subtle and if you're byte shaving it's "free" bytes.


The author is not byte shaving. He states that he is striving for "simplicity," which isn't the same thing.


46 bytes if you take out the new line :)


45 if you remove the trailing }.


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.


Are you sure you don't have the meanings reversed? REM is the one that ignores nesting. EM doesn't, so on a simple site it's easier to use correctly.


I'm sure. For that reason (ignoring nesting), I think rem is easier to use correctly. I think what you're getting at is that simple sites have little nesting, therefore em, but I'm thinking about in terms of em being great for say, css framework developers.


Depends on context and reference: https://news.ycombinator.com/item?id=19608806


Remove all spacing to save even more.


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.

[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...


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.


There's more CSS on the page than that though.

And it doesn't look great everywhere. At 375px-wide the line-length of the text is ~35 characters, optimal would be 50--70.


True. By looking great nearly everywhere, I mean the layout of the elements on most devices. What device do you have that is 375px wide?

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.


> What device do you have that is 375px wide?

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.


Ooh, I just found out the very rectangular Galaxy S9/S9+ viewport is 360x740. Just wanted to let you know.


How would you fit 50-70 characters on 375px wide lines?


Just remove the padding

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 don't think removing the padding is beneficial in this case.



> main {

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.


Yep, I think the priorities should be <html> and <body>. Here's mine, which centers the content both horizontally and vertically via flexbox:

    html {
      display: flex;
      align-items: center;
      justify-content: center;
      min-height: 100%;
    }

    @media screen {
      body {
        max-width: 40rem;
        margin: 1rem;
      }
    }
It's not perfect, but it works well for simple websites (e.g. https://colorclock.hashbase.io/).


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.


>IIRC, the way browsers interpret margins and widths on the <body> element isn't consistent

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.


Yeah, I should mention that this is only for browsers that support flexbox (https://caniuse.com/#feat=flexbox) with little regard for browsers that are behind on their updates. Thanks for pointing this out!


Also, flexbox allows a child element to center itself using `margin: auto;`: https://codepen.io/anon/pen/gyLGwW


Is there a benefit to doing it that way?


Over the parent dictating? No, I wouldn't worry about it.


I cannot access your website: ERR_SSL_PROTOCOL_ERROR


What's your browser? They're using a Let's Encrypt wildcard certificate. It works for me in various current browsers but also in Firefox 3.6.27 for Mac (from 2012).


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.

https://news.ycombinator.com/item?id=18758847


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>.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar...

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin...


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.


Is it just me, then, that hates the "narrow strip of text down the middle of my large monitor" school of web design?

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?


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.


It's to help readability for larger blocks of text, so it's easier to find the next line when the text wraps


> 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.


https://caniuse.com/#feat=multicolumn

Even IE10, mobile safari, and the gingerbread android browser support it


Support is still bad. There's no easy way to fill columns left to right that works well on both short articles and very long ones.


This would make so much more sense to me than the thin strip of text :)


Constrained line lengths increase readability:

https://practicaltypography.com/line-length.html


A reason is that scanning horizontally with your eyes while reading a long text increases the chance you'll lose your place.


What became of text columns https://caniuse.com/#feat=multicolumn to enhance readability and still use all that space? Is anybody using them?


I think because so many of the people here are programmers, there will be some incentive to talk about the code, but the design is lovely.

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.


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.

#longformrebellion #endthelisticle

[0] https://www.gwern.net/About

[1] https://lawler.io


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"?


Thanks for pointing that out. I was under the impression that Pelican's Markdown parser automatically used typographic quotes vs straight quotes, but that's apparently not the case.

Edit: Ah, it's an extension to Python-Markdown that is not enabled by default: https://python-markdown.github.io/extensions/smarty/


Ah, much more developed than I — I maintain a site that has a font similar to yours and I need to manually amend each and every typographic conceit. Not smart!


No worries! There's always room for improvement. Though my site now automatically swaps in [0] the correct typographic quotes (thanks again!), I still have to manually add <section>s and the HTML for the sidenotes, instead of using some kind of Markdown conceit that gets automatically translated when the site is compiled. :)

[0] https://github.com/Eiriksmal/lawler-dot-io/commit/593d3471e6...


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.


Bonus points for looking sharp when I have JavaScript disabled.


Gorgeous


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)


It looks like LegibleNews stopped updating back in January. What a pity, I really liked the concept.


Doesn't look "great" on mobile. 2rem margins are way too big for a phone screen. Too much wasted space.


2vw would be a reasonable substitution, as it creates a dynamic margin, based on the screen's "view width". Smaller screens → smaller margins.


Thanks for bringing vw to my attention, it sounds great! I tried it out and the main problem is 2vw looks much more reasonable on many mobile displays, but puts a lot of top margin on wide screens (laptops/monitors). I still want to retain the same size margins for top/bottom and left/right, so a happier medium would be to vw for mobile and rem for tablets/laptops/monitors, but then that's too much trouble for diminishing returns in my opinion.


Just use 1rem everywhere. There is no reason for the hideously large 2rem margin. Another person said it's just opinion, but I'm sure 9 out of 10 users would tell you 1rem is the better looking option overall.


There is `vh` as well, it works the same way, but instead of working relative to viewport width vw, it works relative to viewport height vh.


That's just opinion. As long as it's not hugging the edge it's fine, it's erring in the side of caution at best.


Still wastes 60% of my display's width.

Sorry, if you are into minimalist design I keep getting back there, with 58 bytes less of CSS: https://motherfuckingwebsite.com/


From that website:

>Yes, this is fucking satire, you fuck

> I'm not actually saying your shitty site should look like this.


> Websites aren't broken by default, they are functional, high-performing, and accessible. You break them. You son-of-a-bitch.


I notice that the author doesn't use capitals either and I'm not sure if visually I like that or not. It makes it feel more casual which is nice, but I think it does get harder to parse the sentences.


I am going for the casual feel, although I am aware for some people it does hurt readability. But I quite like it, and want to indulge a little on my own site :)


There is a CSS rule for everything lower case. If Google gets a snippet of your page and puts it in the less casual results it looks silly in lower case. The content needs to be written with capital letters and punctuation and styled to be casual.


> font-family: Arial, Helvetica, sans-serif;

Putting Arial before Helvetica :(


I've got to save browser CPU cycles! /s


Can say I love the choice of background color.


Thank you! I'm going for a pastel-like palette individual to each top level directory, if you poke around a bit. Website is still in early stages, so colors aren't fully thought out yet, but I'm very glad to hear you like it.


how would you go about choosing a color palette? do you use tools to generate a palette[1] or is there some secret recipe or common rule set that graphic designers follow to come to a final combination that makes sense?

[1] https://github.com/dylanaraps/pywal <- just discovered this yesterday during a weekend effort to improve the color combination used by my window manager, ...


In my experience, automated color palette generation tools look cool, but don't work that well. Most applications or websites need far more colours than people think, even if those colours are used sparingly. This example chapter from the Refactoring UI book called "Building Your Color Palette"[0] was quite helpful, even though I didn't buy the book.

[0] https://refactoringui.com/previews/building-your-color-palet...


I have absolutely zero experience in graphic design or color theory, etc! I just pick whatever colors I think look nice. That being said, as I put more content on my site, I'm looking forward to learning more in this space.

Side note - you'd probably like this: https://jrl.ninja/configs


There is this background color named 'snow'. It looks great and it's just four letters. In HEX it is #FFFAFA (I don't think many CSS minifiers consider #FFFAFA -> snow).


You can use 3-digit hex colors in CSS too.

#eee = #eeeeee #abc = #aabbcc

It's not very precise, but can be convenient short hand.


I find it interesting that this snippet is used:

::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.


Interesting, I didn't consider the fact that blue-screen filters are quite common nowadays. However, I still like the aesthetic of highlighting something on the page with a color similar to that of a highlighter pen, as opposed to the blue highlight + invert color. I remember I was on some website one day and it had this same effect, which I found to be pleasantly surprising.


I do like slightly changed selection colors, but I disabled f.lux and found the yellow too bright and jarring, something a bit more muted is what I prefer.


It's #fff888 now, thanks for the feedback! I had #fffaaa in other places and forgot to change it in etc.


f.lux makes many websites (and indeed apps in general) harder to read, or just look awful. Not sure it's reasonable to expect an arbitrary website to be "f.lux compatible".


Never had any problems with sites being hard to read. But I also don't really visit overstyled sites.

Not to mention that you actually have to do the effort to make it incompatible :)


IMO f.lux makes everything look awful.


Thankfully iOS Safari completely ignores this. I would hate it if websites could mess with my selection color.


My favorite resource about minimalist CSS : http://bettermotherfuckingwebsite.com/

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 took me a surprising number of iterations to arrive at this point. perhaps that speaks to the fact that i know nothing about "modern" web development, or [..] just how hard it is to keep it simple in a world of complication.

It's the latter. Being both simple and good is not easy.


I recognize some of those scrots. Funny to see another /g/ent with a minimalist setup and website.

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.


Looks great even without CSS. The only exception is a very wide viewport.

1024x768: https://i.imgur.com/NEAenbY.png

320x568: https://i.imgur.com/TdVjnKR.png

3480x1600: https://i.imgur.com/MfhxmRD.png


I wouldn't call that great. Acceptable would be a better word.


Why would you want to disable the CSS?


I think the point is that, aside from max-width, this does very little that the browser's default stylesheet doesn't already provide.


Please don't do this with max-width it makes printing a huge mess, I regularly have to edit max-width on sites that set it so I don't have to print double or triple the number of pages, at least set max-width to be a relative unit for print.


Max-width is the correct setting for the desktop, where windows are resized to enable proper reflow. Printing web pages should be quite rare, no?


either way:

    @media print {
      …
    }


How often do you print websites?


seems like this could be solved in the OP with something like "@media screen".


That text area is way too narrow. It inhibits scanning to be unable to see very much of the text at once, because it forces you to scroll see more than about a paragraph at a time.

Readability isn't the concern. Show me a book with margins that gigantic.


Cool! For my personal taste a little bit too much padding for my Galaxy S9 though. 1.25rem or 1.5rem would be sufficient and gives another 1-2 characters per line. But that's mostly personal taste.


Would you mind taking the time to provide a screenshot? What you suggested sounds like a good idea to me!


Here you go https://imgur.com/a/BzMdUtQ

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.


Cool, thanks! It's 1.5rem now if you hard refresh :)


For me the "edge" on a small mobile display feels different than on a full monitor and I've always preferred a small padding on the mobile device.


I would suggest you to always put a `color` when you define a `background-*`. Now that website can support darkmode, it would be a shame to see a white text on this yellowish background...


I'm definitely going to steal your website design (please don't sue me). But I don't like sans-serif fonts. What serif fonts do you recommend to use instead?


I don't care and am instead flattered :) Would appreciate a mention in the comments if you indeed do, though.

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.

[1]: http://web.mit.edu/jmorzins/www/fonts.html


just use font-family: serif; and let the browser use its default. Soon browsers will support font-family: system-ui; too.


I’m an outsider to this world so please forgive the basic question: what is “main”?

Does its use depend on any particular markup in the HTML?

And how far back does it go as a CSS feature?


"main" is not CSS, it's an HTML element introduced as part of HTML5. All modern browsers support it, Firefox since 2013. No version of Internet Explorer supports it but all versions of Microsoft Edge do. Browsers ignore elements they don't recognize (they don't ignore what's within them) which does mean they will ignore CSS statements that only uses "main" a selector.

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...


Thanks!


This is definitely better than nothing.

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.


> it appears that the default font size for most browsers is 16px, so 38rem is 608px

What does px mean in CSS? I thought it was pixels but clearly not...


"The px unit is the magic unit of CSS. It is not related to the current font and usually not related to physical centimeters or inches either. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like an e-book reader? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use."

https://www.w3.org/Style/Examples/007/units.en.html


So that mentions that print sets px at 96dpi.

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.


> What is sharp, small and visible depends on the device and the way it is used

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!


Pretty much, yes. Screens changed and evolved so now it doesn't mean much and most people will attempt to skip using them.


It is defined as a small but visible size. Whatever that should be is left to the implementers.


What do you mean? 16*38=608


Yeah, I can multiply correctly, thanks mate.

> 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.


Unless you're on a phone it's more likely than not to actually be 16 pixels. Otherwise it's based on your system's GUI scaling, which varies a good bit.


Right, that's what I was saying originally. px doesn't seem to mean pixels, which is confusing. Why is anyone using pixels to layout graphical content in the first place?


Sorry OP, but it doesn't look good everywhere. You're only using the middle 1/3 of the screen on desktops.


Three more:

    body { font-size: medium; }
    main, article, content { font-size: 1rem;}
    p, li, dd, dt, blockquote { font-size: 1em; }

Give the user their default font size, not some px-defined kludge.

Em vs rem: https://news.ycombinator.com/item?id=19608806


Interesting.

I'd recommend Water.css for a more through out-of-the box experience that looks great anywhere.


Assuming that JoshuaRLi is Josh:

I really like your site. A minimalist website is surprisingly hard to achieve.


Thank you! I've indeed sunk a surprising amount of effort and time to make this. I have like, 5 directories of past iterations that didn't "feel like the one" spanning a bit more than a year.


Looks like crap on high resolution monitors >.>


Then the page is ruined by the disastrous Arial font.


As someone else who is not versed in CSS this is epic


Love this! 58 bytes of css... and it's typographically better than Wikipedia and many other "styled" websites!


I dig it! Good job!


This is beautiful.


> that speaks to the fact that i know nothing about "modern" web development

I thoroughly agree with his statement and just wanted to post this to help emphasize the fact.


> max-width: 38rem

> 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".


[flagged]


Having seen a number of HNers personal websites, they could absolutely stand to benefit from a simple article like this. Many of them are more interested in talking about how minimal their static site generator is, rather than whether the content on said site is readable or even mobile friendly.


These were my sentiments exactly while exploring other peoples personal websites before making mine! Thank you.


It's one reason why I liked write.as a lot and started writing some stuff on there. Their CSS is really nice and simple.


> I get the impression from that the author is an ancient backend

Thanks for this clear example of an offhanded dismissal.


"Works on my machine, in this viewport size."


Another good resource for this "minimal" approach is:

https://motherfuckingwebsite.com/

.. and it's followup:

http://bettermotherfuckingwebsite.com/

(Both are SFW sites except for the use of expletives in the URL/title).



Don't forget the excessive use of expletives in the content.


I'm a fan of the colors and typography on this one: https://evenbettermotherfucking.website




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: