---
layout: post
title: Why (Mostly-)Standard HTTP/HTML/optional CSS?
author: Adrian Cochrane
date: 2021-01-23 15:20:24 +1300
---
[Modern](https://webkit.org/) [web](https://www.chromium.org/blink) [browsers](https://hg.mozilla.org/mozilla-central/) are massively complex [beasts](https://roytang.net/2020/03/browsers-http/), implementing an [evergrowing mountain](https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html) of [supposedly-open standards](https://html.spec.whatwg.org/multipage/) few can [keep up with](https://css-tricks.com/the-ecological-impact-of-browser-diversity/). So why do I think I *can* do better whilst adhering to the [same standards](https://w3.org/)? Why do I think that's valuable?
## Where's the complexity?
[XML](https://www.w3.org/TR/2008/REC-xml-20081126/), [XHTML](https://www.w3.org/TR/xhtml1/), & [HTTP](https://tools.ietf.org/html/rfc2616) are all very trivial to parse, with numerous [parsers](https://en.wikipedia.org/wiki/Category:XML_parsers) implemented in just about every programming language. HTML *wouldn't* be much worse if it weren't for WHATWG's [error recovery specification](https://html.spec.whatwg.org/multipage/parsing.html#tree-construction) most webdevs *don't* seem to take advantage of anyways. [CSS](https://www.w3.org/Style/CSS/Overview.en.html) should be *optional* for web browsers to support, and most of the complexity there is better considered an inherent part of rendering international, resizable, formatted [text](https://gankra.github.io/blah/text-hates-you/). Even if your OS is hiding this complexity from applications.
If it's not there, *where* is the complexity? [Richtext layout](https://raphlinus.github.io/text/2020/10/26/text-layout.html) in arbitrarily-sized windows is one answer, which I think is disrespectful to want to [do away with](https://danluu.com/sounds-easy/). But unlike what some browser devs suggest it isn't the full answer.
Expecting [JavaScript](https://262.ecma-international.org/10.0/) to be [fast](https://bellard.org/quickjs/) yet [secure](https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/) so you can [reshape](https://andregarzia.com/2020/03/private-client-side-only-pwas-are-hard-but-now-apple-made-them-impossible.html) a beautiful document publishing system into the application distribution platform you're upset your proprietary OS doesn't deliver *is* a massive source of ([intellectually](https://webkit.org/blog/10308/speculation-in-javascriptcore/)-[stimulating](https://v8.dev/blog/pointer-compression)) complexity. The 1990's-era over-engineered [object-oriented](https://web.archive.org/web/20010429235709/http://www.bluetail.com/~joe/vol1/v1_oo.html) representation of parsed HTML which leaves nobody (including JavaScript optimizers) happy is almost 200,000 lines of code in WebKit, which CSS barely cares about. The [videoconferencing backend](https://www.w3.org/TR/webrtc/) they embed for [Google Hangouts](https://hangouts.google.com/) takes almost as much code as the rest of the browser!
I can back up these claims both qualitatively & quantitatively.
So yes, dropping JavaScript support makes a huge difference! Not worrying about parsing long-invalid HTML correctly makes a difference, not that we shouldn't [recover from errors](https://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html). Even moving webforms out-of-line from their embedding webpages to simplify the user interaction, to the point they can be accessed via the unusual human input devices that interests me, makes a difference. Whilst stopping webdevs from [complaining](https://css-tricks.com/custom-styling-form-inputs-with-modern-css-features/) about OS-native controls clashing with their designs.
There's lots and lots of feature bloat we can remove from web browsers before we jump ship to something [new](http://gopher.floodgap.com/overbite/relevance.html).
## There's Valuable Writing Online
To many [the web is now](https://thebaffler.com/latest/surfin-usa-bevins) just a handful of Silicon Valley giants, surrounded by newssites, etc [begging you](https://invidiou.site/watch?v=OFRjZtYs3wY) to accept numerous popups before you can start reading. It's no wonder they want to burn it to the ground!
But beneath all the skyscrapers and commercialization there's already a vast beautiful underbelly of [knowledge](http://www.perseus.tufts.edu/hopper/) and [entertainment](https://decoderringtheatre.com/). Writing that deserves that [deserves to be preserved](http://robinrendle.com/essays/newsletters.html). Pages that, for the most part, works perfectly fine in Rhapsode as validated by manual testing.
It is for this "[longtail](https://longtail.typepad.com/the_long_tail/2008/11/does-the-long-t.html)" I develop Rhapsode. I couldn't care less that I broke the "[fat head](https://facebook.com/)".
## Links To Webapps
A common argument in favour of jumping ship to, say, [Gemini](https://gemini.circumlunar.space/) (not that I dislike Gemini) is that on the existing web readers are bound to [frequently encounter links](https://gemini.circumlunar.space/docs/faq.html) to, say, JavaScript-reliant sites. I think such arguments underestimate [how few sites](https://hankchizljaw.com/wrote/the-(extremely)-loud-minority/) are actually broken in browsers like [Rhapsode](https://rhapsode.adrian.geek.nz/), [Lynx](https://lynx.browser.org/), & [Dillo](https://www.dillo.org/). This damage is easily repairable with a little automation, which has already been done via content mirrors like [Nitter](https://nitter.net/) & [Invidious](https://invidio.us/).
Rhapsode supports URL [redirection/blocking extensions](https://hackage.haskell.org/package/regex-1.1.0.0/docs/Text-RE-Tools-Edit.html) for this very reason, and I hope that it's novelty leads people to forgive any other brokenness they encounter. Rightfully blaming the website instead.
## Why Not JavaScript?
To be clear, I do not wish to demean anyone for using JavaScript. There are valid use cases you can't yet achieve any other way, *some* of which has enhanced the document web and we should [find alternative more declarative ways](http://john.ankarstrom.se/replacing-javascript/) to preserve. I always like a [good visualization](https://www.joshworth.com/dev/pixelspace/pixelspace_solarsystem.html)! And there is a need for interactive apps to let people do more with computers than read what others have written.
What I want long term is for JavaScript to leave the document web. For the browsers' feature set (like [payments](https://tools.ietf.org/html/rfc8905) & [videocalls](https://tools.ietf.org/html/rfc3261#section-19.1)) to be [split between more apps](https://www.freedesktop.org/wiki/Distributions/AppStream/). If this means websites & webapps split into their own separate platforms, I'll be happy. Though personally I'd prefer to oneclick-install beautiful [consistently-designed](https://elementary.io/docs/human-interface-guidelines) apps from the [elementary AppCenter](https://appcenter.elementary.io/)! And I want it to be reasonable to audit any software running on my computer.
In part my complaint with JavaScript is that it's where most of the web's recent feature bloat has been landing. But I do think it was a mistake to allow websites to run [arbitrary computation](https://garbados.github.io/my-blog/browsers-are-a-mess.html) on the client. Sure that computation is "[sandboxed](https://web.archive.org/web/20090424010915/http://www.google.com/googlebooks/chrome/small_26.html)" but that sandbox isn't as secure (eBay's been able to determine which ports you have open [citation needed]) as we thought especially given [hardware vulnerabilities](https://spectreattack.com/), it's restrictions [are loosening](https://web.dev/usb/), & there's plenty of antifeatures you can add well within it's bounds. JavaScript [degrades my experience](https://www.wired.com/2015/11/i-turned-off-javascript-for-a-whole-week-and-it-was-glorious/) on the web far more often than it enhances it.
I want [standards](https://www.freedesktop.org/wiki/Specifications/) that give implementers [UI leeway](https://yewtu.be/watch?v=fPFdV-Z69Lo). JavaScript is not that!
Even if I did implement JavaScript in Rhapsode all that would accomplish is raise expectations impossibly high, practically none of those JavaScript-*reliant* websites (where they don't [block me outright](https://www.bleepingcomputer.com/news/google/google-now-bans-some-linux-web-browsers-from-their-services/)) will deliver a decent auditory UX. JavaScript isn't necessary for delivering a [great auditory UX](https://www.smashingmagazine.com/2020/12/making-websites-accessible/), only for repairing the damage from focusing exclusively on sighted readers.
## Why CSS?
Webdevs harm the [readability of their websites](https://css-tricks.com/reader-mode-the-button-to-beat/) via CSS frequently enough that most browsers offer a button to replace those stylesheets. So why do I want to let them continue?
I don't. I want a working CSS engine for my own sake in designing Rhapsode's auditory experience, and to allow readers to repair broken websites in a familiar language. I think I can expose it to webdevs whilst minimizing the damage they can do, by e.g. not supporting overlays & enforcing minimum text contrast in visual browsers. For Rhapsode I prevent websites from overriding the "dading" used to indicate links you can repeat back for it to follow.
Regardless I believe CSS should be *optional*. Web browsers shouldn't *have to* implement CSS. Websites shouldn't *have to* provide CSS for their pages to be legible on modern monitors. And users must be able to switch stylesheets if the current one doesn't work for them.