Hacker News Reader

The complexity in supporting CSS does not come (primarily) from its individual properties, no matter how obscure. It comes from things like margin collapse, from correctly determining the stacking context, and about a gazillion other things like that.

These aren't things where you can just scan the CSS of the top websites to find out if they're being used. These are things where you'd have to do visual comparisons to the output of at least two other browser engines to determine if you end up with the same result.

Building a browser engine from scratch is imho more doable now than it's ever been before (excepting EME), due to the insane effort by the WHATWG standards to truly describe what is actually happening in browsers (rather than coming up with some theoretically pure description of what is envisioned to happen), and the similar level of detail on the CSS side to the myriad interactions between properties, along with the huge set of testcases for all of that.

Yes, there's _a lot_ - but compared to how loosely specified it all was in the past, when the instruction for building a browser engine was: "reverse engineer the bugs the dominant browser engine of today made in reverse engineering the bugs of the dominant browser that came before, and emulate that to your best ability", anyone starting from scratch nowadays has a way better chance at succeeding.

> These aren't things where you can just scan the CSS of the top websites to find out if they're being used.

I guess I was drawing a distinction between a certain subset of functionality that's definitely being used constantly everywhere, like the core box model, vs new features that have gotten layered-on over time and specifically designed not to interfere with or change what came before. For example, the CSS Grid standard has zero effect on any part of page layout unless it is explicitly invoked with "display: grid". These hard barriers were drawn to maintain backwards-compatibility, but they could be leveraged to carve out pieces of functionality to not support, or at least defer support for.

> Building a browser engine from scratch is imho more doable now than it's ever been before

I agree. And I would actually add Rust as a factor for that. Don't forget, Rust was literally purpose-built for building a web browser. With its focus on memory safety and safe concurrency, I'd bet it will act as a very real force-multiplier when it comes to a project like this. Devs will spend that much less time chasing down race conditions and memory errors, while at the same time getting something highly parallel and performant.

“due to the insane effort by the WHATWG standards to truly describe what is actually happening in browsers”

I wonder whether one could reuse testcases from other browsers. Might be easier than having humans translate those WHATWG descriptions, written for humans, into a form that computers running tests can use.

And nitpick: it isn’t easier than ever. It was a lot easier for Tim Berners-Lee and the first few other browser writers, before there was a lot of agreement on how a browser was supposed to behave. Certainly, before JavaScript and css, SVG, XML, etc. The scope was a lot smaller.

> I wonder whether one could reuse testcases from other browsers.

Even better: there is a shared set of test cases and infrastructure that the web standards and compatibility folks have built: https://wpt.fyi

My favourite example of the thousand-yard-stare horror of web specs is Manish's "Font-size: An Unexpectedly Complex CSS Property". It's awful and hilarious and just keeps getting worse and worse and worse.

https://manishearth.github.io/blog/2017/08/10/font-size-an-u...

Yeah so this is exactly the kind of thing I'm talking about:

-----------------

The syntax of the property is pretty straightforward. You can specify it as:

- A length (12px, 15pt, 13em, 4in, 8rem)

- A percentage (50%)

- A compound of the above, via a calc (calc(12px + 4em + 20%))

- An absolute keyword (medium, small, large, x-large, etc)

- A relative keyword (larger, smaller)

The first three are common amongst quite a few length-related properties. Nothing abnormal in the syntax.

The next two are interesting.

-----------------

I've been doing front-end web dev for nearly ten years, and I've never even heard of those last two, much less used them. That's the kind of thing a new browser could defer support for until after the MVP, while barely detracting from the average user's experience.

Though this does remind me that i18n is a thing, and how gnarly of a problem it must be for a piece of software so concerned with text flow/layout, and ideally it's not something that a theoretical upstart browser would punt on.

While I think you're right that the last two are very uncommon, they are not a large contributor to the complexity of handling font sizing. Once you've done all the rest, I suspect you could add them with <5% more work.

Leaving out rare features to build a browser more quickly only makes sense if those features let you remove a lot of complexity from your implementation.

When it gets to the point of diving into the last two, the article literally says:

> Alright, this is where it gets complicated.

I haven't implemented any of the above myself, but the author at least seems to think the last two are where the complexity is concentrated.

Sorry, you're right. I've gone back and read the article and there was complexity in those two that I had completely forgotten about.

> I've been doing front-end web dev for nearly ten years, and I've never even heard of those last two, much less used them.

Huh, that's interesting to hear you say that. I hardly do any web development at all, but I was using both of those things for personal/toy web sites over a decade ago.

Just goes to show you that even rank amateurs can end up exposed to things that professionals haven't seen, for whatever reason.

If people feel the need to use text inside their <canvas> elements, I've done some (not very rigorous) research on how JS engines interpret font size instructions in their canvasRenderingContext2d environments:

- Absolute size keywords ('xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', 'xxx-large') may-or-may-not work — and the resulting size may-or-may-not have a relationship to the <canvas> elements surrounding environment.

- Relative size keywords ('larger', 'smaller') can be hit-and-miss too.

- Absolute length values, defined with px, pt, in, cm, mm, pc, will usually work as expected.

- Viewport lengths (vw, vh, vmax, vmin) will often work; note that these lengths are set on creation and don't automatically resize when the viewport dimensions change.

- For lengths defined by the font itself, rem will use the root element's font size for its reference; %, em, ch can be less helpful. Again these won't automatically resize in a responsive environment.

- Of the rest, Q is not supported by Safari browsers, while cap, ic, lh, rlh, vb, vi are not supported by any browser. Avoid!

Maybe it's time we create a new html rendering engine by training a ML model using w3c specs and tests as input.

Hmm, you might be onto something here. Someone created a react layout generator using gpt3 that translates natural language description into actual layout. Maybe some ml models can be developed to render a layout from HTML content. No need to perfectly render it, just 80% approximate would already impressive enough.

I've been wondering for a while if we could create an extremely simplified rendering engine that would only accept modern markup and css:

- forget everything about quirksmode and all kinds of workarounds that browsers have today.

- only accept Javascript from a vetted repository that contains things like autocomplete and ajax reload.

- and here comes the smart part: embed it next to an ordinary engine, ideally in Firefox, add a meta tag or content type or something that will get the browser to try to render it in this engine.

1. The idea is to get it to run extremely fast, and

2. get a few websites to optimize for it (Wikipedia?)

3. once people recognize certain pages loads extremely much faster in that browser they'll flock to it

4. more sites will start optimizing

5. since Javascript is extremely limited we get back to a saner content web

A better use case for this engine would be Electron replacement.

Much easier to get adoption if you can demonstrate performance benefits and electron apps are more performance sensitive than webpages in general (who really cares about Wikipedia rendering speed - it renders fast enough)

Have a look at https://github.com/cztomsik/graffiti.

You may be interested in a project that's doing almost exactly that: a new content type that sits alongside the "classic" web, with a heavy focus on performance and only JavaScript from a vetted repository allowed.

https://amp.dev/

Isn't this the thing Google is pushing?

If so it has some huge downsides that overshadowes it.

What downsides does AMP have that your proposal would not?

Another way to think about this is, people were already thinking along these lines and tried to build something, and that thing is AMP. If you want to build something that avoids the failings you see in AMP, you're going to need to think hard about how your plan is different.

For starters I'm not suggesting

- that everyone has to serve all their content from a single domain. I only suggest serving optional Javascript from a single vetted repo.

- that the distribution repo should be owned and controlled by one if the worlds largest advertising companies.

- that the solution only should cover mobile.

Those are mostly not the case anymore for AMP; the only one that looks correct to me is that AMP documents have to include the AMP runtime. If you wanted to make a pure HTML+CSS page, with no JavaScript, I can't think of any technical reason why the AMP specification couldn't be extended to consider that valid AMP. I think the main question is whether there are many sites that would be interested in serving that way?

For your other points:

* The AMP project is now part of the OpenJS foundation, along with Node, Electron, and others: https://openjsf.org/blog/2020/06/23/openjs-world-day-one-hig...

* AMP is not specific to mobile, though it did start that way; there are sites that serve all of their pages in AMP format to both mobile and desktop users.

(Disclosure: I work for Google, speaking only for myself)

> If you wanted to make a pure HTML+CSS page, with no JavaScript, I can't think of any technical reason why the AMP specification couldn't be extended to consider that valid AMP.

Meaning that right now it isn't that way, right?

> The AMP project is now part of the OpenJS foundation, along with Node, Electron, and others: https://openjsf.org/blog/2020/06/23/openjs-world-day-one-hig....

For some reason everyone still seems to associate amp with Google, and the only times I can remember finding AMP pages are when I search with Google.

If a site is technically AMP but served from a non Google domain, I admit I haven't noticed it.

> Meaning that right now it isn't that way, right?

Correct, the current spec doesn't allow that. But, as I said, I think that is something that could reasonably easily change if many sites wanted to publish with vanilla CSS and HTML.

> For some reason everyone still seems to associate amp with Google, and the only times I can remember finding AMP pages are when I search with Google

Google started the project, and is still by far the biggest contributor. But Bing also supports AMP, caching and serving AMP pages: https://www.bing.com/webmaster/help/bing-amp-cache-bc1c884c

> But what if you didn't have to implement all of them?

People will very much tend to prefer using browsers that are fully capable. If your browser only works on 90% of sites, that's not good enough to keep users, it's exhausting to keep switching back and forth.

To escape the modern web, you have to offer something that the modern web can't which people are willing to go out of their way to get.

Some ideas: privacy, anonymity, no tracking, no DRM, global identity (pubkey based). I don't know if any of these would actually be sufficient to drive a new market, but I think creating a new market is the only way.

> global identity (pubkey based)

Pubkey based is good, but a global identity is a recipe for disaster. Ideally, you derive a unique identity per domain, while still managing only a single (master) key pair at the user-level.

The way Firefox initially solved this was with a user-facing version of the Strangler pattern: IE Tab. You could simply tell FF that a given URL needed to be rendered by IE and that would be the case inside your otherwise strictly FF browser. It worked perfectly. That pattern could be reused in such a scenario I guess.

This is briliant. It means bundling Chromium. But it could work.

IE Tab was an extension, never a native feature. It was one of the many innovations allowed by the open extensions API, allowing anybody to make major features without formal approval.

That isn't how it was. When Phoenix was initially released, it was running the Netscape rendering engine with everything else stripped away. There was no IE Tab. Throughout the process of becoming Firebird, and then Firefox, IE Tab was never part of the core browser or default installation. I know: I ran all of these browsers as they came out.

Even though many sites were built specifically for IE, it was very rarely bad enough that you couldn't manage with Firefox. Compatibility hadn't gotten that bad.

(If you were going to make a dramatically simplified browser today, however, I do think this would be an excellent route to go.)

> Some ideas: privacy, anonymity, no tracking, no DRM, global identity (pubkey based).

These are strongly in conflict with each other: if you have global identity what keeps that being used for tracking? This is the controversy around advertising IDs in mobile apps.

I'd pay money to see how would a bunch of mainstream users would react if they only had https://lite.cnn.com/en or https://text.npr.org/ and similar variant for online services (granted a few pics allowed for shopping)

ps: 10$ more on a 'this lowered my medical bills' outcome

I enjoy the lightweight web too, but I want to stress that that's not what I'm advocating for here. You can't simply expect the population at large (or perhaps more importantly, the corporate community at large) to seismically shift the way they're doing things for the sake of web idealism. You have to meet them where they are. What I'm talking about is finding a pragmatic way to do that.

yeah I get it, and I totally agree, radical migrations like that would fail

but I'm still willing to bet on how a week of ultralight web would feel to them :)

> But what if you didn't have to implement all of them?

In that case the browser would fail to render or even load some websites, which would convey the idea that the browser was a poor piece of software.

Usually when a feature - especially a CSS feature - is missing, a site degrades gracefully. This varies between features of course, which could be another factor in prioritizing them: how dramatically will the absence of this break something?

But if a CSS property is invoked that the browser doesn't know about, it simply ignores it and moves on. The same goes for HTML tags and attributes. This is less true for JavaScript features because accessing a field of an object or attempting to call a function that doesn't exist will throw an exception and cease execution. Though on sites whose JS is mostly peripheral to the content, this can still sometimes result in a mostly-functional site. You could also play a game where you stub out enough of the APIs to prevent exceptions being thrown, without actually fully implementing the features. i.e. make an API function callable, and just not do anything.

The idea isn't to write off parts of the web entirely, but to be smart about how things are prioritized and aim for graceful degradation of the overall experience, as a way of dramatically lowering the bar for what it takes to make a browser that could be reasonably used day-to-day.

Initially I imagine anyone who downloaded this browser would know exactly what they were getting into. I'd download something like this if it was noticeably faster and leaner than other browsers, as long as I could do some kind of quick switch to another, like I do with bangs for Google on Duck Duck Go.

The quick-switch idea is interesting. I don't really know how it would work here (embedded Chromium?), but I think the analogy to DuckDuckGo is the right one. DuckDuckGo started as a service for privacy-enthusiasts, and as privacy awareness has become more mainstream we've seen mainstream adoption of it despite its shortcomings compared to Google's results. It a) offered something Google couldn't, and b) became "good enough" on the other axes, and that was enough for regular people to adopt it.

I presume it would in a similar fashion to Zoom on Mac (I have't used Windows in a while) where Firefox prompts you to open a Zoom meeting link in another application (i.e. Zoom), which you can ask FF to remember so the link is automatically opened with that app next time.

Hmm. I think the destination app has to support that directly though, doesn't it? http: links should automatically go to your default browser, of course, but that would require that this new browser is not your default browser. Maybe you could hack around it in some way; I'm not a native desktop app developer so I don't really know just how much leeway one of those has within the host system.

This could be coupled with a search engine that indexes the pages which such a browser has been tested to display correctly.

So you start off with a small index that includes Richard Stallman's web site and a few thousand others, then add many more as things like flexbox or whatever get added.

That feeds in nicely to the development process. The implementation of each new feature has the potential to open up thousands more sites to the index. In fact you could list bounties not in dollars but in the number of new sites a given feature can bring to the index.

That way users look at the search engine to first discover the sites that work in the browser. You could go retro like the hand-crafted directory Yahoo used to use, or automate the process. Either way, it's a big improvement in UX. Compare: "While the supported sites do load fast and look great, their search doesn't cover enough sites for my browsing needs." To: "Wouldn't even load Reddit this thing looks hopelessly broken."

I bet that it wouldn't take too much effort to get such a project to a place where you get a sizable index with the core feature being the lack of inclusion of sites with dark patterns. Like, an hour spent in this browser is filled with 80% critical reading whereas you'd just be infinitely scrolling through memes 80% of the time in Chrome...

You still need a fallback solution for cases where the website doesn't work with your version of the standard. Otherwise, users would be very disappointed, and they would switch browsers very quickly.

I like the idea, but the migration path needs some serious thinking.

The idea is to make a "best effort" solution. Once it's good enough, it could be tolerable for regular users. The next step would be to offer something new, that Chrome doesn't offer, that's compelling enough for the average person to stick with it despite the occasional hiccup. I don't know what that would be. It could be a genuine privacy guarantee (due to the lack of profit-motive), it could be less bloat and therefore longer battery life on their devices. Or it could be a UX-level rethinking of how a web browser is structured.

Though for semi-enthusiast users (HN readers), who want things to mostly just work but are willing to put up with some minor discomfort for the sake of idealism, that second part may not be needed.

Opera tried that approach for years and failed to make any sort of meaningful impact

The story could be different with a dedicated foundation of enthusiasts, backing a fully open (read: not-for-profit) project. It could also not be. We don't know until we try.

Even if most websites only relies on 50% of the web spec out there, it's likely that many of them rely on a slightly different 50%. That would mean the "common" area needed for a good average experience is significantly larger than 50%.

I think this is the trap that non-Chromium MS Edge fell into. I don't doubt that they supported a large subset of websites very well, but the average experience was brought down a lot when it randomly broke or massively slowed down on random websites.

The MS Edge case also suggests that it's not enough to just support a standard, it must also be reasonably optimized, because websites can be intolerably slow otherwise. I think many websites, especially web apps, assume that the user's browser is quite fast and can chew through a lot of load.

> I'd bet that 90% of the web only uses 50% of the web standards out there.

If implementing 100% of web standards is intractably large and complex, then:

Implementing 50% of web standards is intractably large and complex too.

Unfortunately, you can't turn a humungous problem into a friendly little one by dividing by 2.

I would think in terms of dividing by 10 or more. How much of the web only uses 10% of the web standards? My guess is most of it, so we have a chance.

> Taking this further: how do we know which features to prioritize? Most front-end devs probably have a rough idea, but what if we got empirical with it? What if we automatically tested the top 10,000 websites or something and made note of which CSS properties they used, which JavaScript APIs they called out to, and ranked them by frequency (and by popularity of the site?). We could chart a clear, direct path toward "what does it take for a browser to be useful in 2020?"

This would be great data. Something a bit like caniuse, but showing feature usage rather than browser usage.

Getting this data and maintaining it is a full-time job for a team. You can't just fetch the front page of sites to get this info. You need to login and use functionality. Perhaps existing browser telemetry would do a better job, letting users generate the data during normal activity.

However you do it, the cost of this idea is mounting up fast :-)

> I'd bet that 90% of the web only uses 50% of the web standards out there

The problem is the same one faced by people trying to build MS Office competitors back in the 90s and 00s: while that's likely absolutely true, they don't all use the same 50% of those standards/features, so you end up having to implement all of them, or your users will blame you when their favorite random niche website doesn't work, and ditch you for Chrome.

It's a shame that the web/browsers have grown up to be so forgiving of shitty markup that isn't valid.

The experience would be much better for the user if it was all strict, as I suspect things would be faster.

Congrats, you just reinvented XHTML :)

Most HTML is generated by frameworks now, isn't it? Is there a lot of non-matching HTML in the wild anymore?

How would it be better for the user if half the web sites didn't work?

I don't think it would have any observable effect on speed. As far as I know, the bottleneck is not parsing the the html syntax, it is rendering.

Mosaic tried to be strict. Netscape was more SGML-like and so it was a slow slide as people said, “well it works in Netscape, so it must be a bug”.

The early authoring tools also generated pure garbage for markup. So if you weren’t forgiving, you lost users.

Pandering works.

I had a similar thought: Why not build a browser-generator? Some nice presets and checkboxes for options and a single shiny "Build" button. This can't be too difficult, am I right? It would give users the explicit responsibility for broken pieces and also some nice performance gains.

I think there's a great case for a browser which defaults to Reader Mode. Reader Mode is always a better experience when it works. And then build up from there.

And here, dear reader, you have witnessed the birth of new Internet Explorer. Half the standards of a proper web browser with twice the opinions!