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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
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?
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.
"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.
> 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.
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.
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.
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.
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.
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!
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.
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.
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.
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. :)
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.
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)
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.
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.
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.
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.
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).
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.
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".
> 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.
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.
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.
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.
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.
"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.
"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."
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!
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?
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.
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.
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.
I recommend "Web Design in 4 Minutes" from the CSS guru behind Bulma:
https://jgthms.com/web-design-in-4-minutes/