My Baseline Browser

Oh, I see you disabled JavaScript. Keep up the good work, my fellow cleanweb person!

Notice that there might be trace amounts of JS, used for:

Runnable JS code blocks
Prettier email feedback form
Random shuffling of “thought” cards in some posts.

JS is not required for use of the website though, it’s only enhancing the existing functionality.

A light colors thumbnail with “BROWSER” in the middle. Around it, there float a Tab key, Text Fragment marker, Processing Instruction ?start, and an unclosed HTML tag.

Web is hard. Implementing a compliant browser is a doomed enterprise unless you’re Google, Apple, or a whole Open Source community.

But there’s a new breed of browsers like Dillo that focus on a restricted set of Web features. And ignore a whole lot of other “bloat.” Which is a good approach, I think. However, there’s no list of actually useful features that are not “bloated” and thus should be included in a browser. (Consider this a kind of informal standard.) So here’s my list of essential browser features (likely to be updated often:)

Hyper… Text! #

A revelation: a browser does not have to be an app platform. It can be a mere hypertext viewer. Yes, you wouldn’t browse Facebook with this, but do you need to? (I know, not the best argument.)

So my idea of a baseline hypertext browser is that. Hyper… text.

smolweb HTML + Shortcuts #

smolweb HTML is an essential read for web devs. It specifies a “safe” subset of HTML that any browser can easily implement. And that actually does not ignore Accessibility, like many other proposals.

The only problem with smolweb HTML is that it’s… not HTML? It’s XHTML, which cuts out a lot of useful historic shortcuts, like implied end tags. So my perfect HTML subset is smolweb + lenient parsing. Quirks Mode, basically.

Basic CSS #

God I love CSS. I am a heavy :has and pseudo-elements addict. However, I also realize that these are not friendly to smaller browsers.

So my recommendation is this: stick to grades A-C of smolweb CSS. Should be enough for basic styling. Without the need for essentially a Turing-complete styling engine.

Userstyles! #

Dark mode, in the simplest instance. And the ability to override all page styles, in a more complex instance. Preferably supporting existing userstyles formats.

Basic Interactivity: Forms and Commands #

Even a barebones hypertext browser needs a way to communicate with servers. There is a tool for that: HTML forms. Supporting these is enough for basic interactivity.

(A minor pet peeve: please support mailto actions in your forms, as these are a nice way to bridge the worlds of Web and email.)

Add Invoker Commands to that and you have an actually modern declarative interactivity in a browser. I mean, Invoker Commands are popover-heavy, which defeats the point on CSS. But they are a good direction anyway!

Essentials #

Browsers had these for a whole eternity. We don’t want to abandon these:

History: Might be as simple as linear stack history. Or as involved as a Tree-based global / tab-local history
Text search: Again, can be very basic, but I’d also prefer to have case-(in)sensitivity and regex built-in.
Text fragments: Text Fragments are a relatively recent feature. They have ugly syntax and weird behavior. So they’re proper Web citizens! Anyway, Text Fragments allow linking to any piece of text on the page. Without relying on the author adding an ID to everything. It’s an empowering thing and I want to have it in my browser.
Bookmarks: Netscape browser format, with all its quirks. It’s probably the most supported and simplest one. Baseline, in other words.
Tabs: Yes, early browsers had no tabs. And tabs imply a certain multi-process nature required from a browser. But, overall, these are too good to leave them out. Please give me some tabs. Vertical tabs will do too.

DOM Modifications: Processing Instructions and Declarative Templates #

I know, I know, these are too recent! However, they are useful and lightweight and can be implemented in a JS-less browser. So why not have nice things?

Processing instructions (euphemized as Out-of Order Patching by Chrome) and <template for= attribute are building blocks for a nicer client-side HTML-only templating. They are still under-specified and only work in Chrome, but I don’t see how they can be too hard to implement. And they don’t yet allow passing any parameters besides wrapping them into classes or something.

template seems to be a nice thing in general. It concentrates a lot of declarative dynamic HTML features in it. Like Declarative Shadow DOM, for example. Don’t fret though—Shadow DOM is not mandatory for useful template, actually. We can still have templates in a basic browser and use them to construct things.

Keyboard Navigation #

There might be different keyboard navigation features:

accesskeys as quick keybinds created by the page author. Mandatory.
Tab key navigation. It’s essential, both for accessibility and proper navigation. Yes, Tab key is really inconvenient to spam. But that’s the best we have so far. Well, unless everyone implements ARIA properly (🥁)
Caret Browsing maybe?
Something fancy, like Firefox / search or Nyxt Link Hints. If you aim for keyboard accessibility and power-user appeal, these are almost required.

Totalling to a Proper Browser #

This post is a hodgepodge listing of features I want to see in my dream browser. I know, it’s quite chaotic! And it does include both ancient features and really recent ones. So I dunno… maybe implement these if you’re making a browser?