58 bytes of CSS to look great nearly everywhere | Hacker News Reader

58 bytes of CSS to look great nearly everywhere

gist.github.com

723 pointsthunderbong242 comments

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.

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

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.

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?

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.

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

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.

Before it is too late.

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

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.

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

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

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

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

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/

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.

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.

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%}

> 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?

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

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

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

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

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

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

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

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.

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

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?

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

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.

So stick with something like serif or sans-serif.

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

Yep. Test on your parents or elder colleagues.

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

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

A comparison using danluu's website:

Default: https://postimg.cc/k2Zwffms

With the 100 bytes version: https://postimg.cc/645d9vKT

Thanks for taking a minute to do this, it gives a nice side-by-side for a real-world example. What a great improvement.

Line spacing is atrocious

That line spacing is obnoxiously big tho

Yeah, I agree the line spacing is far too much. Butterick's Practical Typography recommends 1.2 to 1.45: https://practicaltypography.com/line-spacing.html

Really the only reason to use a line spacing of 2 is if you are printing it and then editing the text with a pen. So... maybe in a print stylesheet in a very specific situation? But never on the web, IMHO.

I think the line spacing is "comfy". Approved. For me.

Yeah when I saw 2em padding and 1.75 line height in the css I thought "too big". I think 1em padding and 1.5 line-height are a bit better for general defaults.

It often can look better to have more whitespace, but it lowers information density. It depends on the situation.

I honestly prefer the default version. Less scrolling to do.

But more horizontal eye movement, which at least I find unpleasant

Try reading his site on a 21:9 and your eyes start bleeding.

well, browser windows can be resized to take half one's screen...

That's the wrong metric. Scrolling is less straining than moving eyes (or even the head in this case).

People complain a lot about "wasted screen estate" but the first version that "doesn't waste blank space" is completely unreadable to me on desktop, I want to stop reading after the first line.

That website really grinds my gears. He's the equivalent of an HN influencer I guess, because I seem to come across him every three days. Like the Stratecherry guy. And it's so naff. It's clearly designed to look like that on purpose and it's kind of a thumbing-your-nose at your audience thing. "My words are so important that you can get fucked if you want max-width". It REALLY annoys me way more than it should. After all, it's just another dude on the internet.

Can't help but think that both would look a lot better w/ text-align: justify on paragraphs.

The original page seems to be gone from the web, but here's an archive of it: http://web.archive.org/web/20210318102514/https://jrl.ninja/.... That shows the described CSS in practice.

It also references this previous discussion: https://news.ycombinator.com/item?id=19607169

there's a lot of studies about optimal typography for readability in terms of fonts and characters per line etc.

Having dead space on the side is kind of a different problem, more on the lines of the appropriate default settings of the application (or system)

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.

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.

Have you ever seen a long text on a billboard?

I guess not.

I'm pretty sure you misunderstood what I wrote.

> there’s a difference between number of characters and width

Billboards use large letters to fill the space, but normally they would be readable on a business card.

Fair enough. But your point requires discussing nonetheless.

You seem to suggest that fontsize should adapt to width to fill the space (seemingly to a billboard, as per your example).

If the billboard technique was used on the web, I guess we might not have more than a handful of lines on screen (on a 16:10 or so). That would disable skimming on long texts and even more, barely display a single paragraph (that's a gut guessing).

Plus, and more importantly, the distance to the screen is such that a font too big is not more readable. There's a tradeoff to he found for the fontsize that not only has to take into account the size of the screen but also the distance of the reader from the medium.

Or so I assume.

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”.

That's a great point. I gave it some thought and I think it's a matter of the relative distance from the start to the end from your perspective.

Billboards are meant to be read from far away. So even though the physical width is large, we perceive it to be much smaller. Maybe similar to a big banner on a Desktop monitor.

Imagine reading the billboard at a much closer distance, say 2 meter. You'll have to move your neck from left to right. It doesn't matter how big or small the font size is.

As a subjective test, I lowered the font size of a random article to see if I would have trouble reading it. Other than having to focus more to make out the text, I don't have problems reading the entire paragraph. On the other hand, removing the max width made it more uncomfortable to read.

So the distance from where the text will be viewed from is an important factor to take into account. Phones, Desktops & Banners all are viewed from different distances.

It seems clear from context they are talking about maximum width *in character*.

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.

Why do you think constraining the reading width of a text column means it won't change as you resize your browser?

Don't confuse your preferences with how far apart human eyes are. Your preference isn't relevant here.

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.

The internet must be very frustrating for you.

as a user of 56" 4K I vehemently disagree

Newspapers use columns for the same reason, to not get too wide lines. Unfortunately I don't think I've ever seen a site use columns, even though CSS supports it.

https://developer.mozilla.org/en-US/docs/Web/CSS/columns

I think that shows that different mediums need different solutions and also different content.

Newspapers don't have scrollbars. So they use columns.

This may be why phone-apps are so popular, their content is designed to be viewed only through the app.

CSS columns is cool, I didn't know about it. But not sure where I would use it either.

Personally I find column-style layout to be more difficult on the web. Though probably just due to lack of familiarity.

As one example, the "Golf with your Friends" subreddit always throws me for a loop due to its use of columns. I have no idea how to read it!

https://old.reddit.com/r/GWYF/

Note this example will only work on a widescreen desktop browser.

Just a quick note: It works on none widescreen desktop browsers as well if you zoom out far enough. Or at least it does on my 14" with FF 106

Columns that you have to scroll like that is not user friendly, their height needs to be limited to less than the window height.

Columns like those are a bit awkward when combined with scrolling long blocks of text. When you reach the bottom of one column, do you need to scroll back up to get to the top of the next? Or do you have the column fit the height of the screen and have some sort of horizontal scrolling for as many columns as it takes.

Maybe they could do it the old-fashioned way and scroll the columns horizontally.

https://en.wikipedia.org/wiki/Dead_Sea_Scrolls#/media/File:G...

Why not limit the height of the columns so they fit on the screen, and wrap around to new columns lower down? So when you reach the end of the rightmost column, you scroll down the page and continue reading at the leftmost column.

I've experimented with this style on Wikipedia, with separate columns under each headline. It usually works well.

Yes, they've been around forever, but browsers have never properly supported column breaks and orphan control. This tends to make any content with CSS columns unsightly, which is why no one uses them.

One browser did have amazing column break/orphan control: the IE11/Spartan (Edge Classic) renderer. It's amazing/sad how much the web regressed in CSS multi-column support rather than improved since then.

(Some group or groups at Microsoft during Windows 8 development must have passionately loved multi-column text and proper "newspaper inspired" typography and wanted to see it succeed, and they did not seem to survive the backlash against Windows 8, sadly.)

I've used it on my personal blog for many years at this point, because it is my personal blog and I can be weird with it, including using horizontal scrolling by default. https://blog.worldmaker.net

I really love multi-column, and appreciate horizontal scrolling. I've got an ultrawide screen, and I love that my site is one of the very few that makes an interesting use of a screen that wide. (There are articles on my blog you can easily read with no scrolling at all.)

I've gotten so many complaints over the years about my use of multi-column, including here on HN. It seems a very polarizing thing, even as I wish it were more common. The one time one of my posts trended it got a lot of hate about my blog CSS. That was a revision ago, though. I've made a bunch of adjustments to it since then, because I did read all of them, and tried to find some tweaks (including a few bits of JS) to smooth the experience a bit.

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.

Text in books tends to take the full width of the page (minus margins ofc) doesn't it? Why should you waste most of the horizontal space on my monitor then?

Do you have trouble reading HN in a maximized browser window on a wide screen monitor? I don't.

> Do you have trouble reading HN in a maximized browser window on a wide screen monitor

HN comments happen to be capped at 1215px (which I find too long on big comments), and comments usually have line breaks in between that make them not reach the max width.

> Text in books tends to take the full width of the page

Yes. Not the full width of both pages at the same time. Pages on a book have a vertical format, not horizontal. I guess columns would be somewhat ok on the web, but it's not really comfortable either... as we can scroll.

Coverage of the screen with text is the wrong metric regarding legibility.

I don't know what the right metric is but i simply can't read those sites that present you with a mobile-like layout with two paragraphs per screen on a 24" monitor.

If the text is too small I can hit Cmd - Plus but with those i have no recourse.

It's not mobile-like, it's just legible. Just because you have a 24" monitor doesn't mean the text should take all the width, that's terrible.

Two of them

It seems like I'm permanently in some sort of dystopian nightmare 'unpopular opinion' group where wasting two thirds of my monitors useful space is the right way about doing things.

I have monitors either side of my primary in portrait mode specifically for looking at a bunch of code/text and it still wastes at least half of the useful display area.

https://i.imgur.com/Qk7fM35.png

If I wanted this, I'd press the reader button in Firefox or squish my browser window. Why? Shakes fist at sky

I think this is due to the desire to fall in the approx 40-75 characters per line that are considered ideal (numbers vary depending on the source of the study but broadly fit this definition) for users to read. It is also why some prefer double-columns in academic papers, because each 'column' has closer to ideal lines, rather than have wide margins on the page.

Of course, this looks like wasted space when you have a landscape-oriented monitor... I personally very rarely maximize my browser so that I read in more of a portrait-style mode, regardless of the orientation of my display.

But, you're the one wasting it, right? You have a huge monitor with one window open. I use a WM and very rarely have one window on a whole screen, because that would be a waste of screen.

If that text was full width along your screen you'd be wasting vertical screen space instead. Will you ask them to write more to fill your screen up?

Well, OK sure. I'm not the most effective communicator but in the end I'm still genuinely 'not getting it' though.

In my image you can see that either portrait or landscape orientation, there is considerable 'dead' area (edit: either side), by default, even if the text was many paragraphs long.

The usual solution is to smash "ctrl numpad +" four times til things fit perfectly at (usually) 150%. It's actually uncanny how I'll do this without even thinking while browsing.

If resizing the browser is an acceptable solution then not setting the max-width already works. Setting the max-width only makes it worse for people who want the space to be filled regardless of their browser size.

There’s no easy way to organize lots of windows, and there is no way your approach would work nice with all web apps, sites and articles in different tabs of the same window.

What would be nice is a special element <viewport sizeable style=“width:n”> so a user could either enjoy a default width or drag one side of it to resize its margin at both sides, without resizing a window. Or, instead of an element it could be purely a browser viewport-resize feature, like they do for textareas.

Meta: it’s really frustrating that every time an argument about web ui starts, nobody thinks of how to actually make it better and just holds on some particular use case or preference.

> There’s no easy way to organize lots of windows

Sure there is: Tiling window managers. Available for every desktop OS in some form or another. I assume people who are power users enough to have large, multiple monitors can help themselves.

We're in the same group if that makes you feel any better. BTW, since you mentioned reader view in Firefox, here's the userContent.css that I've been using for the past few years:

    @-moz-document url-prefix("about:reader") {
        .container{
            max-width:100% !important;
        }
        .toolbar-container{
            display:none !important;
        }
    }

Make sure to set your preferred size/color first.

yep. I hate it. I've seen people say this is a result of studies but I've never been able to find the studies that claim this is better. It seems to have been stated in elements of typographic style and taken as truth http://webtypography.net/2.1.2

Well you must have not searched very hard if you didn't find studies, because it took me a grand total of 3 minutes: https://www.semanticscholar.org/paper/Optimal-Line-Length-in...

There are many citations that lead to other studies on the same topic.

Thanks.

I limit the width on my website because I find moving my eyes constantly from left to right annoying. For me it's harder to find the beginning of the next line if lines are very long.

Besides, the other half of my monitor is usually taken up by another window or two.

Because reading paragraphs of text with extremely long lines is really annoying. If the lines get too long it makes it hard to subconsciously find the next line when you scan back.

What's your solution? The only other option I can think of is multi-column newspaper style, but that's pretty fundamentally incompatible with the scrolling model of the web.

That's probably why you only see multi-column formats in page-based media like physical newspapers and PDF papers.

>What's your solution?

I don't need solutions to problems I don't have.

If people find it hard to read long lines on my website they can make their browser window thinner. I don't feel compelled to impose my reading abilities (or lack thereof) on them.

that's pretty fundamentally incompatible with the scrolling model of the web

It isn’t though. If browsers supported overflowing text into a “next” container (defined via hierarchy, selectors, whatever), designers could just design repeating pages of layouts like they usually do with full-height marketing stripes.

I'm not sure what you mean. The only way I can think it would feasibly work is if you have multiple columns with the same content, but offset by the window height. That wouldn't require any container linking and would allow you to scroll normally, but I also think it would be pretty weird.

Something like this: https://jsfiddle.net/n87hkdf4/

I think anything else would require tedious scrolling up and down all the time or worse - horizontal scrolling!

That offset would cut lines in half most of the times. Here is a visual diagram of one of examples of such layout:

  0vh
    margin
    column 1     column 2
    text         text
    text         text
    margin
  100vh
    margin
    column 3     …
    …
  200vh

Content flows naturally through column 1, 2, 3 and so on. No lines are cut in half horizontally (in a sense of overflow-y). When a window height resizes, content reflows accordingly - no scrolling required to read a full page at any window height.

Even worse when the text has things like code examples that aren't completely readable without horizontal scrolling.

For real. I have a dozen style overrides for websites that are just variations of `max-width: none !important` to make them actually usable.

Why? Because so many users just run the browser in full screen mode because they don’t how or simply can’t be bothered to manage windows, not because they actually want their screen filled edge to edge with text.

So because long lines are hard to read, line length is clamped to at least provide a decent experience to all those users.

I use a browser extension called Window Resizer where I create 2 resolution profiles (1440x1080 and 1600x1080) and then use CTRL+1 and CTRL+2 keyboard shortcuts to alternate between them.

Thank you! This is a particularly annoying design trend. I regularly hunt in the dev console for the offending max-width element and nerf it with extreme prejudice.

Shot in the semi-dark: there was a blog post posted here —- I haven’t been able to find it with HN search —- some years ago that started from scartch/browser-defaults and proceeded in like 5 steps to some nice minimal defaults. Not exactly a plain reset; there were some opinionated choices. Step one was something like the parent article. Anyone have an idea what this was, or have some similar recommendations?

I had to through my saved favorites, but I knew what you were talking about. From 5(!) years ago:

https://jgthms.com/web-design-in-4-minutes/

Amazing! Thanks :)

Glad to help

Instantly thought of the same ressource. Still something I recommend regularly to people.

Great, with one nitpick: "Black text on a white background can be harsh on the eyes. Opting for a softer shade of black for body text"

Why are people so afraid of black text on white background?! In the end, after all the colors and custom fonts the website has gray text with poor readability which instantly fails WCAG AAA. Had he kept #555 (which is still not ideal), the author would have had a WCAG AAA-compliant design with minimal effort.

Yup. My eyes started getting tired exactly at the point when the text became gray.

Well done step by step presentation.

But I still prefer how the page looked initially, without all the styles.

Perhaps this or this? Excuse the language.

[1] http://motherfuckingwebsite.com/

[2] http://bettermotherfuckingwebsite.com/

And this: https://watercss.kognise.dev/

What is wrong with browser default styling, and why do browsers ship with something that is wrong?

Browsers ship with defaults that are now 20 years old - there was a cool post here about 8px body padding a while ago.

It's not "wrong" it's legacy.

Why is it legacy though? Shouldn't browsers be free to change it?

Web browsers have a hard constraint of backwards compatibility. Eventually we could see some CSS directive which enables "modern" default styling, both for mobile and desktop, but it would be opt-in so that existing sites which rely on defaults do not break.

I bet if they did an experiment where they changed the default styles a bit very very few would complain. Most people visiting tiktok or whatever wouldn't even notice.

Most people visiting tiktok don't do it in their browser

And the people visiting it in a browser wouldn't notice.

Think for a moment. This has nothing to do with tiktok. This has to do with your favorite personal website which hasn't been updated since 2001.

And any change in default styling would be immediately noticed. Pages suddenly centered, or half the width? Increased padding?

And "most people wouldn't notice" is a harmful mentality in web design which allows minorities to suffer. Most people aren't blind, either. Should we not worry about them when designing websites?

If you change them, almost every website will look bad in your browser because most rely on some of these defaults.

It would be nice if you could choose between defaults in the html tag <html style-default="2022">

Without max-width the content will stretch across your entire screen, which isn’t great for readability. It’s faster to read when you don’t have to look across your entire monitor and move your neck/head.

Default styling looks terrible and is hard to read. Humans are good at reading columns at around roughly 80 characters, while browsers default to filling the whole width of the screen with text, resulting in a column that's hundreds of characters wide. Text also gets easier to read when more spaced out; the default line height makes the text too close together.

Browsers still ship the bad defaults because changing defaults would break existing websites.

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

There is a huge amount of research devoted to this. Of course personal preferences exist, but there are physical constraints like the degree to which your eyes can move without turning your neck and other things. It’s somewhere between 60-120 I think, with 80 right in the sweet spot.

It's actually smaller than 80 characters.

There has been over a century of research into this. It's why newspapers print their stories in columns, instead of across the entire page, which would be easier.

Newspapers have been using columns to break up long lines for well over a century.

It's hard to find to the next line, if they are too long.

And it's annoying to have to find the next line every few words if the lines are too short.

Newspaper columns have always felt way too short for me. Most books have longer lines, and I much prefer that.

Just look at any physical book. I also wonder how many people would read Wikipedia more if they serve the mobile version on desktop.

Same, I lose my place every time moving from the bottom of a column to the top of the next.

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.

Ancient-enough greek includes examples of left-to-right, right-to-left, and alternating line orientation, and may be what you're thinking of.

https://en.wikipedia.org/wiki/Boustrophedon

Here's a literature review on the topic: https://www.researchgate.net/publication/234578707_Optimal_L.... The article content is inaccessible, but from the abstract:

> Research has led to recommendations that line length should not exceed about 70 characters per line. The reason behind this finding is that both very short and very long lines slow down reading by interrupting the normal pattern of eye movements and movements throughout the text.

And a document on the topic from the US government: https://www.usability.gov/get-involved/blog/2006/08/line-len...

> The best available research suggests that users will read fastest if the line lengths are longer (up to 10 inches). If the line lengths are too short (e.g., two and a half inch columns), the line length probably will impede rapid reading. Users tend to prefer lines that are relatively short (about four inches).

Wikipedia cites a whole bunch of studies on the topic (https://en.wikipedia.org/wiki/Line_length):

> Legibility research specific to digital text has shown that, like with printed text, line length can affect reading speed. If lines are too long it is difficult for the reader to quickly return to the start of the next line (saccade), whereas if lines are too short more scrolling or paging will be required. [...] One proposal advanced that, in order for on-screen text to have the best compromise between reading speed and comprehension, about 55 cpl should be used.[11] On the other hand, there have been studies indicating that digital text at 100 cpl can be read faster than text with lines of 25 characters, while retaining the same level of comprehension.

There's a decent amount of variance, but common across all research in this area is that many hundreds of characters per line is never found to be the optimal length of a text column.

> (up to 10 inches)

here on HN in my 16" MBP, 10 inches is ~230 characters

The context from the linked article, which dates to 2006:

> Her results showed that passages formatted in the longest line length (95 characters per line or 10 inches) resulted in the fastest reading speed.

> Humans are good at reading columns at around roughly 80 characters

Do you have some evidence backing this up? Thanks.

This is the sort of thing you can Google, because it is extremely common advice. A few of the top hits:

https://www.fonts.com/content/learning/fontology/level-2/tex...

https://pimpmytype.com/line-length-line-height/

https://material.io/design/typography/understanding-typograp... (see under Line Length)

I don't have any studies at hand, but I think it's been pretty well established.

I collected a few links here: https://news.ycombinator.com/item?id=32972710

80 is somewhat arbitrary, I could've said 50 or 70 or even 100, but it's in the ballpark of what studies find. Studies never find 400 characters per line to be optimal.

I much prefer the default styling other than that the margins are nearly nonexistent. Any time I come across a site that uses mostly default styling (such as some academic webpages from the 90s), I always think to myself "wow, this is pleasant to read."

> Text also gets easier to read when more spaced out; the default line height makes the text too close together.

The opposite is easily true in my experience. Making text large, using ample line height, and even greater spacing between paragraphs, makes for text that is more readable but makes the experience of reading much worse. This is of course entirely subjective unless someone comes up with measurable evidence, like a study on the sentiment of users.

Something tells me that designers have been taking principles that are appropriate to hero page sections, advertisements, magazine covers and such, and applying them inappropriately to bodies of prose. Larger text with spacing and huge margins (or smaller max width) helps the reading impaired, but I don't really buy that people actually prefer it.

I feel that large text with large line heights makes small pieces of text (maybe a couple paragraphs maximum) easier to read, but makes comprehension of a larger piece of text more difficult. It makes you loose overview of the larger structure.

It's very well possible that it's all different for different people, but I much prefer having a larger piece of text in view; smaller font, smaller margins and smaller line height all help with that. Longer lines of text too. All within reason, of course.

You know how books for children have ridiculously large fonts and spacing, in stark contrast with (most) books for grown ups? It seems there is a trend now to make websites look like the books I had when I was just a little kid. I don't like it.

I was just thinking; maybe large font size, wide margins, and bigger line height may serve to inflate "engagement" because they make it more difficult for a user to be able to glance at the majority of the page and get a sense of whether it's worth reading. If scrolling and getting a big picture view of an article takes some effort, users may be more likely to either read through the content or scroll slowly. Either way, it's a win for the designers because whatever tracker being employed will provide some fancy charts to convince the suits and ties that their work "increased engagement." It may also get users to look at more ads. All of which will certainly be pitched under the idea that it's accessible.

I really hate this if that's true, because the net effect does seem to be that I have to spend more time on a page to determine if the content is garbage or not. With physical books, you could flip through pages and catch things you're interested in by glancing over large areas. The modern web, for whatever reason, is doing quite a bit to prevent that from being possible on our screens without hacking our own browsers to fix the mess.

> Humans are good at reading columns at around roughly 80 characters

Depends. The reason why it may seem better to have narrow column is so you can skip ahead more easily and thus read faster (reason why newspaper divide an article into columns). Otherwise it doesn't make difference.

To me it's absurd that this day the trend is to have wide screen displays (16:9 but nowadays even 21:9 is common) and then all the text is vertical in a column that makes it impossible to read.

I prefer to give the use a choice: after all if the user prefers narrow text all he has to do is to take the mouse and resize the browser window at the width that he likes! But doing the opposite is not possible (at least without an extension that modifies CSS), and thus you have to keep scrolling something that otherwise would have fitted in a single screen.

The problem with your preferred solution is that it requires changing the window width for each web page. My web IRC client requires a somewhat wide window, since it has a sidebars of channels on the left and a sidebar of users on the right, both of which provide utility and I don't want to hide. Reddit is unreadable on narrow screens. But blogs would need an 80 column window (I.e 1/4 the width of the screen) to be comfortable, unless the blog has some sidebar which makes that too narrow. I don't know about you, but I switch between tabs frequently, and I'm extremely happy that I don't have to resize my browser for every tab switch.

I keep my browser window maximised (usually on a secondary screen). I like that all web pages are more or less readable in that configuration.

> Humans are good at reading columns at around roughly 80 characters

Are they, or is this a legacy of 80x25 text mode terminals?

Yes, they are. Links to studies here: https://news.ycombinator.com/item?id=32972710

(Also, couldn't you have read the answers to one of the many other comments which ask the exact same thing?)

They don't. They just mention the studies. I was wondering if it's linked to legacy terminals because ...

... i don't know what kind of books you read, but all the books I read have as much text as will fit on the width of the page.

The only place i've seen thin columns was in technical books with introductory material. Never in fiction or advanced technical books.

I don't know what books you've read, but the ones I have read don't have pages which are 0.6 meters wide like my monitor. And paper newspapers, which come the closest of any medium I have used, use many columns per page to avoid ridiculous column widths. We can debate whether the optimal column width is closer to 50 characters or closer to 150 characters, but at almost 400 characters we're so far outside of what studies find comfortable that the discussion just becomes silly, IMO.

Nothing is explicitly wrong, but the spacing on lists and headers can look kind of silly. For instance, consider in Google Docs - the headers stack nicely, look clean, and lists have perfect indentation / spacing

Those changes pretty much cover all this does, and it doesn't do a great job IMO. I'd let them get away with "look slightly better than defaults nearly everywhere"

Historical reasons. Default browser styling still carry a lot of heritage from back when screens were 640x480 and you had to squeeze as many lines as possible onto the 14" screen.

Of course, if you change the default CSS now that 30 years of HTML have been written to rely on these defaults, almost every website will break.

I doubt this. Almost every website overrides all of the relevant CSS attributes, because the default is just atrocious. Changing the default won't impact them.

Anyway, the browsers still can update the CSS and add a "reverse read mode" button that changes it back.

They override the CSS attributes that don't fit what they are doing now, but changing the defaults would introduce new attributes, which may not presently be overridden.

The modern approach is to do a universal rest:

  *, *:before, *:after {
    all: unset;
    display: revert;
    box-sizing: border-box;
  }

Would that actually work as a safeguard against this? What you're reverting and unsetting to is the very defaults we're talking about changing.

As I understand it, it won't protect you. What will protect is actually setting the value (and most sites do that, at least for those few commonly changed ones with bad defaults).

That's true, but there could theoretically be more then one default. I'm not arguing in favour of it, just pointing out the possibility. it would be pretty simple to create a <html styling="modern"> so that it's opt-in.

I personally just don't see the point. There are a lot of bare bone frameworks around and if you're doing a static website (which would likely be the only type to benefit from that)... The <10 kilobytes gzipped css won't matter for the most part.

I would still appreciate an opt-in "modern" default that browser developers should feel free to change going forward. For me, it's not about minimizing download size; it's about maintaining a proper division between content and functionality, which are what I as an author and developer provide, and appearance, which should be up to the user agent, to best meet the user's needs and preferences. Sure, since I work on accessibility and am visually impaired myself, my perspective on this is skewed. Still, there are clearly others who wish the browser would have more sensible defaults.

It's probably hard to get everyone to agree on the defaults, especially the width / line-length of content. I think it makes sense to default to no width constraint, zero padding rather than picking something arbitrary. I personally start with 1em padding whereas the author seems to prefer 2em, (or 1.5, or 2ch which is roughly 1em)

Browsers used to default to adding margin/padding automatically to documents (Quirks Mode), but modern html includes a doctype to use "Standards Mode" which is more sane.

At the same time it would be nice to default to sans-serif typeface and line-height around 1.5 but it starts getting arbitrary very quickly and it's nice to build on something that doesn't change over time.

It will (maybe) matter in five years when standards have changed and that bare bones framework you grabbed isn't maintained.

IMHO it's a fairly big miss that default styling is bad, we're missing basic controls like drag & drop, and there's no native layouts like heros or hamburger menus and so on. A lot of cumulative effort has gone into reimplementing these things thousands of times.

Allow me to go off on a tangent and say:

> 30 years of HTML

holy fucking shit

> What is wrong with browser default styling, and why do browsers ship with something that is wrong?

The problem with browser default styling is that there should be another level: user default styling. I.e., the styling as chosen by the user.

I think this is a valid point. For example, I have always wondered why default browser styles don't at least adjust to the OS's theme - be it Metro, Material, Qt, Gtk, whatever. It would solve a lot of issues for bare-bones websites, while still allowing full configurability for websites via override. And if we really cannot have nice things because of backwards compatibility, make OS integration optional via <meta> tag etc.

Why does every website have to reinvent the wheel?

I've got a screen that is much wider than it is tall, this throws away so much of it. It's as bad as Facebook, where the stuff you want to see is a band about 1/4 the area of the screen.

In theory sites could optimize for wide screens by adding columns, but 1) its a very small audience 2) most content is not suitable for that (how would you scroll a feed that spans 3 columns?)

https://www.nasm.us/xdoc/2.15.05/html/nasmdoc2.html

The NASM website is an example of this. Personally, I don't like it and would prefer a single column.

That has a small number of long columns down the entire page, which doesn't give any of the benefits of having columns. Actually, it's only worse in terms of readability, as a big factor is how well your brain can spatialize the location of what you're reading for backwards jumps or subconscious memory palace stuff. Here that's complicated by the mental overhead of "I'm halfway down the page, but the page is really twice as long as it is, so that's actually 1/4 of the way through."

Proper column layout involves limiting columns to screen height, probably by paginating. Then the reader can perceive the text as a tree of Page > Column > Paragraph > Row. Tangentially, I think there are studies positing that this, helped by the notion of physical pages in space, is what's behind the readability advantage of books.

Alternative to pagination is scroll-direction: horizontal. Now the experience is even closer to reading a book. And to Windows 8! IMO there's a shortage of novelty sites with true (non-slideshow or carousel) horizontal scrolling.

This whole design pattern of wasting screen real estate in desktop browsers drives me crazy. If I want narrow text I'll make my browser window narrow.

On mobile, so many times it ends up creating a bad UX, but I will say that it does make more sense there where you can't change your browser width.

browsers have been working on multiple column text for a while now[0], so by employing a container/media query, you could have multiple columns for wide screens and content containers. i experimented with it a couple years ago and found quirks (which i can't remember offhand) that made it not quite ready for primetime then.

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

Hope you don't mind the self-promo: Here's a GH project of mine which attempts to provide styles for popular websites to remove large paddings and max-widths: https://github.com/phil294/density-userstyle

Quick example of how it looks: https://jsfiddle.net/n8Lqypb7/

Is there some way to view the result full screen, namely for viewing on mobile?

result: https://jsfiddle.net/n8Lqypb7/show

Original page: http://web.archive.org/web/20210318102514/https://jrl.ninja/...

And it sets a text color, but no background color, ensuring it will fail on most non-standard color schemes.

Not really "everywhere".

“max-width: 38rem it appears that the default font size for most browsers is 16px, so 38rem is 608px. supporting 600px displays at a minimum seems reasonable.”

I’m not an expert in CSS, but I don’t think this makes sense. Why base the width on the default font size when you know you’re aiming for 600px? Just write 600px. Also that’s a max width, so what makes this support 600px screens at a minimum?

Would have been nice to have some examples showing it in action.

> it appears that the default font size for most browsers is 16px, so 38rem is 608px. supporting 600px displays at a minimum seems reasonable.

I dont get the logic here. If the goal is 600px, why are we using rem?

If the units don't match, changing the user's base font size will only affect one of them. Part of why we stopped using rem.

Why are we even setting a font-size on root of we want to base the width on the "default?"

Why are we even setting a max-width? Just split text into columns to maintain a legible line length.

Does this actually look great to people? I can't stand forced line lengths and these ones feel way too short for the text size. This seems that it looks great for mobile, not desktops.

I'd add

    :root {
      color-scheme: light dark;
    }

This makes the browser choose dark colors for those that prefer them, including form widgets etc...

Do you still have to explicitly add CSS to do something appropriate for the user's dark mode setting? I'd rather not specify any colors at all and just let the browser use system defaults, but last time I checked, that used black-on-white even in dark mode.

That would introduce yet another set of defaults that developers would then need to inevitably override.

I'd accept that. The user-agent knows better than I do what the user needs. Especially if the user is low-vision, color-sensitive, or whatever.

It would break legacy websites that never considered dark mode.

Yes. Sadly, iOS Safari defaults to dark blue links on a dark background for dark mode.

You do, via `color-scheme` or media query

Also restated here: https://www.swyx.io/css-100-bytes

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.

I will never understand inflated line height. It doesn’t make Text more legible.