Should `br` break inline elements?

[pomek]

At this moment if you press Shift + Enter inside an inline element, <br> element won't be inserted as a chidren of the inline element. The <br> will break the inline element:

I'm not sure how it should behave. Is it correct? What if we would like to have the same link in both lines? Editing inline styles (like bold, highlights, font size, etc.) is not a problem. The issue appears if we would like to edit links that are split by the <br> element. But there is the separate ticket for it – https://github.com/ckeditor/ckeditor5-link/issues/192.

---

EDIT: See the workaround in this post.

[Reinmar]

From technical perspective it's a question whether <br> should inherit attributes from the $text. But what we need to discuss are the user experience and HTML-oriented perspectives.

[Reinmar]

cc @Comandeer

[Comandeer]

HTML specification allows using line break inside inline elements (or – to be more precise – inside phrasing content; block and inline elements were defined in HTML 4, HTML LS/5.x defines several other elements categories).

OTOH link is no longer only phrasing content, it's also flow one now, as it can contain flow content like div or sections.

[Reinmar]

Whether HTML specification allows line breaks inside phrasing content wasn't (I think) the question here. The question is – do we need that? From a semantic standpoint I can see cases where the content should contain e.g. <a>first address line<br>second address line</a>. Are there cases where merging e.g. subsequent <strong> elements into one that'd contain a <br> is not what the user would expect? If we don't see such scenarios, then it means that we can safely enable inline elements on soft breaks and all should be fine.

[DutchDave]

I noticed this behavior as well. And for the reason when removing the selection it would be nice to see the link disappear at once.

[mguidetti]

Is there any current work-around for this or progress being made?
I have an implementation that needs line breaks within a single link as @Reinmar described

From my example (an event listing), ideally the output would be:

<a>
Event Title<br> 
Event Date
</a>

But currently if you highlight multiple lines and create a link you get:

<a>Event Title</a><br>
<a>Event Date</a>

The main issue in my case is visual, as the hover effect is applied individually to each line when applying it to the whole block would make more sense.

[VesterDe]

We would really benefit from having this fixed, it's affecting our product development.

[Reinmar]

There are 3 part to this ticket.

1. Extending softBreaks schema

Adding allowAttributesOf: '$text', to softBreak's definition. This ensures data retention.

2. Fixing ShiftEnterCommand

Adding to the ShiftEnterCommand this bit:

 function insertBreak( model, writer, position ) {
-	const breakLineElement = writer.createElement( 'softBreak' );
+	const breakLineElement = writer.createElement( 'softBreak', model.document.selection.getAttributes() );

This will ensure that <br> inserted by the command is inserted inside a link (does not break it)\

TODO: Check whether insertContent() clears up attributes that might not be allowed on this <softBreak>. Ideally, the <softBreak> element inserted to the model should only inherit those attributes that are really enabled on it in the schema. It's realistic that the set of attrs allowed on <softBreak> will differ from the set of attrs allowed on a text.

In case, insertContent() does not clear disallowed attributes in this specific use scenario, use the Schema#setAllowedAttributes( softBreak, model.doc.selection.getAttributes(), writer ) to set only the allowed ones.

3. Fixing the selection attributes' discovery

Fixing the selection attributes discovery code that it reads attributes also from inline elements. Currently, it does not:

(Note: There are no selection attributes listed in the right pane)

Scope of this ticket

Let's cover the points 1 and 2 in this ticket.

The 3rd part (selection attrs discovery) is tricky and hence, worth moving to a separate issue. The result of not fixing this will not be very visible anyway.