Scripts can read and change SVG the way they do in the reference browser, and a hidden hang is gone
Charts, maps and icon libraries talk to SVG through its object model: lengths with units, transform lists, view boxes, gradients. Floati had almost none of it. All 281 of the SVG members the reference browser has are now here, generated from the reference browser's own answers and checked on 1,604 cases every build. The engine's own checks also caught a rare hang: a common text-scanning loop could run forever once the code got hot. That is fixed, along with how regular expressions track their position, and a slowdown that switched off some of the engine's fastest paths on every page after the first. getComputedStyle now also lists all 475 CSS properties, like the reference browser.
Charts drawn by script appear




This chart is ordinary chart code: it sizes each bar through the SVG object model and places each label with a transform list, the way D3 and most chart kits do. On Floati those objects did not exist, so the script stopped at the first bar and the chart stayed empty. It now draws like the reference browser, labels included: SVG text also follows its transforms now, which chart axes rely on.
SVG you can script
D3, chart libraries and icon kits read and change SVG through objects: a rectangle's width as a length with a unit, a transform as a list you can edit, a gradient's units as a number. Floati had almost none of these, so those scripts saw nothing. Rather than write each one by hand, we asked the reference browser itself: a generator walks every SVG element the reference browser knows and records what each member is, which attribute it mirrors and how it starts. Every build then checks all of them on 1,604 cases: each one starts as the reference browser's does, and writing a value back leaves it unchanged.
A hang our own checks found
A very common way to scan text, looping until a regular expression finds no more matches, could run forever after the loop had run a few dozen times. The engine's fast path for that loop updated the expression's position directly, so when the fast path handed back to the slower one, the same step ran twice and the loop never found its end. Stateful expressions now stay on the exact path, and a new check runs these loops on every speed tier and compares them with the interpreter. Fixing it also brought replace, match, matchAll and split in line with the reference browser on how they move an expression's position.
What changed 10 changes
Try it in your browser
Each check runs live in the browser you are reading with. Nothing is sent anywhere.