DomConverter should not trim whitespaces in nodes that neighbour with black–box elements (e.g. MathML) #5870
Labels
package:engine
squad:core
Issue to be handled by the Core team.
type:bug
This issue reports a buggy (incorrect) behavior.
Milestone
📝 Provide detailed reproduction steps (if any)
Note: I used my PoC code here that brings necessary conversion to load
<math>
to showcase the problem. But the issue isn't about the PoC code because it occurs before any conversion kicks in, which is at the raw HTML parsing stage.<math>
):✔️ Expected result
Spaces after "foo" and before "bar" should be preserved.
❌ Actual result
The later is gone:
📃 Other details
I debugged the issue, and the story is as follows:
DomConverter
there's a private method that converts native DOM nodes into text.<math>
and if it ends with some white spaces like, for instance, an indentation used to make the code human-readable (or like a trailing space from the TC), it figures this is it and gives a green light for trimming, which is obviously wrong.The white spaces in the
<math>
do not render like regular white spaces in a bold or something, so they should never be considered.We need a fix and here are some ideas:
DomConverter#objectLike
collection that would collect black–box elements. It would be used in the walker to prevent it from considering black–box content and thus, it would prevent the trimming.Element#namespaceURI
. I didn't test it but I suppose if we replaced<math>
with inline<svg>
(that is also formatted inside), we'd end up with the same issue.The issue was spotted when creating a PoC for MathML .
If you'd like to see this fixed sooner, add a 👍 reaction to this post.
The text was updated successfully, but these errors were encountered: