It's extremely sad because there's no chance that any will listen, but:
If your website could work reasonably in any text-mode browser, then you should make it work (even if there's some degradation).
I'm pretty sure normal users will benefit from this a lot! From people on not-the-latest-and-greatest devices, to people with accessibility needs... to even normal users! Even the developer will likely benefit, as I guess testing will be faster.
So do I, but unfortunately we are a minority and I don't think the message is getting across to any new web developers.
I have to say I was pleasantly surprised to learn that Next.js at least comes out of the box doing server-side rendering by default. But still, many popular web development stacks make it too hard.
That's one of the "signals" that make me appreciate the Lobsters community. And I actually use "do I have to enable JS" as a signal to evaluate the worthiness of an article.
(I think I may have mentioned here that "JS-required" could be another "format" tag here. But I think it's overkill.)
And I actually use "do I have to enable JS" as a signal to evaluate the worthiness of an article.|
I get that impulse. However, there's programmers I really admire (non-web savvy) who will publish on WordPress or Medium for convenience. Their writings are usually valuable. Do you make exceptions for them?
If they have not changed things recently, WordPress defaults to server-side rendering. I just opened my brother's blog in w3m and it's fine.
I've rarely seen content I like on Medium.
As I mentioned, it's just a signal. If there's a Medium article with a lot of good comments here, I'll likely read it. But if I see it posted on some other source without much endorsement, I might skip it.
You can get a plain-HTML compatible version of Google Docs by replacing the last URL component with "mobilebasic" (e.g.). Still annoying that you need to do this manually, but at least it is possible.
Well, I read lobste.rs every day in Offpunk, reading most links without any problem in it. In some cases, it works even better (because it extract the content using either readability or unmerdify)
I only relies on Librewolf to post comments like this one ;-)
Other than gigantic navigation bars, the biggest hurdle for designing with text mode browsers in mind is the lack of CSS support.
For example, (static) syntax highlighting in code examples is easy to do with CSS classes, but to make that work in w3m and friends I resorted to using <b>, <i>, etc. (semantic tags like <strong> might have also worked). I'm pretty happy with the end result, though.
Huh, I'd never seen this approach. That's interesting.
I was going to suggest that this would be an area where I wouldn't mind progressive enhancement- I think most would trade in syntax highlighting for proper lightweight HTML, but your solution looks great. I think it would be worthwhile to "package" this so it could be used by others :)
(Screenshots of code are one of my biggest pet peeves. That's even worse, and quite frequent!)
As someone doing all my web reading for 4 years using Offpunk (which has no CSS/JS support), it turns out that’s no supporting CSS is a blessing: I focus on the writing and I’m not disturbed by all the coloured gimmicks webmasters want to impose on me.
I’m so used to it that I’m now basically unable to read seriously outside of Offpunk (I feel like in a blinking neon-lights street on the normal web). Fortunately, I’ve a quick shell shortcut that will put the article I want to read in my Offpunk "tour" to read it later.
It's totally ok to not have syntax highlighting, some of us might even prefer it that way. In my text mode browser I explicitly disable page colors. For text mode support I'd focus on making sure that the text content is laid out in a reasonable way even without JS, CSS and images.
Every time I reinstall my ArchLinux (which happens at least every 5 years or so, I think...?) I end up using links or lynx to look up information that I'd forgotten on the ArchWiki :D
Adding support for hidden to Lynx is not that difficult (from what I remember of the source - it's been a while.) Obviously there's no way to make it unhidden afterwards due to the lack of Javascript but I'm assuming people can live with that. Also no way to properly support the "until-found" mode. But definitely doable in some kind of fashion.
My only use case for text mode browsers is on old computers that can’t handle a graphical interface or are very constrained on RAM. w3m uses a few tens of megabytes of memory with a dozen “tabs” open.
by requiring UTF-8 […], Gemini excludes retro hardware
Why is UTF-8 problem for retro hardware, and what would be better there? Assuming the system uses a fixed-width 8-bit encoding, the code necessary to translate between the system native code page and UTF-8 will be minimal. In contrast, using a mix of encodings (as e.g. AMB does) means you get to choose between possibly incorrect display (assuming the text is in the local code page) and higher amount of complexity than just using UTF-8 has (going dynamically from the source encoding to unicode to local code page).
On the "excludes retro hardware" front, I have written a Gemini to Gopher gateway. It doesn't do anything about UTF-8, but that's been a pretty minor problem.
One point worth noting here is that, in contrast to the break-neck pace of change in mainstream web browsers, these historic text browsers tend to be developed at quite a different schedules. The features in the article (except for the hidden attribute, which the article notes text browser developers are aware of and have rejected¹) are, per MDN, available across the most popular web browsers' latest versions:
Lynx has gotten releases 2.9.0, 2.9.1, and 2.9.2 between January and May 2024
Elinks has released a minor version once a year in December (most recently Elinks 0.19.0 last month)
w3m has transitioned to another maintainer who's released 0.5.4 and 0.5.5 in October of last year
In the time scales these projects operate on, all of these features are still new. Combined with several of them requiring dynamic relayouting of the page (which I don't believe is needed by any of their existing supported HTML features), I am honestly not surprised these are not supported. Additionally, while I do see the use of <details> and popovers for text browsers (since they are both useful for "document" style of HTML pages, which text browsers are mainly usable with), I am not sure what use, say, a modal dialog that can only be dismissed would have for users of these browsers.
¹ I'd be interested in seeing links to discussion about this, if anyone has them – I wonder what the reasonings given by the different teams are here
koala | a day ago
It's extremely sad because there's no chance that any will listen, but:
If your website could work reasonably in any text-mode browser, then you should make it work (even if there's some degradation).
I'm pretty sure normal users will benefit from this a lot! From people on not-the-latest-and-greatest devices, to people with accessibility needs... to even normal users! Even the developer will likely benefit, as I guess testing will be faster.
The other thing I always like to mention is this section from the Emacs web browser manual that mentions how to use Chrome to turn websites that require JS to render into HTML. More work should be done on this technique.
spc476 | a day ago
Some of us will listen, and have listened for years. My site works quite well in a text-mode browser, and always has.
koala | 20 hours ago
So do I, but unfortunately we are a minority and I don't think the message is getting across to any new web developers.
I have to say I was pleasantly surprised to learn that Next.js at least comes out of the box doing server-side rendering by default. But still, many popular web development stacks make it too hard.
k749gtnc9l3w | a day ago
And actually, most static text Lobste.rs submissions I click on work fine in text-mode browsers. (I know because I read them in Vim).
koala | 19 hours ago
That's one of the "signals" that make me appreciate the Lobsters community. And I actually use "do I have to enable JS" as a signal to evaluate the worthiness of an article.
(I think I may have mentioned here that "JS-required" could be another "format" tag here. But I think it's overkill.)
[OP] abnercoimbre | 9 hours ago
I get that impulse. However, there's programmers I really admire (non-web savvy) who will publish on WordPress or Medium for convenience. Their writings are usually valuable. Do you make exceptions for them?
koala | 9 hours ago
If they have not changed things recently, WordPress defaults to server-side rendering. I just opened my brother's blog in w3m and it's fine.
I've rarely seen content I like on Medium.
As I mentioned, it's just a signal. If there's a Medium article with a lot of good comments here, I'll likely read it. But if I see it posted on some other source without much endorsement, I might skip it.
nortti | 7 hours ago
Ime Medium works fine (at least for basic text + pictures use case) without JS as long as none of the paywall features are being used.
k749gtnc9l3w | 6 hours ago
I do think less of things that are published as Google Doc for no good reason. Medium and WordPress work fine in the No JS No CSS No Cookies case.
Blog posts as Mastodon threads are annoying, though. (Single large post is fine, it gets dropped in its entirety into description meta entry)
nortti | 6 hours ago
You can get a plain-HTML compatible version of Google Docs by replacing the last URL component with "mobilebasic" (e.g.). Still annoying that you need to do this manually, but at least it is possible.
k749gtnc9l3w | 5 hours ago
Oh, thanks. After announcing the drop of the no-JS search I would expect this to be broken too, but apparently they lost track?
ploum | 19 hours ago
Well, I read lobste.rs every day in Offpunk, reading most links without any problem in it. In some cases, it works even better (because it extract the content using either readability or unmerdify)
I only relies on Librewolf to post comments like this one ;-)
k749gtnc9l3w | 18 hours ago
There also various annoyances that people apparently consider visual design which disappear in text mode…
jaredkrinke | a day ago
Other than gigantic navigation bars, the biggest hurdle for designing with text mode browsers in mind is the lack of CSS support.
For example, (static) syntax highlighting in code examples is easy to do with CSS classes, but to make that work in w3m and friends I resorted to using
<b>,<i>, etc. (semantic tags like<strong>might have also worked). I'm pretty happy with the end result, though.koala | 20 hours ago
Huh, I'd never seen this approach. That's interesting.
I was going to suggest that this would be an area where I wouldn't mind progressive enhancement- I think most would trade in syntax highlighting for proper lightweight HTML, but your solution looks great. I think it would be worthwhile to "package" this so it could be used by others :)
(Screenshots of code are one of my biggest pet peeves. That's even worse, and quite frequent!)
jaredkrinke | 12 hours ago
Already packaged :) https://lobste.rs/s/uipd87/450_kb_static_site_generator_based_on
Edit: in case you meant just the syntax highlighting part, that should be easy to do, too, but I forgot about it until just now.
koala | 9 hours ago
Oh, don't feel obliged. And there's a certain lack of "composability" for this kind of tools. But I really think your idea is pretty neat :)
ploum | 19 hours ago
As someone doing all my web reading for 4 years using Offpunk (which has no CSS/JS support), it turns out that’s no supporting CSS is a blessing: I focus on the writing and I’m not disturbed by all the coloured gimmicks webmasters want to impose on me.
I’m so used to it that I’m now basically unable to read seriously outside of Offpunk (I feel like in a blinking neon-lights street on the normal web). Fortunately, I’ve a quick shell shortcut that will put the article I want to read in my Offpunk "tour" to read it later.
jaredkrinke | 12 hours ago
On many (most?) sites, you’re probably right that CSS styling could just be a distraction. A quick toggle would be nice, perhaps.
donio | 10 hours ago
It's totally ok to not have syntax highlighting, some of us might even prefer it that way. In my text mode browser I explicitly disable page colors. For text mode support I'd focus on making sure that the text content is laid out in a reasonable way even without JS, CSS and images.
zimpenfish | a day ago
Looks alright in Lynx (modulo the lack of space between the code and the previous paragraph) - https://rjp.is/lynx-code-highlight.jpg
aapoalas | a day ago
Every time I reinstall my ArchLinux (which happens at least every 5 years or so, I think...?) I end up using links or lynx to look up information that I'd forgotten on the ArchWiki :D
zimpenfish | a day ago
Adding support for
hiddento Lynx is not that difficult (from what I remember of the source - it's been a while.) Obviously there's no way to make it unhidden afterwards due to the lack of Javascript but I'm assuming people can live with that. Also no way to properly support the "until-found" mode. But definitely doable in some kind of fashion.[OP] abnercoimbre | a day ago
I've never understood this niche, but I keep tabs on it! Favorite quote from the page:
kidon | a day ago
I use them as an ncurses replacement to access local web interfaces (mostly HTML form processing with CGI) through SSH.
jaredkrinke | a day ago
My only use case for text mode browsers is on old computers that can’t handle a graphical interface or are very constrained on RAM. w3m uses a few tens of megabytes of memory with a dozen “tabs” open.
ethoh | a day ago
Fortunately, Gopher hasn't degraded like HTTP+HTML has.
ploum | 19 hours ago
And Gemini is even better ;)
ethoh | 16 hours ago
Nah, I'd rather evolve Gopher or Spartan.
Gemini is neither great nor meant to actually be used.
I do not like it; Unfortunately, by requiring UTF-8 and TLS, Gemini excludes retro hardware.
nortti | 7 hours ago
Why is UTF-8 problem for retro hardware, and what would be better there? Assuming the system uses a fixed-width 8-bit encoding, the code necessary to translate between the system native code page and UTF-8 will be minimal. In contrast, using a mix of encodings (as e.g. AMB does) means you get to choose between possibly incorrect display (assuming the text is in the local code page) and higher amount of complexity than just using UTF-8 has (going dynamically from the source encoding to unicode to local code page).
gcupc | 13 hours ago
On the "excludes retro hardware" front, I have written a Gemini to Gopher gateway. It doesn't do anything about UTF-8, but that's been a pretty minor problem.
nortti | 6 hours ago
One point worth noting here is that, in contrast to the break-neck pace of change in mainstream web browsers, these historic text browsers tend to be developed at quite a different schedules. The features in the article (except for the hidden attribute, which the article notes text browser developers are aware of and have rejected¹) are, per MDN, available across the most popular web browsers' latest versions:
In January 2020, the most recent stable versions of the tested text browsers were:
Since then:
In the time scales these projects operate on, all of these features are still new. Combined with several of them requiring dynamic relayouting of the page (which I don't believe is needed by any of their existing supported HTML features), I am honestly not surprised these are not supported. Additionally, while I do see the use of <details> and popovers for text browsers (since they are both useful for "document" style of HTML pages, which text browsers are mainly usable with), I am not sure what use, say, a modal dialog that can only be dismissed would have for users of these browsers.
¹ I'd be interested in seeing links to discussion about this, if anyone has them – I wonder what the reasonings given by the different teams are here