v0.1.31325 Sep 2026·Rendering, JavaScript & JIT, Tabs & interface

A large encyclopedia and a news site now sit where the reference browser puts them

We rendered twelve real sites in our engine and in the reference browser, compared them pixel by pixel, and chased every difference on the two furthest apart down to its cause. A large encyclopedia went from 17.7 percent of its pixels differing from the reference browser to 11.3, and a news site from 29.0 to 21.9, with no other site getting worse. The same hunt, following the errors a news site's scripts hit, turned up several deep gaps in how the engine runs JavaScript that affect a large part of the web, not just a news site. Those are fixed too, each locked in by a test that checks a whole family of cases rather than one example.

Parity with the reference browser

74overall, as of v0.1.343

Web APIs / DOM surface42

Security architecture66

GPU / graphics acceleration68

DevTools / extensions72

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

What changed 7 changes

Tabs & interface	Encyclopedia articles now start where the reference browser starts them. An empty notice box at the top of every article counted its spacing twice, the tabs under the title had their labels stuck to the top instead of centred, and small icons set to sit in the middle of a line pushed the text below them down. All three follow the layout rules exactly now.
Rendering	News pages with photo cards keep their columns. A photo sized to fill its card (the usual way to make images fit any screen) was treated as needing its full original width, which forced every card on a news site's front page wider than its column so the headlines ran into each other. Photos now shrink to their column, as the layout standard says and the reference browser does, in grids, rows, tables and inline boxes alike.
JavaScript & JIT	A very widely used script library works as intended. Many sites include core-js, a library that checks which JavaScript features the browser supports and replaces the ones it thinks are broken. Three of its checks failed on our engine, so it swapped out built-in features for slower copies, and one of those copies then crashed while starting up. All of its checks now pass, so it leaves the engine's own versions in place.
JavaScript & JIT	Scripts can ask what an object is made from and get the right answer. The questions JavaScript uses for this (the prototype chain: which template an object was built from) answered wrongly for lists, functions, errors, promises and more, and one of them always said no. Code that decides how to handle a value by asking these questions now takes the correct branch.
JavaScript & JIT	A common older coding pattern works again. When a script loops over a list with forEach, map, filter and similar, it can say which object the loop code should treat as itself. The engine ignored that everywhere, so code written that way (still very common in older libraries) failed.
JavaScript & JIT	Apps can build their own versions of built-in tools. Code like a cache that extends the built-in Map, a custom kind of Promise, or an event bus built on EventTarget (the standard way for app parts to send each other messages) failed or crashed. These now work as in the reference browser, including creating a plain EventTarget on its own.
Rendering	Page elements now behave like real objects with a shared blueprint. Scripts that add a feature to every element at once, or borrow a standard element method to use elsewhere (a very common trick in libraries), now work. Forty of the core page features a script can ask for that were missing are now there, such as checking whether an element has children, reading document.fonts, and editing text node contents piece by piece.