They’re easily overlooked between all the Chrome and Safari violence, but there are still text-based web browsers, and people still use them. How do they handle the latest HTML features?
While CSS is the star of the show when it comes to new features, HTML ain’t stale either. If we put the long-awaited styleable selects and Apple’s take on toggle switches aside, there’s a lot readily available cross-browser.
But here’s the thing: Whenever we say cross-browser, we usually look at the big ones, never at text-based browsers. So in this article I wanna shed some light on how they handle the following recent additions.
↫ Matthias Zöchling
Text-based web browsers work best with regular HTML, as things like CSS and JavaScript won’t work. Despite the new features highlighted in the article being HTML, however, text-based browser have a hard time dealing with them, and it’s likely that as more and more modern features get added to HTML, text-based browsers are going to have an increasingly harder time dealing with the web.
At least OSNews seems to render decently usable on text-based web browsers, but ideal it is not. I don’t really have the skills to fix any issues on that front, but I can note that I’m working on a extremely basic, HTML-only version of OSNews generated from our RSS feed, hosted on some very unique retro hardware. I can’t guarantee it’ll become available – I’m weary about hosting something from home using unique hardware and outdated software – but if it does, y’all will know about it, of course.
Maybe: https://www.theregister.com/2026/01/02/brow6el_browser_terminal/
I was going to suggest brow.sh https://www.brow.sh/
I’m not a fan of bloat, memory leaks, ads, popups, and Ai integration, so I’ll stay a rebel and keep Lynx and Links., n matter the lack of features, as most of my browsing doesnt require pictures or video.
drcoldfoot,
Your comment made me think about using AI to converting multimedia websites to text, which is a task that AI might actually do well at when websites aren’t designed to degrade gracefully. I don’t like the idea of depending on 3rd party services, I wonder if anyone would be interested in something like this if it existed as a browser proxy or extension.
Alfman,
The problem, which we have discussed many times in the past, is the heavy need for JavaScript. Especially as a “de facto DRM”
(Even the youtube-dl now requires a full offline renderer just to get video URLs)
And more, and more websites are shutting down their lightweight / text only versions. A major letdown was GMail, which has been here for maybe 20 years.
So… in theory you’d have full Chrome running as headless
Have an LLM continuously parse the UI (+DOM)
And build a second, fake “text UI” on top if.
As an irony, I think Google’s recent AntiGravity IDE could even be used to kickstart this project.
Downside?
It won’t run fully local on low end hardware. Maybe something like Qwen3 4b could be used with some fine tuning. But that still requires a modern device.
(I asked the feasibility of this to an LLM. I mean why not?
Anyway, it would require a decent computer with 4GB+ VRAM. And would still be slow and laggy.
Ouch)
sukru,
These days I envision most projects processing web data will work best using existing browser engines. (ie webdriver). You may have some savings if you don’t download videos/images/CSS, but the value that a real browser adds in terms of compatibility may be worth the overhead and complexity.
That’s if we heavily rely on an expensive LLM to generate new pages. But that assumes a full blown LLM would be the best way to do this. Since the goal here isn’t to use an LLM to understand and rewrite the content but rather just to understand page elements, formatting, and certain navigation mechanics. A specialized AI might actually do the job better than an LLM while using significantly fewer resources to do so.
Alfman,
Ideally, we would have “Semantic Web™” 🙂
Making the web “machine readable” with RDF, XML, and SOAP kind of technologies (RDF is used in RSS, which is literally RDF Site Summary)
However that experiment has entirely failed.
That specialized AI is the LLM (or LLM is that specialized AI). You need something that understands unstructured language data and process that into a structured format.
Of course we can have very sophisticated SGML parsers, DOM analyzers, and rudimentary language models. But LLMs supersede all of those.
More so, if you fine tune on specific training data.
(If you had written any web scrapers, you would know the pain. “Third p inside the main div has the title. Oops that added another div after the start before the main one”)
sukru,
That might have worked if it had originally underpinned the evolution of the web earlier. It would be so lovely if data and presentation were delivered separately in a consistent way. But HTML conflates these today (despite CSS).. The whole thing is too big to change now, we can’t go back and fix it.
There’s a lot of specialized AIs can outperform LLMs depending on tasks. It’s possible that an LLM could work here, but most off the shelf (ie generic) LLMs would not be a good choice because they’re not trained appropriately for the task at hand. and their overengineering could actually be a problem. We’d just need it to restructure paragraphs and UI/navigation elements for a text medium. This should require far less computational power than an LLM that understands the contents.
I have worked on several projects that needed to parse web content, which is why I emphasized webdriver as a useful tool – importantly it mitigates the javascript accessibility barrier. An LLM might work, but I wouldn’t necessarily say it would outperform other types of AI at this type of task. I think the goal of TUI could be accomplished with fewer resources than you implied earlier.. It could be quite interesting to see these ideas in action using the different approaches. I am envisioning things like a router’s web interface being accessed from the terminal.
Or you use something like crawl4ai as base…
Sysau,
Interesting…I am not familiar with it. I am reading the docs.
https://github.com/unclecode/crawl4ai/blob/main/README-first.md
It does appear to use existing browsers via “playwright”, which itself is a tool to provide automation for browser engines.
https://playwright.dev/docs/browsers
Personally I would have gone about it using the DOM of the source page directly, but I am curious how well a tool like this would work leaving nearly the entire task to the LLM. A tool like this could build a completely new text interface that wouldn’t have to resemble the web version at all: creating summaries, relabeling interface elements, etc. I get the impression there may be too much indirection and it might loose too much context to create a TUI that’s meant to substitute the GUI version of a webpage, especially if the webpage needs to work bidirectionally. But as a read only medium it would be interesting to use an LLM in this way.
Alfman, Sysau,
This all depends on how much of the original page you would like to preserve.
That crawler seems to have two useful advangages.
1 – Converts the main content to Markdown
2 – Handles “infinite scrolling” for extracting paged information
When I was writing my crawler, I also used a text extractor. Basically (1) download page (2) extract links (3) extract title (4) extract main content as text (markdown was not as popular back then)
And used to analyze the text only.
Here those two parts (MD and infini scroll) could be used in translation.
However…
It means you “translate” the content of the page, but not the experience of it. I’m not sure how to best handle interactivity this way.
(Even GMail frontent would not work)
sukru,
An interface build out of standard browser controls (select boxes, input boxes, buttons, etc) can map cleanly to text even if they are controlled via javascript. You can transparently map HTML DOM elements to a new interface while still keeping them wired up unbeknownst to the javascript. New low level interface primatives & interactions built purely out of javascript would be much more difficult to map to textual elements though. If there is nothing recognizable in the DOM to convert, interpreting the GUI graphically makes this a whole lot more challenging!
Many years ago for work I wrote software that did virtually the opposite: present textual mainframe screens as web pages. This software supported a direct mode with 1:1 element mapping, which is meant to work for 100% of interfaces out of the box. The software also supported an indirect mode wherein several terminal screens worth of data could be aggregated into more sophisticated HTML pages and the mapping was bidirectional (ie not just readonly). This opened up the possibility of web interfaces that didn’t have a 1:1 correspondence with the underlying green screen application.
I think many of the same problems exist with text based browsers. 1:1 DOM based mappings should be easy enough and decently for webpages that use standard DOM controls. Browsers like elinks already do this and in principal it should even work when DOM elements are controlled through javascript. But if you start breaking the 1:1 relationship, that’s just very hard to do while retaining bidirectional compatibility.
Alfman,
repeating from below
(This was from Google)
Unfortunately websites do not use standard elements for interactivity. Instead of list boxes, buttons, and option controls, they would use links that only trigger javascript, nested monstrosity of divs and heave use of canvas elements.
sukru,
I don’t think I was clear enough in saying it, but javascript is not the crux of the problem. Many javascript based websites still use DOM interactions and controls. The fact these these DOM elements are generated programmatically creates a problem if you were scraping the HTML directly, but not if you are accessing the DOM of a browser engine that natively supports javascript, which is what I was suggesting. Javascript creates a barrier for accessing information via scrapped HTML, but it does not create a barrier to getting the information and interacting via the DOM.
As long as the javascript application uses the standard DOM model, it doesn’t much matter if those elements were populated through HTML or javascript code and a text browser doesn’t care what created those DOM elements using an API like webdriver. (Just as you can open up the developer tools to peak at the DOM).
So there is no problem with javascript unless the javascript application does away with standard DOM components for GUI interaction. For example instead of HTML buttons & links, it could render it’s own UI controls and handle events using global handlers such that there’s no way to “discover” things like input boxes and buttons by scanning the DOM. The entire interface might be rendered into a canvas. I think this is pretty rare in practice, but hypothetically a website that did this would require computer vision techniques to extract information and it would be far more fragile than the DOM approach.
The problem, of course, is that while AI might be able to describe the images and video, it doesn’t necessarily have the context to focus on what’s *relevant*. And that’s not even getting into what might be relevant to some people reading it and not to others.
My intuition tells me that a website that takes accessibility seriously should also be workable in a text based browser. Isn’t it the cae case?
dsmogor,
I believe that is the case, yes. But I don’t think many pages care about accessibility anymore.
In theory, the “screen reader” would have a DOM representation that could easily render as text.
As someone who has tried to navigate the web with Lynx to clone some repos, the lack of JS is horrible. Drop down spam gets everywhere.
I am one of the dozen people who like to browse the web in terminal emulator while SSHed into a remote box without having to reply on yet another service or server.
Flatland_Spider,
Yes. IMHO it would be useful for text browser like Lynx to support javascript to make itself compatible with more websites. But javascript is a lot of effort for a niche project. The best way to maximize compatibility would be to use an existing browser engine and provide a text interface for the DOM. This way at least from the website’s perspective it would look and work like a normal browser even if it’s being rendered out to a text interface.
It used to be trivial and useful to run SSH with -X to remotely launch a standard browser via X11, but alas it no longer works in many distros that did the wayland swap.
I don’t know what your use case is, but if you just want to proxy your traffic through another box (ie I sometimes use this to access intranet resources over the web), SSH is still quite the swiss army knife.. You don’t need to configure anything on the server or client to create a socks proxy that works with the browser. And SSH does it securely to boot!
(edit: wordpress destroyed the command…trying again)
“ssh -N -D port user@host”
Of course if your goal is to download resources to the remote server, then using it as a proxy won’t be useful. I often use “wget” to download things to remote servers once I copy the URL from my local browser.