Re: SVGTextContentElement interface broken

While wondering if the statements at developer.mozilla [1] were 100%
dependable, I got the expected confirmation that SVG2 [2] specifies
that xml:space
is “retained for backwards compatibility”, proving that the warning in [1]
makes false statements, in particular “Be aware that this feature may cease
to work at any time.”, while, as per the specification, it must not cease
to work. Unfortunately, as arbitrary as it may be, that statement proves to
be true.

Difficult now to guess if anyone can, or is willing to do something about
it.

Domenico

On Thu, Mar 11, 2021 at 2:38 PM Domenico Strazzullo <
strazzullo.domenico@gmail.com> wrote:

> Hi,
>
> The concerned methods are: getComputedTextLength(), getSubStringLength(),
> getStartPositionOfChar(), and getEndPositionOfChar().
>
> The task is to get the advance values in a string of rendered and
> formatted text.
>
> getStartPositionOfChar() and getEndPositionOfChar() are obviously the most
> appropriate for that task. But they fail. Then getComputedTextLength() and
> getSubStringLength(), which can both do the job (programmatically
> rebuilding the string one character at a time), were tested, and also
> failed. This is true for Chrome and Edge, while Firefox executes the task
> flawlessly using any of those four methods.
>
> I repeat, Firefox executes the task flawlessly using any of those four
> methods.
>
> What’s causing the failure (errors thrown on wrong “charnum” and/or
> “nchars” parameters -> freeze of the concerned text element) is the
> charCode 32 (space bar) – which, incidentally, can be replaced
> programmatically by charCode 160 (non breaking space) during after-input
> processing, and before using any of the aforementioned methods (but
> still… this would be just a cheap workaround).
>
> More precisely, double spaces and trailing spaces cause the errors, but
> also a single inner space depending on the method used and the proceedings.
>
> After puzzlement and then investigation, you learn that the "xml:space"
> attribute is deprecated in SVG2, and at
>
> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xml:space
>
> you read "Instead of using the xml:space attribute, use the white-space
> CSS property". But... in the Browser compatibility section you can see that
> only Firefox has full support, all the others showing the "Compatibility
> unknown" sign – at my expense I found out that Chrome and Edge obviously
> decided to break the support, even though it's nothing like common practice
> to break backward compatibility, quite the contrary.
>
> But that is nothing, when visiting the white-space CSS property page,
> Browser compatibility section, you learn that only Firefox – and defunct
> Internet Explorer – has full "Support in SVG"! All the others show a
> merciless "No". And not only that, the white-space CSS property is just a
> candidate recommendation in CSS Text Module Level 3. It seems then that
> somebody decided to take something fundamental out of SVG with the
> intention to replace it with an extraneous feature that is not quite there
> yet, and in any case not implemented. Did that/those persons even consider
> that SVG does not have the same text module as the markup language that is
> the natural target for CSS?
>
> Please, cancel the deprecation of "xml:space" in SVG.
>
> Regards,
> Domenico
>