This is similar to what was done with rich-text source before. It would create() here.

Isn't this change a little bit risky? e.g: some block may be comparing the attribute with undefining to check if the value does not exist and that may stop working now.
Also isn't there a risk a block may want to differentiate an HTML attribute being undefined (e.g: the query element was not found ) with an HTML attribute being empty (element exists but its content is empty )?
In this case, I would be inclined to just add a default value of the empty string in the merge function to reduce the risks.

(e.g: the query element was not found )

We currently already pass '' if the query is not found.

Alternative is to add default: '' everywhere.

And do you have a use case for the undefined? Note that ! value will still work.

If we already pass '' if the query was not found I think everything seems fine. I was not aware of that. Sorry, I thought we passed undefined when the query did not match any selector.

I'd prefer default everywhere or accounting for the undefined value in merges much more than to include ad hoc corrections in the factory.

It's also conflicting messaging when we went out of our way in #10338 to explicitly remove tolerances. If we'd kept the tolerances, I'd rather see something where we normalize undefined of type: 'string' to an empty string, but again still nothing targeting one specific source.

What's the issue with providing the default, aside from tedium / verbosity? I see it as no different (and thus extremely confusing in its consistency) from how we don't provide empty arrays for array types, zero's for number types, or an empty string for any other string types (what's the difference here between why we need an empty string here for assumed HTML stringiness and source: 'attribute'?).

At worst, I'd think we should codify this as a source-level default mapping.

I find it a bit weird that plugin authors will have to provide the default value, and may forget about it. Otherwise we have to set the default in merge functions etc., but since even we forget about it, I think block authors might also forget about it and cause these preventable bugs.

That's all well and good as a goal, but targeting a resolution for something so specific is going to have negative consequences (i.e. bugs) elsewhere in setting people up for mixed expectations for what is and isn't normalized on their behalf.

Okay, then let's change it. I'm not sure what the right solution is here tbh.

I think it's a reasonable expectation on the part of the block author that if they want to assume an attribute is a string (i.e. in concatenating), they should assure that it is one, via default.

This doesn't mean we have to add the default for every source: 'html' attribute, if we're not actually making such an assumption. I think it's also perfectly reasonable to not define the default if the stringiness is not assumed but instead accounted-for in the implementation.

See: #10756

This is interesting to me as well that it be required to test for. I understand it's a consequence of the multiline behavior, but (correct me if I'm wrong) it's still effectively an emptiness check, and as such it seems strange we'd need to fork logic for concatenating the value of an "empty" field. And also strange that, if it is a test of emptiness, that it not be something we could use RichText.isEmpty for.

Alternatively, should we account for this from RichText itself, never allowing '<p></p>' to become the value, but instead normalizing to--I assume--the empty string? This feels awfully reminiscent of inconsistencies we had ages ago with the RichText array vs. undefined values.