GHS: Preserving empty inline elements. #14406
Conversation
…ggered so mutation observer won't trigger false alerts.
…rsing input data).
| editor.data.htmlProcessor.domConverter.registerInlineObjectMatcher( element => ( | ||
| element.name == definition.view && element.isEmpty ? { name: true } : null | ||
| ) ); | ||
| // TODO should it affect spaces vs NBSP in editing pipeline? |
There was a problem hiding this comment.
TODO - resolve before merging.
There was a problem hiding this comment.
I'm not sure if an inline object should affect whether NBSPs are rendered around an inline empty element.
Editing view not aware of empty inline object:
Editing view aware of empty inline object:
Data output (no matter which option). If rendered as style: inline-block the spaces are visible, otherwise space are collapsed to a single one.
The main problem is that rendering of an inline empty element depends on the style of that element (if it is an inline-block or not).
cc @Reinmar
There was a problem hiding this comment.
Another approach would be to ignore empty inline elements without any attributes. There still are some side effects but maybe this would be good enough. We simply do not know if the custom CSS class sets the style display: inline-block on the given element.
Suggested merge commit message (convention)
Feature (html-support): Introduced configuration option to allow empty inline elements. Closes #9888.
Other (engine): The
DomConvertershould allow registering custom matchers to detect inline object elements. See #9888.Other (source-editing): Fixed formatting of
<br>elements in source editing. Whitespaces before<br>element should not be added.Additional information
For example – encountered issues, assumptions you had to make, other affected tickets, etc.