Re: SVGTextContentElement interface broken

 Hi Sebastian,

The test cases are from an input class, keyboard class (which both worked
seamlessly for over ten years), and input cursor class, which was added
recently, revealing then the problem.

Needless to say, the cursor is essential to handle all input situations,
and the methods in question, from the Javascript binding, are fundamental, as
that is what they were designed for.

While I obviously can’t post the code here, I can instead show you the
results when adding spaces at the beginning or end of line, or more than
one space anywhere in between. The method used is getEndPositionOfChar().

EXAMPLE. Using the word “AB”, these are the advance values you get in
Firefox; they are the expected values:

"AB"    —>    0, 8, 15                (no spaces)

"A B"   —>    0, 8, 11, 18          (1 space)

"A  B"   —>    0, 8, 11, 14, 21    (2 spaces)

" AB"   —>    0, 3, 11, 18          (space before)

"AB "   —>    0, 8, 15, 18          (space after)

The cursor gets positioned just fine, the spaces show, and life is
beautiful.

With Edge and Chrome it only happens for the first two cases. The others
produce this error:

“Uncaught DOMException: Failed to execute 'getEndPositionOfChar' on
'SVGTextContentElement': The charnum provided (4) is greater than or equal
to the maximum bound (4).”

Interestingly, when testing with getComputedTextLength() (where the string
gets rebuilt character by character as you type) an added space is always a
trailing space in the dummy text element, and for some reason you don’t get
errors. But you don’t get the spaces either! Also interesting the fact that
the overall length shows to be correct. The advance values of the spaces
are there, although showing the same value for each added space, even for
omitted spaces.

Here again, Firefox correctly returns the same values as above.

Though it’s true that xml:space does work in a static file, when instead you
add text programmatically through input, the methods in question fail,
meaning that the SVGTextContentElement interface of the Javascript binding
is broken. It possibly got broken after an inadvertent change. Even though
the browser vendors are ultimately responsible for it, things now seem to
prove that the design idea for the deprecation was probably overlooked. I
don’t need to remind that the browser vendors are active participants in
the specification making.

WHITE-SPACE

In the example
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xml:space

whether you say
white-space="pre"

or
text-space-collapse="preserve-spaces" (CSS-text-4 draft)

you won’t get the effect.

But if you say
style="white-space:pre;"

now that does it.

However, when I made all the tests again after replacing
xml:space="preserve" with style="white-space:pre;" in the topmost SVG
element, just to make extra sure, I got exactly the same results.

This means that the SVG specificators deprecated an SVG presentation
attribute in order to have it replaced by a CSS property designed by CSS
 specificators, with no SVG “attribute” syntactic equivalence. Then it’s a
matter of principles. If principles matter, this is wrong.

It wouldn’t be a problem if Chrome and Edge respected the specification in
terms of backward compatibility. But I have no intention to report this to
them because it would only start a windmills war (or just silence if you’re
lucky). It would be much more realistic if someone here would be willing to
rectify an absurd situation. It’s all about telling Edge and Chrome to
reactivate the feature for backward compatibility. That said, I don’t
actually know if the SVGTextContentElement methods ever worked at all with
dynamic text elements. In the past I only ever used getComputedTextLength() (on
static elements) and found it to work fine.

To conclude, I see two issues: one is the broken SVGTextContentElement
interface
in Edge and Chrome, and it remains to be seen how and why this happened;
the other is the rationale behind the deprecation of the xml:space
attribute, in particular to see if the repercussions brought by such a
change were exhaustively evaluated, and to determine if the current
problems with the SVGTextContentElement interface are a consequence of that
change/deprecation, or not. If not, then only Chrome and Edge can find out
why their implementation of the SVGTextContentElement interface is not
state of the art, like it is for Firefox.

Domenico