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;
}
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.
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.
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
> 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.
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.
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".)
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.
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?
> Will people (and you?) pay for Chromium browser to compensate its development? It's _expensive_, by the way, to develop that complex project.
This sounds like an argument for breaking up Alphabet, not an argument against it.
You're effectively saying that Google is using their resources to give away something really expensive, which means that no competition will ever arise.
The Linux kernel is OSS, yet magically gets build collaboratively. And many large OSS projects exist, often more complex than a browser, without a sole source, single corporate backer.
Or, gasp!, even a corporate backers at all.
The modern stack is built upon, and relies upon OSS. Even chromium draws code taken from other projects, and also, relies upon a myriad of OSS libraries and toolsets.
And beyond all of that, Firefox exists is an immensely cash flush environment.
There are endless business models, and OSS development models, without business involvement to make a browser.
The world was doing just fine before chromium came onto the scene. Chrome was pushed by Google's search engine, bundled with Chrome books, Android, on TVs, and more.
Chrome is market dominant partially due to Google's aggressive push for market share.
All this said, your fears are unfounded, and currently one of largest threats to our way of life, to freedom, to democracy, is the entire ad ecosystem.
This ecosystem, in its curent form, simply must die. There are no patches, no fixes which involve any data collection on the user, that allow for co-existance with personal freedom and democratic principles.
Ads need to be served with zero knowledge stored and collected about users, and anonomization is meaningless and proven useless.
Whether Google is broken up or not, Chrome will die soon enough, as a personal spy, and a collection device.
Google's best move right now, is to discover profitability, research how to enable it, without data collection.
Because what has happened to Meta is only the start, what is happening to Google and others in the EU, is coming to the rest of the West, and this business model is over. It's done. Finished.
Execs who are not planning for a corporate future without data collection, are poorly managing, and living in the past.
Google's best move is to see where the market will be without data collection, and use its immense power to move there now.
> 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?
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.
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.
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.
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.
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.
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)`.
> 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.
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!
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.
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).
A snippet that could work better in my opinion is the following: