Live data from Hacker News

58 bytes of CSS to look great nearly everywhere

gist.github.com

191–200 of 254 posts

Re: 58 bytes of CSS to look great nearly everywhere

#191

I think this does not work well for mobile devices. Spacing and the font size is too large. Hence, a lot of screen space is wasted and the user has to scroll more. Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway. A snippet that could work better in my opinion is the following: html { max-width: 70ch; /* larger spacing on larger screens, very small spacing o…

I like this but given the max-width: 70ch, how do you prefer to handle things that you do want to take up the full screen width, such as pictures or header/footer with a background color? Explicitly set each of them to 100vw? I've tried the opposite approach, setting the max-width only on p,h1,h2,h3 (etc) but it's error-prone. I've never quite found a set up that feels simple and robust.

[deleted]

Re: 58 bytes of CSS to look great nearly everywhere

#192

Earlier quoted context omitted.

I don't like that. I can adjust the full text width by adjusting my window but if have a big wide screen and you limit it, then I'm wasting a lot of what I can see. Give me customization, not "alleged optimization" that turns out not to be so

Don't confuse constraining an entire website's width for constraining the text reading width. You can gracefully have maximum reading width text columns with other content to the left and right of it to maximize real estate. Also, don't ask users to resize their browsers to accomodate for a site's poor UX. That's called "blaming the user."

As a user, I expect to use my browser window to resize the content in my browser. Please don’t second-guess my preference.

9X% of web sites don’t do anything sophisticated, with columns or otherwise. They hard limit the content width regardless of the user’s window size, resulting in a tiny sliver of text.

Re: 58 bytes of CSS to look great nearly everywhere

#193
post #162

Earlier quoted context omitted.

I don't like that. I can adjust the full text width by adjusting my window but if have a big wide screen and you limit it, then I'm wasting a lot of what I can see. Give me customization, not "alleged optimization" that turns out not to be so

paragraphs are less readable past 90-100 characters width

I hear this a lot, and as a user I simply don’t care.

I deliberately bought a giant high resolution monitor that I want to fully use. If I stretch my browser window full screen, I expect your web site’s content to expand to fit. I don’t care what some researcher thinks is “readable”.

I wish web developers would stop second guessing the user.

Re: 58 bytes of CSS to look great nearly everywhere

#194
post #120

Not explicitly mentioned here, but worth bringing up: Text width should always be constrained to a maximum width to optimize for human reading. Every book ever printed has text with set within the same range for a reason. Full width text guarantees most users will have a poor reading experience.

Large margins are also distracting and a waste of human time. I wish browsers or sites would automatically flow the text into n columns depending on the view window size. It's not trivial but if one is optimizing for reading, then extra window scrolling to get to newer sections of text is not particularly optimal either.

Web sites should just serve the text and let the user-agent make the readability decision and decide how to appropriately render it. Browsers have handed over way too much layout and stylistic control to web developers.

Re: 58 bytes of CSS to look great nearly everywhere

#195

I think this does not work well for mobile devices. Spacing and the font size is too large. Hence, a lot of screen space is wasted and the user has to scroll more. Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway. A snippet that could work better in my opinion is the following: html { max-width: 70ch; /* larger spacing on larger screens, very small spacing o…

> max-width: 70ch;

OK. This will probably be in the range 640–780px where it caps out (taking the font-size scaling for that width into account), but it depends on the font (and the viewport aspect ratio because of the font-size vmin component). Acceptable.

> padding: calc(1vmin + .5rem);

Assume the browser em is 16px (almost always true) and the above values for 70ch, and you end up with this reaching almost 15px at 700px, down to 11px on a 300px viewport (which is about the narrowest realistic viewport). I reckon a bit more is warranted at both ends, and tying it to viewport width only rather than vmin. I’d prefer just `padding: 1rem` (16px everywhere) or `padding: 4vw` (12px at 300px, 28px at 700px). Maybe a mixture like `padding: calc(3vw + .2rem)` if you really want to get fancy (12.2px at 300px, 24.2px at 700px).

Actually, a correction (though I’ll leave that paragraph alone): you haven’t touched the body margin in this stylesheet, so you’ll get an extra 8px on every side, so I’d either adjust that or reduce this padding by approximately 8px in each case. In light of the extra 8px, calc(1vmin + .5rem) is actually a bit much on tiny viewports, rather than too little.

> margin-inline: auto

But be aware this is new, March 2019 in Firefox up to April 2021 in Safari: https://caniuse.com/mdn-css_properties_margin-inline. Where unsupported, you’ll lose the centring of the document column.

Also this won’t do what you want in a vertical writing mode language. :-)

> font-size: clamp(1em, 0.909em + 0.45vmin, 1.25em);

This is typically 16px until 323.5̅px, 18px at 768px, 20px from 1212.4̅px. I would generally prefer to cap at 18px, but this scaling is acceptable. Actually, since it’s using vmin rather than vw, it’s seldom going to reach even 19px because almost no one has viewports that are both even 1000px wide and tall.

Again this is new, mostly early 2020: https://caniuse.com/css-math-functions. Where unsupported, it’ll stay at the typically-16px value.

> font-family: system-ui

I object to this. system-ui is problematic because there’s no guarantee that the font it resolves to is suitable for your content language. In Chinese Windows setups, this is likely to get you a font that renders English fullwidth, basically equivalent to massive letter-spacing. Use `font-family: sans-serif` instead. At present it will commonly resolve to a font that is subjectively not so “pretty”, but it will always provide a reasonable font, and it’ll be even better for users that have chosen their own default fonts.

system-ui has often been being used as a proxy for nicer-looking default fonts, but it has semantics attached to it, and those semantics actually make it an unreliable choice.

Also again comparatively new in the scheme of things, with Firefox the latecomer having only had it for twelve months: https://caniuse.com/font-family-system-ui. Where unsupported, you’ll get the default font, which is likely to be serif. Even if keeping system-ui, I would recommend adding a fallback, e.g. `font-family: system-ui, sans-serif`. (Incidentally also, remember the semantics of system-ui and that it might not be a sans-serif. It could be a serif, or even something more exotic. It could be Comic Sans. Do you really want your website shown in Comic Sans? Wonder if that’s the angle to take in dissuading people from system-ui! :P)

> line-height: 1.75;

Too much. Much too much. I’d suggest something in the range 1.2–1.5.

:is() is also new, last couple of years, https://caniuse.com/css-matches-pseudo. So this excessive line-height is comparatively unreliable. A more compatible spelling of the selector would be `body :not(h1):not(h2):not(h3):not(h4):not(h5):not(h6)`.

Re: 58 bytes of CSS to look great nearly everywhere

#196
post #155
post #83

Earlier quoted context omitted.

I almost agree, but there’s a difference between number of characters and width, and also graphics and tables are a different beast. Personally, I think websites should fill up the available space, increasing font size if it makes sense, perhaps using resizing images. So, no - text should not be constrained to a maximum width. If width were a problem, billboards wouldn’t be a thing.

the maximum width for readability is in characters per line so it should be expressed in that

To add: which the em unit is supposed to do, and roughly succeeds in as a it equates to the width of the letter “m”.

Re: 58 bytes of CSS to look great nearly everywhere

#197
post #162

Earlier quoted context omitted.

paragraphs are less readable past 90-100 characters width

I hear this a lot, and as a user I simply don’t care. I deliberately bought a giant high resolution monitor that I want to fully use. If I stretch my browser window full screen, I expect your web site’s content to expand to fit. I don’t care what some researcher thinks is “readable”. I wish web developers would stop second guessing the user.

The web is optimised for the bulk of its users, that’s why 90% of the websites limit line length at a ‘researched’ optimal width, and some legacy or (legacy) tech enthousiast focussed websites wrap at the end of the available width.

Re: 58 bytes of CSS to look great nearly everywhere

#198

Earlier quoted context omitted.

> Humans are good at reading columns at around roughly 80 characters What makes you say that? Anecdotally, I prefer using the full width of my screen.

Especially for long blocks of text or becomes easy to go to the wrong line when scanning back to the left side of the page. There exist decades of empirical research on this topic. https://en.m.wikipedia.org/wiki/Line_length

I can’t think of a source for this so take it as you wish but at some point in history it was attempted to mitigate this by changing the reading direction every other sentence so you’d be able to read in a continuous stream. It failed for obvious reasons.

Re: 58 bytes of CSS to look great nearly everywhere

#199

I think this does not work well for mobile devices. Spacing and the font size is too large. Hence, a lot of screen space is wasted and the user has to scroll more. Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway. A snippet that could work better in my opinion is the following: html { max-width: 70ch; /* larger spacing on larger screens, very small spacing o…

I don't get this:

> font-family: system-ui

Why render texts with the font that the reader has selected for a different function, ignoring the one that she has selected for texts?

Re: 58 bytes of CSS to look great nearly everywhere

#200
post #111

Earlier quoted context omitted.

Does anyone know what theme that blog is using? It looks really nice.

uh wow, this is the first time anyone's complimented anything I designed lol! it's a handrolled theme, with a lot of inspo from @leerob of vercel. i keep a clonable version here https://github.com/sw-yx/swyxkit/

I doubt it :), swyxkit is one of the best designed blog templates I've seen.. even if the default color scheme is a bit ..tropical.
Post reply on HN