Published results show a striking split: high pass rates in some DOM categories, but roughly 57% in Grid and Flexbox. That makes Northstar a useful engine experiment—and a reminder that web compatibility is uneven work, not a single score.
Summary
Northstar is an open-source browser written from scratch in C, without Gecko, WebKit or Blink. Its project description says it targets practical HTML5, modern CSS and JavaScript, and runs web-platform-tests. Published category results cited in the dossier show high scores in some DOM areas but roughly 57% in CSS Grid and Flexbox; those are per-area measurements, not a comparable overall score or an independent audit.
What happened
Northstar implements its own rendering and web-platform layers rather than embedding an existing engine. The reported test results are more revealing than a broad claim of standards support: some DOM categories perform strongly, while Grid and Flexbox are around 57%. That gap matters because a browser can handle many document-level behaviors and still struggle with layouts common to modern sites. The project’s changelog, as cited in the dossier, records concrete compatibility fixes—evidence of the iterative maintenance this work requires, though not evidence that any particular fix caused the reported scores.
What the archive adds
The archive shows browser projects taking different routes: Cloudflare’s Kitesurf update describes work on an agent-oriented browser, while Lightpanda is presented as a purpose-built headless browser. These examples put Northstar in a broader field of specialized browser engineering, rather than establishing it as a direct substitute for mainstream browsers. According to the dossier, Mozilla argues that engine concentration can constrain competition over web standards and privacy. That case for diversity is distinct from the practical question of how well a new engine handles real sites.
Trend signal
Browser-engine independence is both a competition question and a long compatibility grind. Northstar makes the engineering proposition tangible, but its uneven category results show why starting from scratch is not the same as reaching broad web compatibility. According to Mozilla’s argument summarized in the dossier, concentration can make alternative implementations harder to sustain. The counterweight is ongoing work: specifications, tests and successive fixes must converge across the many features sites depend on.
Why now
According to Northstar’s project description (d2), the immediate driver is an effort to implement a browser engine from scratch rather than depend on Gecko, WebKit or Blink. The project’s published category results make that engineering effort measurable in specific areas, including DOM and CSS layout. A broader motivation is competition: according to Mozilla’s argument in the dossier (d3), engine concentration can make alternative standards implementations harder to sustain. Those pressures make independent engine work relevant, but do not ensure that compatibility work will be funded or maintained.
Connections to other events
The surprising signal is the gap between strong results in some DOM categories and roughly 57% in Grid and Flexbox. This suggests Northstar can implement meaningful parts of the platform independently, while still falling short in layout areas that can determine whether a page is usable. The changelog’s concrete fixes illustrate compatibility maintenance as repeated diagnosis and repair, not a one-time engineering milestone. These results are per-area published measurements; they are not an overall score, a matched comparison with other engines, or an independent audit.
Why it matters
For browser engineers, the practical opportunity is to turn category-level failures into small, reproducible tests and fixes. For teams assessing Northstar, the results argue for checking their own CSS-heavy pages rather than relying on a general standards-support claim. A new engine’s value may be substantial as an experiment in implementation and diversity before it is suitable for everyday browsing; the CSS results help define where that distinction currently matters.
What happens next
- Northstar’s published Grid and Flexbox results will show measurable improvement from the roughly 57% figures cited in the dossier. (6 months, 55%). Watch for: A later published WPT report gives higher pass rates for Grid and Flexbox using identifiable category results.
- Northstar will continue to record concrete compatibility fixes in its changelog rather than treating the current results as a finished milestone. (3 months, 65%). Watch for: A dated changelog entry describes a browser behavior fix tied to a reproducible web-platform issue.
- The project’s published results will continue to show uneven coverage across categories rather than a uniformly high result across DOM and CSS areas. (12 months, 70%). Watch for: A later per-area results report still shows a material gap between at least one DOM category and Grid or Flexbox.
Limits and uncertainty
The figures and changelog are project-reported material cited in the dossier, not an independent audit. Per-area WPT results cannot be collapsed into one score or compared fairly with another engine without matching test runs and conditions. The evidence also does not establish how representative those tests are of sites people use, or whether future fixes will materially improve real-world behavior. Strong DOM results should not be read as proof of broad compatibility, and the CSS figures alone do not settle the project’s overall usefulness.
Skill to build now
Practise writing minimal reproducible CSS tests this week: choose one Grid or Flexbox behavior, create the smallest page that demonstrates it, record the expected and actual output in Northstar, and link the case to a relevant specification or web-platform test. This makes compatibility reports easier to verify and act on.
Reader takeaway
If you work on browser compatibility, build a minimal reproducible test this week for one Grid or Flexbox behavior that matters to your users. Run it in Northstar, record the expected and observed rendering, and connect the failure to the relevant web-platform test or specification behavior. That gives maintainers an actionable report and gives your team a more useful signal than treating category percentages as a general readiness score.
Open question
Can steady, test-driven fixes close Northstar’s Grid and Flexbox gap fast enough to make its strong DOM results matter to real websites, or will the web’s layout long tail keep the project specialized?