Inconsistency in down-casting the UIElements

[niegowski]

📝 Provide a description of the improvement

I was checking why putting an UIElement inside some text formatted as a code is moving following part of that text and I realized that it's because we split all AttributeElements while inserting any element into the view (this is causing the content movement because a <code> element has the padding so it has 2 additional paddings inside after split):

ckeditor5/packages/ckeditor5-engine/src/view/downcastwriter.js

Lines 691 to 692 in f9ff247

	const insertionPosition = this._breakAttributes( position, true );
	const length = container._insertChild( insertionPosition.offset, nodes );

On the other hand, if we already have an UIElement and we wrap some content with an AttributeElement then we allow a UIElement to be wrapped with it (also EmptyElement and RawElement are allowed):

ckeditor5/packages/ckeditor5-engine/src/view/downcastwriter.js

Lines 1171 to 1176 in f9ff247

	// Wrap the child if it is not an attribute element or if it is an attribute element that should be inside
	// `wrapElement` (due to priority).
	//
	// <p>abc</p> --> <p><span class="foo">abc</span></p>
	// <p><strong>abc</strong></p> --> <p><span class="foo"><strong>abc</strong></span></p>
	else if ( isText || isEmpty || isUI || isRaw || ( isAttribute && shouldABeOutsideB( wrapElement, child ) ) ) {

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[niegowski]

I created a branch with the simple solution (the full solution should probably be able to handle multiple UIElements, but it seems to be a virtual case that never happens in real-life scenarios).

While thinking about this I realized that we could extend it to handle inline elements (like inline images) so the generated link would not break before/on/after the inline image but would be created properly on the whole range (I tested it with a simple flag isInline on the view element and it works perfectly in both view and data pipeline). Also funny thing is that it already works correctly in the data pipeline without any changes (just because of isEmpty check in the mentioned code fragment because an inline image is an empty <img> element).

[niegowski]

I have some questions about how to proceed with this:

1. Instead of checking isEmpty || isUI || isRaw while wrapping with an AttributeElement we could add a property to the view Element that would indicate that this element can be in-text (won't break an AttributeElement). This property would be exposed in the same way as getFillerOffset and priority. This seems like a very similar case to the priority property (and is used in the same context - DowncastWriter). And what would be the name of this property? allowInText?
2. Should we handle multiple in-text nodes in DowncastWriter#insert() or we can assume that it's a virtual scenario so there is no point in complicating code for it?

cc @Reinmar @scofalik