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