Closed Bug 1417841 Opened 2 years ago Closed 2 years ago
The textpath has an offset x, the offset is shown on Chrome and Edge but not Firefox
Bug 1417841 - Don't reset <textPath> first character coordinate to 0 when an ancestor text content element specifies an explicit position coordinate.
59 bytes, text/x-review-board-request
Original from https://webcompat.com/issues/13506 Steps to reproduce: 1. Open the URL 2. Scroll to right, see 109 like this in Firefox https://webcompat.com/uploads/2017/11/b129097a-5b77-4904-b6fc-37988380b9eb.jpg <textPath xlink:href="#109" xmlns:xlink="http://www.w3.org/1999/xlink">109</textPath> in Chrome, it's above the yellow line https://webcompat.com/uploads/2017/11/23cd7d1f-5a86-420e-b538-38caeb05621a.jpg
The issue (as discussed offline) is that we always reset the position of the first <textPath> character to (0, 0), even if there are inheriting x="" / y="" positions from an ancestor text content element. It looks like other browsers don't do this. We still need to reset it to (0, 0) when there is no explicit inherited character, otherwise content like <text x="100">ABC <textPath href="...">DEF</textPath></text> would start the DEF text at 100 + advance("ABC ") along the path.
Assignee: nobody → cam
Status: NEW → ASSIGNED
Comment on attachment 8928923 [details] Bug 1417841 - Don't reset <textPath> first character coordinate to 0 when an ancestor text content element specifies an explicit position coordinate. https://reviewboard.mozilla.org/r/200268/#review205496
Attachment #8928923 - Flags: review?(longsonr) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/ee0d31af522a Don't reset <textPath> first character coordinate to 0 when an ancestor text content element specifies an explicit position coordinate. r=longsonr
You need to log in before you can comment on or make changes to this bug.