c.f. https://wpt.fyi/results/svg/text/scripted/getstartpositionofchar-dominant-baseline.html?run_id=5186421294366720&run_id=5159272738979840&run_id=5100859438923776&run_id=5131751863615488&run_id=5163365977030656 which regressed in STP 174 bisecting this points at 265525@main, from bug 139258 The test seems to be specifically testing that certain things don't depend on dominant-baseline; it may just be that this a bad test (previously bogusly passing because it relied on dominant-baseline being inherited), but it is nevertheless a test regression.
<rdar://problem/112420119>
Thanks @Sam, let me explore what is causing this failure, might not be immediate solution from my side but still will look into it.
So while this is indeed a test new failure due to making dominant-baseline inherited, it doesn’t reveal a new bug in our SVG text layout code. Manually inheriting the property shows the same issue.
Created attachment 467071 [details] test
Using these baseline properties with SVG text isn't super common, but I have seen people use it. There is a small risk of breaking content, without fixing the underlying SVG text layout problem. I think we should revert bug 139258 until we can fix the SVG text issue.
I am OK to revert this but at the same time, this change progressed two WPT tests (if I am not wrong) and helped us close three ancient bugs, we had.
Fixed by revert: https://webkit.org/b/259335 > I am OK to revert this but at the same time, this change progressed two WPT tests (if I am not wrong) and helped us close three ancient bugs, we had. I think we do want to try to fix this test if we were to reland this.