i find myself requesting this whenever i see a new minimalist browser pop up:
it would be great to standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that when building their websites and alternative browsers makers can target something useful without boiling the ocean
i personally prefer this approach to brand new protocols like Gemini, because it retains backward compatibility with popular browsers while offering an off ramp.
> standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that
Could such a standard be based on the subset of HTML/CSS acceptable in emails? Maybe with a few extra things for interactivity.
AFAIK, "email HTML" isn't standardized either; most organizations that make nice-looking HTML emails have to do a ton of testing across different clients and come up with workarounds to make everything look consistent.
It's fascinating how much "email HTML" is trapped in about HTML ~2.5, with limited CSS support and still a ton of FONT tags and TABLE layouts.
HTML 2 might be an interesting subset of HTML to "focus on" for smolweb, but it would be a big retro throwback, and not feel at all modern.
If you were starting today, might be more interesting to start with the most modern stuff and work backwards. HTML 2 TABLE could be implemented as a specialization of CSS Grid, for instance.
Could we standardize email HTML?
If you can convince Apple, Google, and Microsoft to implement your standard: sure. Attempts have been made with varying success.
Your standard still needs to render in Outlook on Windows, though, which means you need to support the weird Office version of IE11 as an upper limit.
Google has recently been pivoting AMP which nearly broke the web towards email. It might actually be a better use of AMP than the web, but I'm still skeptical about some of its privacy stance and ad-injection focus: https://amp.dev/about/email
Does the email client on Windows still use IE11? (Some older versions might still have significant market share, but I’m not sure it would be for much longer?)
"Outlook (New)" (aka "One Outlook") is React Native with a full Chromium webview, and the transition from out-of-the-box Windows-provided "Outlook Mobile" (Windows 8-10) to "Outlook (New)" has mostly completed, but the transition from Outlook (Classic) (aka "Bloated Corporate Outlook") seems somewhat stalled because a few big corporations have extensive plugins and cranky IT admins. (Also Outlook Mobile had a better than IE11 support and also has been Chromium on most platforms, it is "Outlook (Classic)" that continues to haunt us all with its ancient Word-based micro-browser fork of IE.)
Sometimes I really wish MSFT broke backwards compatibility in the places that matter, not places their corporate customers don’t care about.
You could write a standard.
If it actually gets mainstream adoption or goes into the standards pile it another question entirely.
A few extra things like.. JavaScript?
No interactivity! The email must be printable as-is. Not even CSS code to change styles when you hover over links. That's what I would for a minimum HTML for emails standard that's widely supported.
It’s actually a bummer: you can’t use a <style> tag because some email clients don’t like them. Instead, you have to inline your styles in every element. the lack of :hover is just a side effect of that I think (although it plays out nicely here).
(While on it, can we also ban loading images from third-party servers?)
you sure can if we resolve to make a text editor instead of a web browser!
Hmm, that might not be a bad idea! We could ban CSS altogether: just leave some markup tags, maybe whatever you can do in Markdown + tables. No colors, no small print, no images. (We could even use something like gemtext as the format instead of HTML, but that wouldn’t be backward compatible with clients.)
But I don’t see any email clients with somewhat significant market share going through with this :(
I'm confused, we're talking about browsers, and comment I replied to suggested 'email + interactivity' as a standard for minimal browsers. I wasn't suggesting adding JS execution to emails. (I don't even allow remote images personally.)
A total PL would be nice...
I think that would be really neat for small scale web publishing, but making it a subset of browser standards could be a really difficult sell to the people making browsers. While it's easier to build a browser to a subset of such a massive set of specs, the subset will drift towards a "similar but slightly incompatible standard" pretty soon after it's decided on. Following the development of Ladybird has given me an appreciation for just how often the "spec" for the web changes. (in small ways, daily.) That locks new browser implementations into a diverging standards track that would be very difficult to get off of.
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. "It's got to look good in Ladybird/Vaev/etc".
An idea: a web authoring tool built around libweb from Ladybird! (Or any other new web implementation that's easily embeddable) The implied standard-ness of whatever goes in that slot would just come for free. (Given enough people are using it!)
small-web living standard
The phrase "living standard" is an oxymoron, invented by the incumbents who want to pretend they're supporting standards while weaponising constant change to keep themselves incumbent.
> 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.
The subset could just be an older version of the spec, e.g. HTML 4.01 and CSS 2.1.
(My opinion as another one who has been slowly working on my own browser engine.)
Pick a subset aimed directly at accessibility.
The least-needed features are often accessibility nightmares (e.g. animation - although usually not semantic).
The accessible subset could then be government standardized and used as a legal hammer against over-complex HTML sites.
For a while search engines helped because they encouraged sites to focus on being more informative (html DOCUMENTS).
I think web applications are a huge improvement over Windows applications, however dynamic HTML is a nightmare. Old school forms were usable.
(edited to improve) Disclosure: wrote a js framework and SPA mid 00's (so I've been more on the problem side than the solution side).
Styles can be provided as client-side dependencies instead of free form CSS:
then browser decides how to resolve them.That's easy to specify but contains a lot of bloat and unused features. A slimmer but more modern set would be useful.
I feel like some of the newer standards like CSS Grid instead of tables might be the best way to go. Many HTML/CSS improvements were not just bloat but actually better standards to build on.
Right! Crazy fonts or cursors, not on smolweb (as another use put it) but Flex and Grid are almost necessary. There are loads of things that could be dropped (it feels like).
I just want one of these browsers to give me a proper ComboBox (text, search and drop-down thing)
From accessibility background: Please stop using CSS for table data. It does not translate to my screenreader.
Yes, but grids are everywhere in the UIs, not just the tables. In 2000-s, the problem was the opposite of what we have now: every interface was a table full of tables, because there was no other way to position things reliably.
But now we have best of both worlds: use <table> for the actual tables, and CSS grid for UI layouts.
You still need to have tables.
And <marquee>, of course.
But the rendering engine might be easier to build with TABLE as a specialization of CSS Grid layout rendering rather than the slow real world work of CSS Grid being a generalization of TABLE rendering.
Sounds kinda like DOM levels: https://en.wikipedia.org/wiki/Document_Object_Model#Standard...
Well, until everybody just gave up and declared it a "Living Standard".
I think we do still need something like this, but I worry that basing it on versions of the spec is just repeating the same DOM levels mistake.
Cat is out of the bag. nobody wants their CSS without flexbox anymore. It has to include that.
Everything flexbox can do, CSS Grid can do, with easier/better/cleaner support for the second axis. At this point, I'd be interested in dropping flexbox entirely for CSS Grid.
("I don't need to worry about the second axis" seems to be a "not thinking fourth dimensionally enough" excuse to me today. You haven't considered enough responsive breakpoints or you haven't considered future features or future expanded data or future localizations, yet.)
But older versions contain lots of crap we don't need (eg <blink> tags) and miss out on useful stuff (grid layout).
Why not start with what is required for markdown formatting? Then build out from there.
> slowly working on my own browser engine
care to tell us more?
Sites often get that wrong. I'd say support motherfuckingwebsite.com subset: <p>, <a>, <h*>, <img>, <ruby> (i.e. markdown/gemini++) and do everything else with webcompat/fixbrowser way.
I am all for this. A completely simplified version of HTML without all the quirks and edge cases which have been added in over years + Javascript.
I wish for the same as well and have been asking for it for so long. Or a new Standard that could compile to a consistent subset of web standard with test spec available.
In this case it is better to make a new standard because HTML/CSS have so many legacy things and quirks that better be got rid of (like <hr> tag for example, table cell not inheriting font size etc).
What you have against <hr>?
You mean AMP without the BS