Delete your RTL-detection script

An attribute for text fields. Add dirname and the browser submits a second field alongside the value: the direction the text was typed in, ltr or rtl. Chrome and Safari have shipped it since 2012. Firefox 116 completed the set in August 2023, and the 30-month clock ran out on 1 February.

Delete: the direction-guessing code. If your site stores user text that might be Arabic or Hebrew, something today inspects each comment to decide whether it needs dir="rtl" when displayed again, a client script or a server-side heuristic. The browser already knows; let it tell you.

−<!-- a script sniffs the value, fills a hidden field -->
−<input type="text" name="comment">

+<!-- the browser reports direction at submission -->
+<input type="text" name="comment" dirname="comment.dir">
+<!-- comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl -->

One seam at the edges. On input types where the spec says the attribute does not apply, current stable runs disagree: Firefox 153 and Safari 26.5.2 submit the direction pair for a month input anyway, while Chrome 151 and Edge 150 omit it. Keep dirname on plain text fields and textareas, where every current run passes, and treat the extra field as optional on the server. A browser too old to know the attribute never sends it: your default direction applies, and nothing breaks.

A clip-path drawn with path commands in CSS syntax: lines, curves, arcs, in any CSS unit. The path() function it improves on takes one SVG string and, as the spec puts it, implicitly allows only the px unit. The spec defines shape() as a superset of path(): the same commands, but percentages, em, var() and calc() all work, so a curved shape can finally follow the box it clips.

The scoreboard argues. webstatus.dev shows stable Safari passing a third of the suite, which reads like a Hold. It is not. The current Safari 26.5.2 run fails seven subtests, and every one is the same complaint: when style is read back, Safari keeps the default from start and from origin keywords instead of dropping them from the serialization. Every parsing and computing subtest for the geometry itself passes, as it does in the current Chrome, Edge and Firefox runs. Nothing renders differently.

Firefox shipped it last, on 24 February, so declare a fallback on the line above; a browser without shape() drops the declaration it cannot parse and keeps the earlier one:

clip-path: polygon(0 0, 100% 0, 100% 85%, 0 100%); /* older browsers stop here */
clip-path: shape(from 0 0, line to 100% 0,
                 line to 100% 85%, curve to 0 100% with 50% 80%);

Two footnotes. If your tests compare getComputedStyle strings for clip-path, Safari’s extra keywords will trip them; that is the entire defect. And Firefox Android has no current measurement: its newest test run predates the release that shipped the feature, so the low score there is a blank, not a fail. If it did turn out broken, the fallback line above is what those users would see.