This is Safari as shipped in iOS Beta 18 - AppleWebKit/605.1.15 The "d" property for the SVG path element was previously not implemented in CSS / getComputedStyle. It is now half implemented and this is a serious problem - since it is now returning always "none" Reproducing: For example, this page https://codepen.io/igrecesc/pen/yLWKxPd?editors=1010 used to display just "Computed style for d:" on Safari. In other browsers it might display `Computed style for d: path("M 0 0 L 100 0 L 100 100 L 0 100 Z")` which is the CSS equivalent of the attribute. Outcome: In Safari shipped with iOS 18 beta this always displays `Computed style for d: none` regardless of the path attribute value. Expected: undefined as before or path("... as a fix forward Impact: This prevents our SVG workflows from making a meaningful choice (before, it was easier to reason about an unimplemented feature). We cannot assume that "none" should be falling back to reading the attribute since one path attribute could be present and a CSS style could legitimately override that to be none. Links: The start of the implementation https://commits.webkit.org/277297@main as tracked here https://bugs.webkit.org/show_bug.cgi?id=272446
This is already addressed on ToT as the feature is now behind an off-by-default flag until I manage to fix the performance regression issue caused by it. The latest release of Safari Technology Preview (197) has the fix and this will make it in an upcoming iOS 18 Beta (perhaps already in the second seed that just came out?). *** This bug has been marked as a duplicate of bug 274935 ***
Thanks for the quick answer! I downloaded the iOS 18 beta 2 and indeed it seems to be ok now, I'll follow up if something else is found wrong.
If we do re-enable the "d" property, I hope we do include the computed style implementation. I don’t know where we would keep track of that.
Re-enabling would include everything, including the computed style.