[FrontAid]

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 on tiny screens */
      padding: calc(1vmin + .5rem);
      /* shorthand for margin-left/margin-right */
      margin-inline: auto;
      /* fluid sizing: https://frontaid.io/blog/fluid-typography-2d-css-locks-clamp/ */
      font-size: clamp(1em, 0.909em + 0.45vmin, 1.25em);
      /* use system font stack: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family */
      font-family: system-ui
    }

    /* increase line-height for everything except headings */
    body :not(:is(h1,h2,h3,h4,h5,h6)) {
      line-height: 1.75;
    }

[dwringer]

I wonder if everyone has a different optimum here based on different eyesight, screen size, and usage patterns. I always have a slightly different zoom on every website I visit.

With this one I tend to agree, I can't see enough text at once and the margins seem a bit wide.

[jcynix]

Yeah, the zoom, that almost needs to be customized per website, sigh. But one of the worst misfeatures for old (and maybe not so old) eyes, is the gray text on some "pastel" background. Contrast helps readability (as does a carefully chosen font), but "modern" designers seem to think contrast is bad or outdated or whatever.

[wolpoli]

Well modern designers deliver mockup filled with Lorem Ipsum so no one notices that the text is hard to read.

[bhaak]

> but "modern" designers seem to think contrast is bad or outdated or whatever.

I think much more reasonable is the assumption that many designers have Macs with good monitors and there you can still read it well.

Whereas most people have old or poorly color calibrated monitors where you only get a grey goo.

[jcynix]

I have a state of the art Macbook too, and a good monitor, but I still find light grey text hard to read. Because I have old eyes with suboptimal eyesight.

Anyway, it would be reasonable if designers tested their designs with other people on other hardware, instead of thinking "looks fine for me" … at least that's what I learned about design, user interfaces, etc ;-0

[FrontAid]

> I wonder if everyone has a different optimum here based on different eyesight, screen size, and usage patterns. I always have a slightly different zoom on every website I visit.

I would think so. And because of that, accessibility is an essential topic. Luckily, this snippet will automatically follow your zoom level and/or font size settings.

[mwcampbell]

But it would be better still if browsers offered an opt-in modern default style, to relieve us developers of having to make assumptions about the user's visual needs, which should be the domain of the user agent.

[WorldMaker]

Firefox had that for a long time, hidden in a menu, but discoverable eventually. It also used to have a menu for Alternate Styles when a webpage included named LINKs to alternate styles (allowing pages to have a heavy, preferred default but offer the user other options, without needing to add a "theme picker" in the HTML somewhere).

Outside of dedicated "Reader Views" it seems like we've given up on the idea that might be something the browser should do. (Which, I appreciate the "Reader View" as an easier to discover way to do this, even if I think moving it into a "modal" with its own liminal space continues the narrative of the browser moving away from being a "user agent" to being an "application runtime".)

[rch]

Content on the web used to flow pretty well irrespective of those factors. The 'liquid' layout in Adobe's pdf reader works as it should, as does the simplified view in Chrome (which is suspiciously only offered on sites without ads). So, I'm optimistic that simplified layouts are worth pursuing.

[b112]

If Google would stop the absurd block on text reflow and resize, on Chrome Android, we'd really be good.

Seeing how slick and smooth and beautiful and handy it is on Opera, puts any ridiculous dev team rejections to waste.

Text reflow missing from Chrome -- valid proof end user convenience is not a primary concern.

I bet text reflow moves ads into the wrong position, thus the decade long block.

[rch]

Designers want the latitude to place ads where they're likely to be effective. How does an ads company which incidentally also provides a browser balance that interest?

[b112]

How does an ads company which incidentally also provides a browser balance that interest?

Another argument for forced Alphabet breakup. Browser in one corp, on its lonesome.

Amusingly, Alphabet has given us the number of new companies. 26. Maybe Chrome can be called C, Google search G of course, M for gmail, etc.

[zx8080]

>forced Alphabet breakup

Who will pay C for browser? A for ads. They will pay only for things they need.

Will people (and you?) pay for Chromium browser to compensate its development? It's _expensive_, by the way, to develop that complex project.

So I don't really see how G brakeup helps get better browser for free.

[logifail]

> Hence, a lot of screen space is wasted and the user has to scroll more

Unfortunately that appears to be the case for a great many sites when viewed on a mobile device.

My current pet hate is British Airways, https://www.britishairways.com/travel/home/public/en_gb/ has so much wasted space that on my Pixel I have to scroll to reach the buttons "Manage My Booking" and "Check In". Further down the page the "Your account" and "Sign up" bits are so large and generously padded that they fill my mobile device's screen all by themselves.

Is this by design? Maybe in some warped design brief "scrolling" = "[potential] customer interaction" = a KPI gets fulfilled?

[maccard]

Frankly my pet hate is that page takes 7 seconds to load on a 500Mb WiFi connection on a high end android device.

[b112]

I bet you think autos should not have wood interiors, too! Heathen!

(I wonder if it is a "posh / classy" style or what not?)

[DaveInTucson]

hopefully not too dumb a question, but why put this on html instead of body?

[FrontAid]

Au contraire. That is good question. Everything in the snippet except the font-size should also work with the body selector. The font-size is an exception here as it defines the root font size that the `rem` unit is based on. And that has to be defined on html.

https://css-tricks.com/html-vs-body-in-css/

[samtheprogram]

This, in combination with the author trying to limit the number of bytes (adding another selector would be unnecessary and add to the length), is why.

[clairity]

in my personal css framework, i only do fluid type on headers, not body text, as i found the effect to be too subtle to matter. but header text can be overwhelming on small devices without it.

then you can let the user (agent) set the default font size on root/html.

[sholladay]

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.

[lelanthran]

> . Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway.

So? Most people over a particular age cannot focus close-up anyway, so the phone is at arms length or close to it, which requires a larger font size.

[nottorp]

Yep. Test on your parents or elder colleagues.

[nicexe]

Yep. Lets optimize for the 20%, let the 80% adapt by moving their phone further away.

[lelanthran]

> Yep. Lets optimize for the 20%, let the 80% adapt by moving their phone further away.

What 20%?

Near-focus eyesight problems start in mid-30s for some folk, and are already noticeable in close to 100% of 40 year olds.

You're optimising for 45%, not 20%, while allowing almost 100% to view.

Doing it your way optimises for 55%, while allowing only 55% to view.

[chrismorgan]

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

[antics9]

This will work in obscure browsers like Netsurf as well:

html{ margin:0 auto; max-width:80ch; padding:0.6em; font-family:serif; line-height:1.6; background:#FFF; color:#222 } h1,h2,h3{color:#444} img{width:100%}

[teo_zero]

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?

[7steps2much]

MDN[0] says:

> Glyphs are taken from the default user interface font on a given platform. Because typographic traditions vary widely across the world, this generic is provided for typefaces that don't map cleanly into the other generics.

So it might have been used to make the snippet "truly" universal for the developer using it. That said, I believe it would be better to choose the font family based on the content.

Even if a viewer is from a place where Serif/San-Serif/etc. doesn't make sense, they are still viewing the same content as anyone else.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family

[teo_zero]

I still don't get it. You don't know what users select as UI font, how can it be universal? On the other hand, you do know what font they like for text, but decide to ignore it and serve them text rendered in what they selected for buttons!

[chrismorgan]

You are correct not to get it. system-ui has been abused from the very start as a proxy for prettier default fonts, but it has semantics, and those semantics make it unsuitable for use as a body font. https://infinnie.github.io/blog/2017/systemui.html gives a simple demonstration of how it can go wrong.

So stick with something like serif or sans-serif.

[alberth]

> body :not(:is(h1,h2,h3,h4,h5,h6)) {

That seems both clever and hard to maintain over the long run.

[taberiand]

What would make it hard to maintain? (honest question, I'm rather ignorant of CSS)

[alberth]

I like my code to be explicit. Meaning, you are clearly defining explicity what you code should DO.

But using the ":not(:set())" operator, you're making your code implicit. Because you're telling your code what NOT to do (and instead rely on defaults or other side effects to define what will happen to your headings line-height).