Raw Handling: Distinguish between Paste and Conversion

[ellatrix]

Currently both paste and block conversion run through the same rawHandler function, stripping the same tags and attributes. The current filters are ideal for paste where we only want to preserve semantic tags that we think the user intended to paste. It's not so ideal for conversion existing content where we want to preserve as much as possible.

• rel and target attributes should be kept on anchor tags. See Converting To Blocks Looses Existing Anchor Tag Parameters #4498.
• We might want to keep any classes. Related: Updating existing content to Gutenberg doesn't honor existing attributes #5392.

What else is there that we should preserve? I remember there were a couple of other things (maybe with issues) but I don't recall.

[brandonpayton]

A couple other examples are:

• Lost ID's
• Lost ARIA roles and properties

It would be an improvement to handle these specific cases, but when converting existing content, is it appropriate to remove any attributes without translating them to something of equivalent meaning?

[danielbachhuber]

What else is there that we should preserve? I remember there were a couple of other things (maybe with issues) but I don't recall.

I think "what else" could be argued to be the entire HTML5 spec (e.g. #7057 (comment)). I'm not strongly opinionated that the entire HTML5 spec should be supported. However, if Gutenberg doesn't support it, then we'll keep seeing issues like #4498 (comment) open as users see their content modified unexpectedly.

[ZebulanStanphill]

@danielbachhuber I definitely think the entire HTML5 spec should be supported, or at least the parts of it that are not considered bad practice or deprecated or something.

[aduth]

Implementation-wise, this seems like it should be an option passed to the raw handler, not that the raw handler itself has knowledge of a distinction between paste or other conversion.

Re: Attributes support. As it stands, Gutenberg can't know how to apply any attribute it encounters in reserialzing a block. The validation is a representation of this, as it defends against content loss for this fact. In an ideal world, maybe Gutenberg accumulates the attributes it encounters while traversing in parse, allowing a block to be considered value so long as the element shape remains the same, then reapply the original accumulated attributes during the next serialization.

[aduth]

Quoting part of #6102 (comment) which I'd made forgetting that this issue had existed:

So while filtering the phrasing content schema could provide some improvement to classic block conversion, it might also inadvertently reintroduce some of the unwanted markup from these other sources.

Perhaps then if we consider the classic conversion to be exempt to filtering, or conversely the paste handling to be exceptionally strict, we could do one of the following:

• Bypass schema validation for raw handling of classic conversion
• Allow a 'raw' transform (specifically paragraph) to receive the "purpose" of transform (paste vs. convert) as an argument to vary the schema it produces.

[ellatrix]

Prioritising.

[ellatrix]

Duplicate of #6102.

[erictreelight]

I got here by way of "how to add a link to an image". (If there is a way to do it, I have yet to see it.)

That followed the question of "how to add an image to a bullet item", which turns out can only be done by "splitting the list" -- in actuality, by duplicating the list and deleting elements from each copy. (A process that needs to be repeated for each list item that needs an image.)

At least, I don't have a numbered list. For those lists, the task of splitting and renumbering borders on the impossible.

In short, as nice as Gutenberg may be for the developers creating it, I am so far finding it a giant step backward in terms of usability and functionality for a blogger.