Gutenberg: Block validation error for 'viewbox' attribute

[Michael-Ashfield]

Describe the bug
Gutenberg returns a block validation error when using the viewbox attribute in an inline svg when using the custom HTML block

To Reproduce
Steps to reproduce the behaviour:

1. Create a custom HTML block
2. Add an inline svg that uses the viewbox attribute
3. Leave and comeback to the editor
4. The block will now display as 'externally modified' and will show an error in the developer console:
   "Block validation: Encountered unexpected attribute viewbox."

Expected behavior
I expected any content I enter into the custom HTML block to be regarded as valid wether it is valid HTML or not as I develop custom HTML my way, at the least for valid attributes to not bring up errors.

Desktop (please complete the following information):

• OS: macOS High Sierra 10.13.6
• Browser: Chrome Version 68.0.3440.106 (Official Build) (64-bit)
• Gutenberg Version: Version 3.8.0
• Server: MAMP 4.4.1 (local host)

Extra context:
There are other unrelated errors reported on my page due to the absence of any container block, meaning that I have to place a rogue "<div class='my-container'>" above a set of blocks, then close it in a separate HTML element "</div> <!-- closes my-container -->" below the blocks, this is a hacky work around which produces invalid HTML errors, however they should not affect the viewbox error, as they are just expected errors looking for closing/opening tags.

[Michael-Ashfield]

To be clear, this is not a help request, I am reporting a bug. The viewbox attribute is in the SVG2 specification, SVG1.1 (second edition) and is described in detail in the Mozilla Web Docs.

In addition, after further digging, I found multiple issues with Gutenberg and SVGs.
Gutenberg will throw errors for valid SVG attributes claiming they must be lowercase, when infact they are camelcase in the specs (For example "linearGradient" will throw an error saying it must be "lineargradient" which is wrong). This error is pointed out in the edit but not the console it seems, however when it the attribute is lowercase, it is reported as an error in the console.

Gutenberg will also take issue with self closing elements in SVGs, which are used extensively in any SVG asset and is perfectly valid and inline with the specs(Paths for example ares elf closing). This is further heightened by the fact that the suggested closing tags ("" "" e.c.t.) are invalid and will cause even more issues. It is an issue in the console if you don't close the tags and an issue in the editor if you do close them.

SVGs seem to be a wider issue in the custom HTML editor block, upon further inspection. There is a distinct lack of communication between the console reported errors and what the frontend reports as errors, it is a lose-lose situation when trying to use inline SVGs.
This has been tested on a fresh install.

Sources:

• https://svgwg.org/svg2-draft/coords.html#ViewBoxAttribute
• https://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute
• https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox
• https://www.w3.org/TR/SVG/paths.html

[chrisvanpatten]

I've been experiencing similar issues today. SVG code inside HTML blocks are being interpreted as invalid/externally modified blocks on a page refresh, in addition to the above validation issues.

[johngodley]

This should be fixed in #10474. Note that an SVG is still likely to be transformed in some way, and this is being looked at in #10551. Marking this as fixed as the invalid block warning is no longer shown.

[jshwlkr]

I seem to be experiencing this issue in WP 5.2.2. ( Which is Gutenberg 6.1.0 I think?) Both in the custom HTML block and in a custom block with hardcoded SVGs.

[firxworx]

This is not fixed. WordPress 5.2.2.

viewBox and strokeWidth attributes fail validation if they are injected into a raw post directly as part of a block definition, when I try to edit the post with the Gutenberg editor.

In a block's save() function (as part of registerBlockType()), I define an SVG as part of the block and use the JSX strokeWidth and viewBox attributes. If I add my block in the editor (e.g. new post, newly added block) it works fine, but that's because WordPress is apparently mangling these attributes to strokewidth and viewbox respectively.

I can confirm this by creating a new post using the Gutenberg editor that features my block. If I use the WP REST API to view the raw post as it was saved to the database (via an authenticated request w/ &context=edit), I can see that these attributes appear as the incorrect strokewidth and viewbox.

The actual properties should be stroke-width and viewBox, see:

• https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-width
• https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox

Interestingly, when I actually view the markup sent to the browser, the mangled attributes are corrected, presumably by some WP filter.

This leads to an interesting situation where I am programmatically creating blocks using invalid attributes so that Gutenberg doesn't complain, where the invalid attributes don't line up to the JSX that corresponds to my block definition, and then some filter is correcting the invalid attributes before pushing them out to the client browser. This all seems very shaky. Ultimately I think there's still a bug with Gutenberg in play here that should be resolved.

[aduth]

@firxworx I agree this should not be considered an invalidation. For that task, I have opened #18266

As for the markup produced by Gutenberg: There is an issue at #12932 with some additional context. It's still unclear to me whether it makes a significant difference to output in lower-case. A workaround is possible for hyphened attributes to include the hyphen in the rendered element. That all being said, this seems like an easy pitfall, especially with the inconsistency from React, and I'd be inclined to reopen that issue.