Framework: Use custom serializer for texturize compatibility

[aduth]

Closes #3353
Previously: #4049

This pull request seeks to introduce a custom element serializer, removing dependency on react-dom/server (for renderToStaticMarkup) and improving compatibility with WordPress' wptexturize behavior.

Unlike #4049, it does not allow content to remain completely unescaped. Instead, it performs the minimal escaping as prescribed by the HTML specification:

the text must not contain the character U+003C LESS-THAN SIGN (<) or an ambiguous ampersand.

Source: https://w3c.github.io/html/syntax.html#writing-html-documents-elements

Therefore, unlike #4049, it should not suffer from unintentional HTML on the front-end (#4049 (comment)).

This pull request also includes related improvements to block validation, allowing boolean attributes with differing values to be treated as equivalent, as a boolean attribute is effective by its mere presence, regardless of value:

isEquivalentHTML( '<video controls="true"></video>', '<video controls></video>' );
// true (previously false)

It is important to note that while it it is expected to be, there is no presumption that the markup produced by this serializer must be safe. Server validation still occurs, and there is no effective difference to saving markup produced by this serializer and that added as arbitrary HTML to the classic editor's Text mode.

Unlike #4049, this does nothing to change or support additional shapes for Editable value, though it can be extended in the future to support such needs if desired.

Testing instructions:

Verify that no block invalidations occur upon saving and reloading the post. Demo content is a good place to start.

Verify that adding potentially "unsafe" characters (e.g. ampersand or less-than) to text, or other attributes (ampersand or quotes in additional class name) are properly escaped in serialized content (can verify in Code mode).

[youknowriad]

alt="" is an accessibilty concern, I believe these should be kept somehow?

[youknowriad]

It feels weird that the closing > is not automatically converted. I know this is not needed in the minimal requirements but how does the current editor work? Should we be consistent?

[aduth]

alt="" is an accessibilty concern, I believe these should be kept somehow?

From a content creator perspective, yes, alt is a requirement. So far as a serializer, my understanding through various readings published by standards bodies is that forcing an empty string is in-fact harmful:

The benefit of requiring the alt attribute to be omitted, rather than simply requiring the empty value, is that it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content, but for which not alt text is available.

https://blog.whatwg.org/omit-alt

Except where otherwise specified, the alt attribute must be specified and its value must not be empty;

https://html.spec.whatwg.org/multipage/images.html#alt

However, the specification does continue to describe an interpretation of img where alt is explicitly set to the empty string:

If the src attribute is set and the alt attribute is set to the empty string [...] The image is either decorative or supplemental to the rest of the content, redundant with some other information in the document.

https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element

One difference between this serializer and React's is that when an attribute is empty and not meaningful (either boolean or data-, aria- attribute), it is simply omitted. With above in mind, maybe I should drop this behavior and allow it to be written, if explicitly an empty string (still omit for nullish).

Alternatively, we could maintain a separate set of attributes for which the empty value implies significance, such as alt (maybe src, though I've not been able to track this to any supporting material).

One of my motivations was to avoid exceptions as much as possible, except where strictly needed.

[aduth]

It feels weird that the closing > is not automatically converted. I know this is not needed in the minimal requirements but how does the current editor work? Should we be consistent?

Personally I'd prefer correctness over consistency in this case. I don't feel strongly compelled to encode where not strictly necessary, for no other reason than because it may have been done in the classic editor.

[aduth]

Another thing I'll plan to add here: I think we can bake in support for RawHTML and drop our ugly post-serialize hack:

gutenberg/element/index.js

Lines 101 to 106 in 161f3f0

	let rendered = renderToStaticMarkup( element );
	// Drop raw HTML wrappers (support dangerous inner HTML without wrapper)
	rendered = rendered.replace( /<\/?wp-raw-html>/g, '' );
	return rendered;

[mcsf]

This is looking great.

Another thing I'll plan to add here: I think we can bake in support for RawHTML and drop our ugly post-serialize hack

Let us know once you'd like that reviewed too.

[aduth]

c0846d2 serializes empty string attributes verbatim, reverting previous changes to omitting alt and src for integrations.

f496200 builds in support for RawHTML to the serializer.

[mcsf]

Eager to see this one merged!

[mtias]

Nice work here!

[mtias]

@lancewillett you've run into some typography related issues before, would love if you can test this (curly quotes, etc) again when it lands on 2.6.

[lancewillett]

Left a comment after updating the plugin to 2.6.0 and confirming the expected behavior: #3353 (comment)