We could also all go back to 800x600 monitors. That way, no one would have to be subjected to writing the 10 lines of css to make text heavy sites more readable ;)
No, because then you'd have a short line of text that takes up a huge amount of space.
Your lines of text on the screen should never be much wider than your hand at arm's length, ever, for any reason. Not even if it's an example of a one-liner in bash - wrap that line to make it easier to read.
Don't believe me? Angrily click <reply> on this post to tell me what an idiot I am, start to type your reply, and then hold your hand up palm out at arm's length to the screen so it covers up the text box you're typing in.
Decades of research show that long line lengths cause people to read more slowly, although it is of course possible that you process text differently than most.
"Ridiculously" short is another matter, but by my count, "significantly wider than your hand at arm's length" means well above 20 words per line.
When writing outside of a terminal, I wrap single-line shell commands with backslashes and space indentation. The breaks are at logical clauses, as if writing a conventional programming language. I find this much more readable than the alternatives. Often my terminal will also get it this way, from a copy-paste.
If I have to do it twice I stick it in a proper script, with some comments, so I remember what it all does next time I go to do it. I do this particularly for stuff like complex ffmpeg filter chains where I need to do a lot of stuff to a video file. By simply running the bash script, at some later date I can get it to remind me what it does, and suitably mangle the video file.
Then, later on, often weeks later, I use command history to scroll back through everything I've typed until I find something that looks vaguely like what I originally typed, or I don't find it and figure it all out from scratch again, having totally forgotten about the bash script I wrote.
Yeah, but how many times do you see a one-liner that's in a nice little boxout, but there's a scrollbar and you need to slide it backwards and forwards to read the whole thing?
> we would just keep our browser windows at a smaller size
I wouldn't keep a browser at all, I would just read them in Emacs all the time or from the command line. I would also be able to use my preferred visual theme with the entire web, and not have to look at some really nasty web designs from time to time, albeit I do agree that as a game dev (long time ago) I do like when I see pretty graphic design.
However, I am not sure how my bank will do and all the other web services in just plain text. Perhaps it is possible, perhaps not?
I think the trick is to avoid the hr tag and to center the pages. I run a no css website https://www.pilledtexts.com/ and just have the readable content in .txt files where I can add a max width.
Which is pretty bad on mobile, because the lines wrap before the hard line endings, making a long-line/short-line repeating cadence which I find really difficult to read.
Unironically, somewhere between 1080 and 2K scaling is probably all anyone will ever need since humans can't focus on more real estate than that. The higher-res monitors all scale the UI to that.
What do you mean? It perfectly adapts to any browser width; if you want to resize it, just resize the browser window. It's perfectly readable on both a 4k screen and a small phone.
The alternative is the "accessible" mush which is common nowadays - no matter how big your screen is, the content is compressed together into a small strip in the middle of the screen, almost like a phone.
No thanks, I'll take fullwidth content anytime over that....
Making text wider is lazy. At some point, you'll need to break it into columns so that the text is readable. Perhaps on super wide screens, three or four columns (akin to a two column book that's wide open or a newspaper) may even be more preferable.
Otherwise, the other option is to scale up thr text size, but that takes up precious vertical space on wide screens, and doesn't increase information density.
Obviously, text columns may only make sense it certain scenarios - a minimum amount of text might be required to justify a second column as opposed to just limiting the width of the first column.
But why does that matter for reading it? It's just reading left to right either way. The submission was fine for me to read, and so is HN which has pretty thin margins by modern standards.
Ah, never mind. I understood it the wrong way around. So you have a big resolution and want shorter lines.
Maybe use reader mode which applies some css. I still like this for content centric websites. My favorite blog also works like this for years
"No HTML Club" stands as the only logical step forward in this evolution. Browsers are perfectly capable of rendering plaintext, what could we ever need those pesky "tags" for?
(Yes, I know technically codepage isn't ASCII. I guess you could use box drawing extension to draw foreign language character if you wanted. Or maybe just SVG of the text)
please not codepages. finally being able to write multiple languages in a single document, which is something i need to do frequently, really makes a difference. codepages were a nightmare compared to the simplicity that unicode is in this aspect.
These make me feel weird. On one hand, I love the way justified way it takes me back to old READMEs, GameFAQs, etc. but on the other all accessibility is thrown out the window.
Clicking on links is a bad idea, links are a bad idea. Besides from the horrendous potential for wasting your time you expose your reader to all kinds of dangers. Links could be changed in ways you don't control. They could point at offensive content, thinks you are not suppose to know, illegal things, phishing websites, hackers and much more you are better of not knowing about.
just the other day i logged into a MUD which presented me with an interactive world with a graphical map in color. the same MUD has a built-in http server so it can display the same information with the interactive and feature rich, yet compact telnet interface, as well as the round-trip heavy and verbose http/html interface.
It is considered CSS [1], which makes sense to me as this relates to styling. What has never made sense in my mind is to have completely unstyled pages rendered with microscopic fonts on smartphones. Doing so for old sites that, at the beginning of the mobile revolution, assumed on their CSS sheets 1024px wide screens is reasonable (though still debatable). Not so for CSS-free pages, whether they were authored in 1991 or in 2023.
I'm sorry if I got carried away, I wasn't replying to you in this last part :) For the record, I would also make this exception, though it would be neat to be able to select those without even the meta viewport tag.
No problem, really. Thanks for the correction. This is indeed css. I must have automatically associated meta tags to non css data only. And I totally agree with you concerning the microscopic font and the meta tag.
I don't understand why it has to be added to every single page. Is there a reason this is not implemented as a default browser behaviour for devices where it matters (i.e. mobile phones)?
Counterargument: sane users expect consistent presentation across all browsers and viewport dimensions.
A CSS reset overrides the user-agent stylesheet and the rest of the CSS determines the final style. This is the best practice. If you don't like web pages, then don't use them.
The final form of this club would be to settle on their favorite serialization format bit banged into their nervous system so they can be one with the matrix. /s
This is still subjective. Some users would prefer to see consistency across all sites they visit rather that consistency on the same site across all browsers.
When every site uses it's own reset there's no consistency while in the same browser, which is way more common for most users that don't have a separate browser for every site they visit.
This is one of the main use cases for reader mode for me—I already have an ad blocker to remove noise, reader mode means I don't have to deal with whatever each random site's designer thought would be the most readable thing, I can standardize all my reading in a format that works for me.
I'd rather look at this club as some sort of 'code golf' than take it seriously as a manifesto. Actually, even as a manifesto their point is valid, as a form of minimalist art. I consider the web as to be a canvas for many artists too. You don't need to agree to admire their work (e.g. dadaism is not frowned upon today)
Ok if this is the serious intent (minimalism) then they probably want SGML, not HTML. They would also not want this delivered using the seven layer burrito that is the OSI model.
I consider that the browser's obligation. If I'm not specifying any font or background color, I cannot be responsible to add special media queries because someone chose a dark theme.
Thank you for bringing this up. I had been looking for an “easy” way to enable a Dark Mode on my website without overriding user-configured default colors and this seems to do it pretty well.
My page uses a minimalistic CSS and only changes the colors for syntax highlighting -- which is now slightly broken in the dark mode but probably still an improvement over the white background for those people who want the dark mode :)
My current solution is to switch the syntax highlighting to monochrome which should work fine for both modes. I love the colorful syntax highlighting, though. So maybe I will revisit this later to find out if I can do something along the lines of what you suggest.
One problem though is that the default link colors can be unreadable in dark mode. That's why I use @media (prefers-color-scheme: dark) to set a:link, a:visited, a:active colors.
i like the default (unstyled) link colors chrome uses, they seemingly do accessibility the best. on the other hand, safari's default link colors for dark mode are quite poor, e.g., a:link is dark blue, a:visited is purple
worth noting, browsers also treat the default dark mode background colors differently: chrome uses black, safari uses dark gray, and firefox uses dark navy
Maybe it's time to add some decent looking CSS defaults to browser, but only for websites without CSS includes. Page width, better fonts, maybe even mobile specific improvements could be added. Of course, I understand that would introduce incompatibility with old websites.
> Of course, I understand that would introduce incompatibility with old websites.
Why, though? If the website has no styling (we can exclude sites that use <font> and friends), the whole premise of HTML from very early on was that it only specifies content and the user agent controls formatting.
A "sane" default style would require "default" content coupled with a "default" viewing device. None of which exist. There can't be a one-size-fits-all solution.
In addition, content is more than just text - style, design, and layout are information, too.
I don't think anyone is suggesting that the new defaults be standardized. Each browser should pick defaults that make sense in the context they're used.
For completely unstyled sites, reader view should be the only view. What guidelines or rules should the other/s view/s be following? I say definitely not "nostalgic" view!
Dennis Ritchie's site is given as an example, but it's filled with ancient bgcolor and width HTML attributes, which are, how to put it, not better than CSS.
I wonder if what we're really lacking is just a decent set of default web fonts. The main modification I do when I kick out a basic HTML presentation of some data is throw in bootstrap so I can get a more comfortable font experience.
Shouldn't this be the default though? Why is the default bad?
True hackers only read the web directly as source files fetched by CUrl and opened in Nano anyway. Only normies need anything more than their minds to "parse" or "compile" source.
I have a bookshelf of books next to me and the only ones with even slightly similar spines are books in the same series, not to speak of the covers.
I opened a couple of text heavy ones and they all had different font choices and minor variations on page layout. Most of them had elaborate and unique chapter headings.
Book typesetting is a fascinating subject, I would recommend anyone who works with websites to look into the way typography influences the reader's subconscious. (Maybe we'd have less Helvetica spaffed all over the internet!)
> I would recommend anyone who works with websites to look into the way typography influences the reader's subconscious.
To me, paradoxically, it reached a point where my subconscious associates light or poor typography with serious material, and pretty web pages with empty ad-ridden content:
I used to be no CSS, but a little CSS can improve readability. There's nothing magical about the browser default fonts, margins, etc. And no max-width can be problematic.
You might want this to prevent the text size from changing when you rotate to landscape on mobile:
html {
-webkit-text-size-adjust: none;
text-size-adjust: none;
-moz-text-size-adjust: none;
}
That's an implementation detail of the user agent, not anything to do with the website.
The point is "your user agent should make this readable by default, somehow". If it chooses to do so by way of a CSS style sheet, that's the user agent's prerogative, but the standard doesn't care how it goes about rendering a style-free page.
You can say "should make this readable" and talk about "the standard", but in real life you've chosen this specific stylesheet (or its 2 or 3 variations), which effectively hasn't changed since the beginning of the Web, for 99.9% of the times someone looks at your webpage as your stylesheet because it's already preloaded as opposed to choosing a different stylesheet because it looks better or some other criteria.
I felt guilty at adding "<meta name="viewport" content="width=device-width, initial-scale=1.0">" so my no-CSS site wouldn't look on mobile like a website for ants.
I don't know the full history
and I discovered it in the early 2010s, but it's been around since at
least 1996 if the page content is to be trusted. I use a script to
scrape the site and filter by artists I care about.
https://watercss.kognise.dev/ I would argue classless css is the way to go, you just include a single css file, then write your html without touching any css anymore, all related tags in html are inherently css-ed for you. a nice trade off for me sometimes.
Why in the holy hell can we not just PICK THIS FOR OURSELVES?
This is the thing, right? Perhaps we could shoe-horn this in behind the ADA or something. Require every website to provide a "pocket" or whatever mode.
Books have mostly plain text style. No javascript, no cookie consent, no hover bars, no broken scrolling, no light gray text on white background, no crooked google fonts.
I’m sure Mozilla used to allow you to apply your own style sheets. I’m a huge fan of producing semantic markup and adding in a style sheet to do all the… styling.
> Bump that body copy to render close to 16px or more
also known as the default font size in browsers, don't you dare override the user's preferred font size for body copy, scale everything else in units of rem instead.
> don't you dare override the user's preferred font size for body copy
I’d bet you that 98+% of users don’t even know you can change the browser font size. For that overwhelming majority of users the size reported by their preferences and their actual preferences do not necessarily align. This is not a defence of setting smaller-than-16px font sizes, but it is a defence of setting larger sizes if testing shows it improves user experience.
I disagree, I field a lot of reasonable adjustment requests and a staggering number of people don't know about basic functionality. They are also not interested in them.
Don't scale everything in units of rem; we want "zoom text only" to continue to do what it says on the tin. Only scale the things that need to be text-sized.
Is there a reason for certain CSS frameworks like Tailwind to scale absolutely everything in units of rem and ignore px like the plague? Or is that just too far?
Incompetence, and thus obedience to a mistakenly-generalised caricature of "good practice", is my guess. I used to use em everywhere for exactly this reason. (The only reason I didn't shift to "rem everywhere", "flexbox everywhere", "web fonts everywhere", etc. was obedience to some different caricature of "good practice".)
I've never seen a CSS framework that's good. (Unless you count https://simplecss.org/, but that's of very narrow usefulness.) They're all made by the kinds of people who don't understand web technologies, and seek to hide them behind a layer of abstraction so they don't have to think about them any more. Unfortunately for them, there's a reason the web's how it is. Some of it's backwards-compatibility, but most of it is that a large group of very clever people failed to find a way to make it any simpler without breaking something important; and so, the framework people tend to break important things.
If you find yourself reaching for something like Tailwind or Bootstrap, just use inline style attributes. It's easier for everyone involved.
If you need any of those things, you should be using a proper stylesheet. Use <style scoped='scoped'> in the <body>, if you really must.
A crude "not that different from writing inline styles" classy framework just makes it harder to refactor your CSS in future, because it's all tucked away under incomprehensibly-named CSS classes, and there are otherwise-useless <div>s all through the HTML.
Everyone jumped on the only-use-rem train when mobile started dominating because it provides relative units that scale better rather than absolute pixels.
In practice it doesn't really mean much outside of blog-like text so when doing layouts it's more of just a standard everyone agrees on using everywhere because it's easier to stick to one for consistencies sake and it does the job. I don't think many frontend devs ever test zooming text using a browser anyway, their main concern is variations in screen sizes, basically device variation not manually zooming text. But I get the arguments to limit it to text.
I have mixed feelings about the second one. Yes, line width highly improves readability. But I think the grey font makes it more difficult to read. And I'm no fan of the increased font height, though that might be more personal.
I have never understood this. Black text on white backgrounds is fine at night, maybe you should stare at screens more or something? Or use something that adjusts brightness to ambient light, like most phones do now. I personally do not like all this low-contrast nonsense, clear and legible is the way to go.
I think the comfortability of contrast is subjective. I have several coworkers who use higher contrasts themes and swear by them, but my eyes start to hurt if I look at content that’s too high contrast. White text on black is by far the worst for me, but I know people who find that very readable.
Yet I have only ever heard of people complaining about it recently, when GUI designed started debasing itself by making everything web-based, and zoomers started demanding dark mode everywhere. Before that, and in my lifetime of computer nerditry dating back to the mid-90s (on self-luminescent CRTs!), I have never heard of people intentionally turning down the brightness or complaining about contrast of anything, whether its a tube TV or computer screen.
Which makes this whole preference for low-contrast incredibly suspicious. Like it was another one of those learned 'ailments' that spread around society like a shitty meme.
My phone is always on low brightness at night, but for some reason my monitor is always at 100% without question, which means light theme during the day (to match paper/pencil in front of me) and dark theme at night because it is otherwise too much light. Then one day, I tried a light theme at night at 50% monitor brightness and my eyes relaxed immediately. I realized that I have been squinting constantly to brace against the maximum brightness.
The usual advice is to instead increase ambient/room light but I have the room light set perfectly for writing and reading on paper.
Decreasing the brightness reduces the contrast which also decreases the readability of it. A dark background with light text has both higher effective contrast and less light hitting your face.
If I zoom in to increase the font size and make it more readable, the text doesn't reflow so it forces me to drag left and right to read the whole line.
There used to be a time where you could have actual adaptive reflowing zoomable text content, but web designers and browser developers conspired to break it and make it worse.
On iOS Safari, there’s a little “ᴀA” button left of the location bar which lets you zoom to make the text larger, reflowing the way you expect.
This makes sense to me. Pinch to zoom is a specific affordance which means “make the line segment between my fingers be this long”. It wouldn’t make sense with reflow.
But if you change the font size setting on your browser you will get exactly what you want. Odd how zoom and font size are not linked the same as on desktop - at least for me on Firefox mobile.
You can customize the user agent. Firefox I can set the colors & fonts …and this includes different settings for dark themes as well. I prefer this experience; namely on my OLED displays I like being able to have #000 black backgrounds & on my e-reader, I much, MUCH prefer #000 text on #fff for maximum readability. There so many contexts where the designer doesn’t need to get overly involved versus letting users decide.
The first one respects my wishes. If I want to adjust the line width I will just adjust the size of my browser window. I have a 38" monitor, the second page is an ocean of grey pixels. I view white space as a direct insult to my intelligence.
Some sites take the 'reduce line width' way too far though, and on a widescreen desktop display you're looking at a narrow column in an ocean of whitespace.
(It's one of the more glaring flaws of the Reddit redesign...)
Personally, the childish "saying motherfucker is shocking/bold" style is a bit of a cop out to make a proper argument.
I don't even say it with the typical puritan TV USA mindset but just the, give me the facts, not the show. Yelling won't make you right, just 14. Specially when it's clearly not a visceral reaction but a thought out post.
It's like comedy that thinks saying fuck or shit is funny when that's basically the lowest bar of humor. Say it, but style matters, the word in itself is not funny (unless you're a kid and afraid of someone telling you off, again: boldness).
While I appreciate the sentiment, I feel you're missing the point. This is akin to maddox's writing. It aims to strike a nice balance between satire and self-immolation, but might stumble in its attempts.
You're supposed to feel conflicted between the obnoxious tone and the rational message. The writing makes fun of know-it-alls while also making a well reasoned argument.
Just read a Maddox (didn't know who they were) post and, boy, is it full of edginess and self confidence to mask that they don't have a good point.
Of course it's easy to rant and monologue. Dozens of TV presenters do it but sometimes it's very easy to find fault in their subjectively humorous generalizations.
Blowing in the wind, the first song that comes to mind, doesn't fit this at all.
A quick Spotify search through the most popular songs and I can't find any in 10-15 that fits that example soundbite he used, to extrapolate this "emperor's got no clothes" argument on bob Dylan.
I'm not particularly a fan of Dylan except a song here and there I like (looking at the list), but it just shows the style over substance and strength of argument.
To this, someone will call "don't be such a buzzkill, it's just a joke" and that's fine but then you've left the land of making valid points and into the self congratulatory "ironic" content.
I didn't miss the point, it seems, but you did miss mine.
> I don't even say it with the typical puritan TV USA mindset but just the, give me the facts, not the show. Yelling won't make you right, just 14. Specially when it's clearly not a visceral reaction but a thought out post.
Yeah, but if they had done it your way neither you nor anyone else would know about it.
Looks to me like they put a lot of thought into the marketing of that thought out post
Agreed. The idea that words can bring curses or displease some fictional deity is a dated trope with no place in modern society. Which means the only reason left is that it displeases certain people to hear them... but fuck those folks for trying to impinge on freedom of speech
This is not about freedom of speech. I explicitly stated it was not a puritan thing.
Fuck your strawman, if you want. See? That did very little in terms of argumentation.
Now it was about using insults instead of proper arguments and pretending the mere use was funny. Which isn't.
Also, it's funny how you "insult" in generic third person because if you insult me directly you might get banned. Hey, feel free to insult me directly. I won't care. You just won't necessarily have a good argument because of it and you might also get your comment deleted, but let's see if you're as "brave" to argue with the would be censors then.
You may also like writing in 1337speak. That's not an actual argument for it being an effective mechanism to convey an argument, which the website presumably tries to.
Finding an insult funny just because it's an insult is definitely childish, as I've said before and you haven't tried to address, it relates to rebelry against some authority, which just isn't there in this case.
I won't be offended by the insult, but using in the way the website in question does is just superfluous content and can effectively serve as an mechanism to hide less than solid points.
I dunno guys, I kind of like CSS.