White-space only text nodes.

[Tavmjong]

Relevant links:
https://www.w3.org/TR/SVG2/struct.html#XMLSpaceAttribute
https://www.w3.org/TR/SVG2/text.html#WhiteSpaceProperty

The attribute xml:space is used to control white space in SVG 1.1 inside elements. As this is an XML attribute, it presumably must also follow XML rules for handling white-space only text nodes (different from text elements) which dictate that a value of "default" results in the removal of text nodes that only contain white space:

<text><tspan>A</tspan> <tspan>B</tspan></text> => AB

<text><tspan>A</tspan> B <tspan>C</tspan></text> => A B C

This behavior is not clearly defined in either the SVG 1.1 or SVG 2 specs and neither Firefox nor Chrome seem to follow this. Inkscape has followed this behavior (except due to a bug, now fixed, introduced by a change in the libxml2 library).

If this interpretation is wrong, then text should be added to the spec to make it clearer.

Note XHTML2 sets xml:space to preserve for all elements.

PS. It's a real pain that we can't attach SVG files!

[fsoder]

Can you point to said XML rule (about white-space only text nodes)?

I know that we've willfully violated the white-space collapsing rules (using CSS rules like [1] essentially) since they are not very author friendly (as I believe would be obvious if applying said rules to your second example.)

[1] https://drafts.csswg.org/css-text-3/#white-space-processing

[longsonr]

Firefox basically flattens the text and applies the rules on the post processed text i.e. A B or A B C. That way adding tspan elements doesn't in itself change the layout. That's also compatible with html text processing.

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[dirkschulze]

Here the example in CodePen https://codepen.io/krit/pen/MZWeJd

It seems like all browsers render the text snippet the same and do not ignore the white space. @Tavmjong so you think xml:space is not compatible to the white-space property? If so, would we need to define the behavior of xml:space to follow the behavior of white-space in stead?

[longsonr]

That's how Firefox works right now. I.e it maps xml:space to CSS white-space

[css-meeting-bot]

The SVG Working Group just discussed White-space only text nodes., and agreed to the following:

• RESOLUTION: `xml-space` attribute does not affect parsing of whitespace nodes.

The full IRC log of that discussion

<AmeliaBR> Topic: White-space only text nodes.
<AmeliaBR> GitHub: https://github.com//issues/352
<AmeliaBR> Dirk: For SVG, we have the XML whitespace rule but we also have CSS property.
<AmeliaBR> Tav: Issue came up when updating inkscape. We actually strip whitespace-only nodes unless there is `xml-space="preserve"` (which we always add when we generate code).
<AmeliaBR> ... But I can't find an XML spec that recommends that.
<AmeliaBR> ... So I'd be happy with just keeping whitespace nodes always.
<AmeliaBR> Dirk: Are then other differences between them, or can we just treat xml-space as mapping to CSS.
<AmeliaBR> Amelia: That's how we've currently got it defined.
<AmeliaBR> Tav: It's a little complicated. xml-space strips out a lot of stuff. The Level 4 CSS spec adds in a new value for `white-space` that matches the `xml-space` behavior.
<AmeliaBR> https://svgwg.org/svg2-draft/text.html#WhiteSpace
<AmeliaBR> Tav: Browsers implement the attribute already.
<AmeliaBR> Amelia: Not consistently. I think only Firefox implements it fully.
<AmeliaBR> Tav: Yes, there was some issue about the inheritability of the attribute.
<chris> https://www.w3.org/TR/css-text-4/#white-space-property
<chris> https://www.w3.org/TR/css-text-3/#white-space-property
<AmeliaBR> https://drafts.csswg.org/css-text-4/#propdef-text-space-collapse
<AmeliaBR> Amelia: Could we move the new values from CSS Text 4 into SVG 2, and make that the stable definition for now?
<AmeliaBR> Chris: Looking at the Level 3 vs 4 definitions of `white-space`, I don't see any new values.
<AmeliaBR> Amelia: Looks like it's been moved to a new `text-space-collapse` longhand. The `preserve-spaces` value.
<AmeliaBR> Myles: I'm not sure what the issue is. Can we just defer it to CSS WG?
<AmeliaBR> Tav: I could do some updated testing on what current behavior is.
<myles> ++chris
<AmeliaBR> Dirk: The question is whether we need to do this now, or can defer the fix until later.
<AmeliaBR> Amelia: We could leave the current spec text, which has special rendering behavior for the attribute not defined in CSS. The issue about removing whitespace-only nodes sounds like its a non-issue per spec, from Tav's research.
<AmeliaBR> Chris: If there is interest in implementing the new keyword, I like the idea of moving it up to be a stable spec. We could discuss that.
<AmeliaBR> Dirk: The open issue is then what does `xml-space="default"` map to. Need testing for that.
<AmeliaBR> ... Can we resolve on not dropping white-space nodes?
<AmeliaBR> Eric: I don't think we should ever just drop nodes. That would affect JS and so on.
<AmeliaBR> Amelia: If Inkscape drops nodes as part of import/export clean-up, that's probably not a big issue, but that's not per spec.
<AmeliaBR> ... The issue is whether this was actually a parser instruction on the XML parser, that the nodes get dropped before the DOM is created.
<chris> http://www.xmlplease.com/xml/xmlspace/
<chris> +1
<AmeliaBR> Dirk: Can we resolve?
<AmeliaBR> RESOLUTION: `xml-space` attribute does not affect parsing of whitespace nodes.