Element: renderToString incorrectly lowercases attributes

[bfintal]

Describe the bug
Calling renderToString from @wordpress/element incorrectly lowercases some attributes, for example viewBox turns into viewbox.

There are a number of SVG attributes with a capitalized letter in the middle: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute I would think that these are incorrectly lowercased as well.

Expected behavior
renderToString should work with attributes that have a capitalized letter in the middle.

[icurdinj]

To add to that - it seems to also remove hyphens from SVG attributes, e.g.: accent-height becomes accentheight, effectively making browsers ignore those, and breaking the SVGs.

[youknowriad]

I confirmed that this is a bug in our custom serializer, React's serializer is a bit different. cc @aduth

[aduth]

I've started to look at this issue, but have a few additional questions:

1. To the original request, does the fact that the attributes are lowercased make any meaningful difference, if the HTML is interpreted as case-insensitive in most any context?
   • Part of why I ask is in considering the implementation specifics, we rely in some cases on the lowercasing behavior to avoid needing to list individual attribute names which should be lowercased from their DOM-equivalent properties, for example contentEditable (DOM API property) -> contenteditable (HTML attribute)
2. @icurdinj, I was not able to reproduce this issue. Specifically, using an attribute with hyphens does not remove the hyphens. Are you able to share some problematic code?

wp.element.renderToString( wp.element.createElement( 'font-face', { 'accent-height': 10 } ) )
// "<font-face accent-height="10"></font-face>"

[kraftner]

Not the original reporter but concerning 1: Yes.

I for example use the Icon Component to create Dashicon SVG icons. But since the saved HTML is lowercased the block is always broken after first save with This block contains unexpected or invalid content.

[aduth]

@kraftner Could you share some specific code? I would expect that since both the block save serialization and parser compare content judged by running both through the same (lowercasing) element.renderToString, there should not be a difference in result. The warning "contains unexpected or invalid content" occurs only when the markup between save and parse is different (reference).

[kraftner]

I am sorry, when trying to create a reduced test case I realized I had another problem that caused this.

What got me off track was the fact that when clicking on the "Resolve" Button instead of highlighting my actual mistake (having the wrong selector in an attribute definition) the b/B issue of viewBox was highlighted.

[youknowriad]

If I'm reading this properly, there's no further fixing required. Let me know if I missed anything.

[ajlende]

I'm still having this issue with the lowercased 'b' in viewbox causing the "This block contains unexpected or invalid content" error.

The exact same code in ajlende/gutenberg-random-blocks works fine with renderToStaticMarkup from react-dom/server but not with renderToString from @wordpress/element.

Maybe my use-case is slightly different since I'm saving the rendered string to an attribute and then displaying it with RawHTML.

EDIT: Actually, this might be closer to the issue in #9898 (which is marked as closed but seems to have the most recent activity with other folks commenting on it)

[aduth]

@ajlende I think this is an issue with the validation logic, for which I've opened #18666

[acketon]

I'm running into similar issues. My block has some SVG elements in it that include preserveAspectRatio attribute on an <image> element in the SVG. It seems that on save it is getting lowercased to preserveaspectratio and when the block editor is reloaded and the validation runs the user is given an error saying the block is invalid. The block validator wants to make the attribute properly camelcase like: preserveAspectRatio.

[aduth]

Given that the behavior is consistent within @wordpress/element renderToString (consistently lower case), and this is what the validation process uses to compare markup, I would think it should only be an issue if you're bypassing the default element serialization (e.g. RawHTML, with or without a different serializer such as React's own renderToStaticMarkup).

[acketon]

I'm not bypassing anything... but I was able to resolve the issue. I found an unrelated issue in my block markup that was causing the rendered block markup to be different than the markup from the save() function in my block's code. (It was a sort of random key added to an attribute name)

What was odd was that the validator was failing focused on the camelCase of the svg attributes so I was focused on that and didn't see any indication of the diff being incorrect elsewhere in the markup. When I removed that bug and difference in the markup the validation doesn't have an issue with the case of the svg attributes. It is still lowercasing the svg attributes such as preserveAspectRatio but it doesn't seem to bother the validator now.

There does seem to be an issue though with the validator telling me the error was with the lowercase preserveaspectratio and not with the true error elsewhere in the block markup.