Issue metadata
Sign in to add a comment
|
getComputedTextLength() + textLength oddities
Reported by
philipp....@gmail.com,
Dec 11 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Steps to reproduce the problem: 1. Go to https://bl.ocks.org/Herst/raw/a304caf946e59a7e34c24bd828fa0b3a/?textLength=100 or alternatively open the attached test case and set the textLength to 100 (and press the enter key or trigger the "change" event somehow else). 2. Observe the displayed getComputedTextLength() return values displayed below each SVG. What is the expected behavior? The getComputedTextLength() return value would be expected to be around what the value set by the textLength attribute. What went wrong? The getComputedTextLength() return values differs quite a bit from textLength attribute value. In some cases it seems entirely unaffected by it (set the "textLength" textbox to empty to see how it is without textLength). Did this work before? N/A Does this work in other browsers? No Apparently Apple Safari 9.1 (according to browserstack.com) is similar to Chrome on this. Mozilla Firefox and Microsoft Edge are not (at least if spacingAndGlyphs is used in the case of Firefox). Chrome version: 63.0.3239.84 Channel: stable OS Version: 10.0 Flash Version:
,
Dec 12 2017
,
Dec 12 2017
@#1 Below the SVG it says "computedLen:", after this is the value returned by getComputedTextLength(). This return value is very different from "100" or any "textLength" value you enter, unlike in other browsers. This is what this issue is about.
,
Dec 12 2017
,
Dec 12 2017
getComputedTextLength() never was particularly well-specified. The SVG 1.1 definition [1] basically say "The total sum of all of the advance values...". The SVG2 draft defines it in terms of the getSubStringLength() method, but in practice I think it only differs from SVG 1.1 by not including contributions from 'dx' and 'dy'. SVG2 has a note which seems to indicate that the "user agent's calculation for ‘textLength’" is what's supposed to be returned - which I interpret as not including adjustments due to textLength. In Blink the behavior is fairly close to what SVG2 says, although I suspect that *-spacing may not be included. You can raise an issue on the spec (https://github.com/w3c/svgwg/issues) for clarification. [1] https://www.w3.org/TR/SVG11/text.html#__svg__SVGTextContentElement__getComputedTextLength [2] https://svgwg.org/svg2-draft/text.html#__svg__SVGTextContentElement__getComputedTextLength
,
Dec 12 2017
,
Dec 13 2017
Thank you, since this is a standards issue then and not a bug per-se it can be closed from my side (I shouldn't be one making that decision though). BTW, I came across this because I wanted to achieve that having text which just possibly shrinks to fit into text into a box but without expanding if the text width is smaller. If something existed where I could just make a text element behave this way then getComputedTextLength() wouldn't be needed (in this case), see also https://github.com/w3c/svgwg/issues/341
,
Dec 13 2017
FWIW, we're happy to change the behavior here if there's consensus around what the behavior should be (and it is clarified et.c.) I think we can close this until then though.
,
Dec 26 2017
The NextAction date has arrived: 2017-12-26 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by viswatej...@techmahindra.com
, Dec 12 20171.5 MB
1.5 MB View Download