shiomiru

> Things can remain backwards compatible forever.

This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company.

Indeed, to me it seems that at some point, you either have to

a) freeze the standard

b) drop old stuff

c) accept that there is no standard

and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate.

(Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)

> If the site really was static before, and no JS was needed

One does not imply the other. This forum is one example. (Or rather, hn.js is entirely optional.)

> Another great solution? Just ask users to login (no js needed). I'll stand pretty firmly behind "If you aren't willing to make an account - you don't actually care about the site".

Accounts don't make sense for all websites. Self-hosted git repositories are one common case where I now have to wait seconds for my phone to burn through enough sha256 to see a readme - but surely you don't want to gate that behind a login either...

> My take is that search engines and sites generating revenue through ads are the most impacted. I just don't have all that much sympathy for either.

...and hobbyist services. If we're sticking with Anubis as an example, consider the author's motivation for developing it:

> A majority of the AI scrapers are not well-behaved, and they will ignore your robots.txt, ignore your User-Agent blocks, and ignore your X-Robots-Tag headers. They will scrape your site until it falls over, and then they will scrape it some more. They will click every link on every link on every link viewing the same pages over and over and over and over. Some of them will even click on the same link multiple times in the same second. It's madness and unsustainable.

https://xeiaso.net/blog/2025/anubis/

> Functionally - I think trying to draw a distinction between accessing a site directly and using a tool like an LLM to access a site is a mistake.

This isn't "a tool" though, it's cloud hosted scrapers of vc-funded startups taking down small websites in their quest to develop their "tool".

It is possible to develop a scraper that doesn't do this, but these companies consciously chose to ignore the pre-existing standards for that. Which is why I think the candy analogy fits perfectly, in fact.

> They mostly aren't worth worrying about

Well, a common pattern I've lately been seeing is:

* Website goes down/barely accessible

* Webmaster posts "sorry we're down, LLM scrapers are DoSing us"

* Website accessible again, but now you need JS-enabled whatever the god of the underworld is testing this week with to access it. (Alternatively, the operator decides it's not worth the trouble and the website shuts down.)

So I don't think your experience about LLM scrapers "not mattering" generalizes well.

> I don't get it either, because that has always been the case, thus most of his post is borderline non sense.

Yes, making software development cheaper has been the main priority of the industry for a long time. The new development is that there's now a magic "do what I want" button that obviously won't quite do what you want but it's so cheap (for corporations, not humanity...) that you might as well pretend it does. (Compared to paying professionals who might even care about doing a good job, that is.)

That's what pagers are for (e.g. less.)

That is allowed, with the exact same syntax as Python. But then you still lose the qualification so I don't see any benefits, it's just more boilerplate to constantly adjust, git conflicts to fight with, etc.

Nim's import rules are part of its generalization of OOP's obj.foo() syntax. That is, in Nim, you don't have to put "foo" in a specific class, just set the first parameter of "foo" to the type of "obj", and this only works if you don't have to qualify "foo" (similarly to OOP languages...)

The difference between valid PNG you can't decompress and invalid PNG is fairly irrelevant when your aim is to get an image onto the screen.

And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.

Sure, but I'm talking about where my fingers first reach when taking the device out of my pocket.

In that case, I'm grabbing it with my thumb, index finger and middle finger, and since the phone is seated upside down, my thumb reaches the home button before I'm even holding it in my palm.

On phones with a fingerprint sensor on the back, I first have to get a full grip, and then I can reach for the sensor.

(But it's probably somewhat hand/pocket-specific...)

> That was seriously the best solution.

I much prefer having it on a physical home button. You can still feel a dent, but it takes even less effort to reach for it with your thumb.

(Well, I think the Pixel never had a home button, and by now it's unfortunately disappeared from other phones too...)

The closest thing is https://codeberg.org/bptato/chawan/raw/branch/master/todo, but it's somewhat outdated and I rarely bother to sort it according to priority...

Fixed on master.

(It turned out to be a miscompilation on part of clang; quite interesting, see the ticket linked above for details.)

> terminal browsers are hobby projects because

...those pesky GUI users want pixel-precision :P

Surely it's a hobby project. You have to have very specific tastes to browse in the terminal in 2025.

> using external binaries for protocols feels like sidestepping the real engineering

You could easily move all protocols to the main binary. The reason for the current arrangement is that this way, you can e.g. replace the HTTP handler with curl-impersonate, or add custom protocols like magnet (etc.) See the bonus directory in the sources for inspiration.

> tied to niche image formats like sixel/kitty which barely anyone supports.

Sixel & Kitty are the only image formats anybody supports. The alternatives are ASCII art (fun, but too pixelated) & hacking images onto the terminal thru the display server (is that still a terminal-based app?) But I'm happy to discuss further, I find the issue fascinating :)

> mac

The macOS issue is largely a function of the only person working on this not having a mac. If you do, you can help solving it by debugging it yourself & posting the results: https://todo.sr.ht/~bptato/chawan/63

chawan has a custom terminal module, so my knowledge about the standard X/Open curses is not that great.

That said, for the actual escape sequences, XTerm's ctlseqs.ms[1] is an invaluable resource. I also took many ideas from nick black's notcurses[2], and I especially recommend his notes on "sprixels".[3]

[1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

[2]: https://nick-black.com/dankwiki/index.php/Notcurses

[3]: https://nick-black.com/dankwiki/index.php/Theory_and_Practic...

The intention is that it should "just work"... I'm aware sometimes it doesn't, you can consider that a bug :)

But if you really want custom CSS for grid displays, chawan does support the standard "grid" media feature: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/grid

The address bar should open by pressing C-l (control + L).

Chawan never really used ncurses, only termcap. (ncurses just happens to implement termcap too.)

I started with termcap because I was already familiar with it through w3m. But termcap is an obsolete interface, and cannot describe the only useful attribute for modern terminals (true color). Its only benefit was "maybe it accidentally works on a hardware terminal from the 80s", which is cool but not really worth the extra failure mode.

So instead of migrating to terminfo, I ditched it completely in favor of terminal queries (which were already necessary for other reasons). There is still a built-in terminal database, to detect known TERM values with XTerm incompatibilities. But a terminal that correctly responds to queries will work out of the box, even if its TERM value is unknown.

Strange, so it sees your input but still doesn't evaluate the commands...

OK, let's try something else. On master, is anything written to the status line if you press `p` when started with

    cha -o'page.p="pager.alert(config.page.j)"' -V

It's a bug, thanks for reporting. I've created a ticket: https://todo.sr.ht/~bptato/chawan/63

Could you please pull the macos-input branch from https://git.sr.ht/~bptato/chawan and report back on what the `a` file includes after opening a site and typing some commands? (Should be created in the current working directory.)

cha-config(5) or about:chawan. The former also has an online version: https://chawan.net/doc/cha/config.html#pager-actions

For navigation in particular you'd use capital D to discard the current buffer and return to the previous page. There's also , (comma, back) and . (period, forward), which non-destructively cycle through the stack.

(Well, it's really a tree, but the UI mostly treats it as a stack.)

Thanks :)

If you're interested, I posted a user style for HN here: https://lists.sr.ht/~bptato/chawan-devel/%3CD9S40OS2QWHL.PXQ...

Mainly just to fix the vote arrows, because for now background-image only renders placeholders.

No GPM yet, but it does recognize XTerm's mouse protocol.

Glad you like it :)

> XTerm OSC 4 may have a very limited ability to probe the color palette. At least on `st` I can only see default foreground, background and cursor colors, not the full 16-color palette. This mostly just amplifies the point elsethread by @hnlmorg.

What st version? For me, 0.9.2 prints the entire color cube with

    for n in `seq 0 255`; do printf '\033]4;%d;?\033\\' "$n"; done; read

(although unsurprisingly, it's subtly broken: I sent ST, but the responses are terminated with BEL...)

> The idea of taking a screenshot of the terminal and then parsing that to determine the true colour support is definitely novel,

A better way to do this is to send `OSC 1 0 ; ? ST` (query foreground color), `OSC 1 1 ; ? ST` (background color), then `OSC 4 ; {n} ; ? ST` where {n} is the nth XTerm color.

See: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-O...

It's not just lazy, it's nonsense. The author is conflating piracy with plagiarism, even though the two are completely different issues.

Plagiarism is taking somebody else's work and claiming that you yourself created it. It is a form of deception, depriving another of credit while selling their accomplishments as your own.

Piracy on the other hand is the violation of a person's monopoly rights on distributing certain works. This may damage said person's livelihood, but the authorship remains clear.

> Scrapers, on the other hand, keep throwing out their session cookies (because you could easily limit their access by using cookies if they didn't). They will need to run the PoW workload every page load.

Such a scheme does not work without cookies in the first place, so the optimal strategy for scrapers is to keep any (likely multiple) session cookies until they expire. Technical details aside, if a site becomes a worthy target, a scraping operation running on billions of dollars will easily bypass any restrictions thrown at it, be that cookies, PoW, JS, wasm, etc. Being able to access multiple sites by bypassing a single method is just a bonus.

Ultimately, I don't believe this is an issue that can be solved by technical means; any such attempt will solely result in continuous UX degradation for humans in the long term. (Well, it is already happening.) But of course, expecting any sort of regulation on the manna of the 2020s is just as naive... if anything, this just fits the ideology that the WWW is obsolete, and that replacing it with synthetic garbage should be humanity's highest priority.

My interpretation is that they are interested in looking at a real world application of the technology in question, which seems on-topic to me. But I agree that it's worded unfortunately.

I was curious what "view transitions" are even about: https://www.w3.org/TR/css-view-transitions-1/

It's yet another 2.8k line specification solely authored by Google employees, introducing a brand new complexity monster (clones of ghost elements represented as a pseudo-element tree) to... make it easier to add fancy animations.

Now what I really miss is a "disable CSS animations" button. I find them very distracting and an unnecessary burden on battery life.

> I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too.

A "standard" should mean there is a clear goal to work towards to for authors and browser vendors. For example, if a browser implements CSS 2.1 (the last sanely defined CSS version), its vendor can say "we support CSS 2.1", authors who care enough can check their CSS using a validator, and users can report if a CSS 2.1 feature is implemented incorrectly.

With a living standard (e.g. HTML5), all you get is a closed circle of implementations which must add a feature before it is specified. Restricting the number of implementations to one and omitting the descriptive prose sounds even worse than the status quo.