Text-based web browsers
31 points by abnercoimbre
31 points by abnercoimbre
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.
Some of us will listen, and have listened for years. My site works quite well in a text-mode browser, and always has.
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.
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).
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.
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.
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)
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.
Oh, thanks. After announcing the drop of the no-JS search I would expect this to be broken too, but apparently they lost track?
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 ;-)
There also various annoyances that people apparently consider visual design which disappear in text mode…
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!)
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.
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 :)
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.
On many (most?) sites, you’re probably right that CSS styling could just be a distraction. A quick toggle would be nice, perhaps.
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.
Looks alright in Lynx (modulo the lack of space between the code and the previous paragraph) - https://rjp.is/lynx-code-highlight.jpg
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
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
I wonder what the reasonings given by the different teams are here
Can't directly speak for the current Lynx team (because I've not done development on it for over a decade) but afaik it's basically just Thomas Dickey maintaining it as a side-project.
dynamic relayouting of the page
Unless there's been a radical rewrite, Lynx can't do any page changes without re-parsing the initial HTML (because it does layout at parse time to a fixed grid and essentially discards the HTML afterwards.)
I've never understood this niche, but I keep tabs on it! Favorite quote from the page:
If you don’t care about text-based web browsers (I can’t blame you), this article doubles as a list of all the cool stuff that got added to HTML.
I use them as an ncurses replacement to access local web interfaces (mostly HTML form processing with CGI) through SSH.
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.
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.
Fortunately, Gopher hasn't degraded like HTTP+HTML has.
And Gemini is even better ;)
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.
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.
This has been a good option for quickly looking something up! (Not general browsing.) https://github.com/Magic-JD/is-fast
