-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
White-space only text nodes. #352
Comments
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 |
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. |
Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone |
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 |
That's how Firefox works right now. I.e it maps xml:space to CSS white-space |
The SVG Working Group just discussed
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. |
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!
The text was updated successfully, but these errors were encountered: