v0.1.3352 Oct 2026·Rendering, JavaScript & JIT, Web APIs & DOM, Memory & reading, DevTools, Tabs & interface

A developer-docs site works like the reference browser, and every frame gets its own built-ins

We took a developer-docs site, the web's main developer reference, and fixed everything that differed from the reference browser until its header, icons and interactive examples matched. That one site led to about forty engine fixes that every site benefits from: web components now construct and update at the same moments as in the reference browser, private class members belong to their own class, text measurement through ranges is real, and a JIT bug that could run the wrong code for a function from another script is gone. Each frame now also gets its own copy of the language built-ins, created only when it uses one.

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 12 changes

DevTools	A developer-docs site's Try it examples work. The interactive box under every reference page was blank; it now shows the code editor with the example, the Run and Reset buttons and the console, laid out as the reference browser lays it out, line numbers included.
Web APIs & DOM	A developer-docs site's header matches the reference browser: the navigation tabs, the blue logo, the login button and every icon (they were black squares). The causes were general: the CSS keyword initial, custom properties set to initial or left empty (the light-dark polyfill many sites ship), SVG colours from page stylesheets and from modern colour functions, CSS Shadow Parts, and icons drawn with mask-image.
Web APIs & DOM	Web components behave as in the reference browser. A custom element created by innerHTML, cloning or importing a template is built before the call returns, connected when it enters the page, and told about attribute changes before setAttribute returns. Lit components (a developer-docs site, a browser-support site and many design systems) depend on exactly that timing.
Rendering	Dynamic import() loads modules for real, with import maps and the page's content security policy, and a class's base is evaluated once, as the standard says.
Rendering	Private class members belong to their class. Two classes in one chain can each have a private member of the same name (Lit's mixins do this), and a class created over and over by a factory gets fresh private members each time. Before, they collided and the wrong method ran.
Rendering	Static class members have the right shape: methods are hidden from enumeration and fields are visible, fields run with the class as this, and assigning to a static setter calls it. That last one kept a developer-docs site's own analytics from starting.
Web APIs & DOM	Text positions are real. Asking a range for its boxes (how editors place the cursor and measure lines) now gives one box per line around the selected text, as tall as the font, exactly where the reference browser puts it. DOMRect can be constructed.
JavaScript & JIT	Fixed a JIT bug: a hot function compiled in one script and called from another could be analysed in the caller's code and run the wrong instructions. CodeMirror's line lookup returned a number instead of a line. Found by switching off each of the engine's 207 optimisations one at a time on the live page.
Rendering	Layout fixes found on a developer-docs site: a slot element lays out as its children, a grid item spanning a flexible track no longer widens its neighbour, percentage heights inside a grid resolve against the grid area, and an empty pre keeps its default margins.
Tabs & interface	Pages measured with script see a real window height while they load, so code that only measures what is on screen (editors, lazy loaders) does its work.
Memory & reading	Each frame has its own language built-ins: its own Array, Object, Promise and the rest, so a frame's changes stay in the frame and a page can get pristine built-ins from a hidden iframe, as sites do. They are made lazily, one constructor at a time when a frame first uses it, so a frame that touches only Array costs about 11 KB against the reference browser's 120 KB.
JavaScript & JIT	Smaller fixes: borders sized in rem through a CSS variable keep their size (a code-hosting site's borders were 3px), iframe sandbox, link relList and part are token lists, element properties like value exist only on the elements that have them, and Object.keys on an element lists what scripts set on it, in order.