Tagging Editing-team since internal MediaWiki links display the same way with regard to line breaks, so perhaps the white-space: nowrap should apply to internal links as well.

Would it apply to mobile cases? e.g.

In T279706#6994560, @Etonkovidova wrote:

Would it apply to mobile cases? e.g.

Great question @Etonkovidova - I was going to say yes, but especially on mobile there could be cases where the link text goes over one line like this made up example:

Is there an alternative or addition to the white-space:nowrap proposed solution that we could adapt instead to also handle the above cases?
For example a way to break the middle section:

Nowrap tends to work out poorly for long links (such as titles), especially when used in small spaces (e.g. multiple columns). What's the problem with the current look? It feels quite natural to me.

The robot icon should be prevented from splitting off on its own, though. Probably needs a non-breaking space or zero-width joiner before the icon (although the ve-ce-nail elements might complicate things).

In T279706#6996003, @Tgr wrote:

Nowrap tends to work out poorly for long links (such as titles), especially when used in small spaces (e.g. multiple columns). What's the problem with the current look? It feels quite natural to me.

While it's not terrible in cases where the text goes over one line, it should ideally keep as a single element instead of splitting into two. It looks like a mistake to have the tag severed abruptly this way in cases where it can fit on one-line. This is why I suggested in the exception case to at least have some sort of indicator like an ellipsis for the tag continuing over to the next line.

The robot icon should be prevented from splitting off on its own, though. Probably needs a non-breaking space or zero-width joiner before the icon (although the ve-ce-nail elements might complicate things).

Besides it looking especially strange when the end icon is orphaned, there are also cases where the start of the tag is cut off before the link text:

VisualEditor is explicitly setting pre-wrap

.ve-ce-contentBranchNode {
    white-space: pre-wrap;
}

@RHo — what do you think of this solution (that doesn't use white-space: nowrap)? With this, we won't have a hanging empty box and the text won't break unless it does't fit, but the box does cover more area.

Before

After

In T279706#6996028, @RHo wrote:

Besides it looking especially strange when the end icon is orphaned, there are also cases where the start of the tag is cut off before the link text:

Yeah, that looks quite strange.

VisualEditor wraps the annotation with invisible images to support the behavior that there are two different cursor positions at the same text position (inside and outside the annotation). It seems like that caused similar problems in the past and those were infeasible to fix: T134571: Link cartouches interfere with browsers' word break algorithms so not sure how much we can do about this.

In theory we don't need those placeholder images as we disallow normal editing, but I imagine such a low-level behavior cannot easily be modified.

While it's not terrible in cases where the text goes over one line, it should ideally keep as a single element instead of splitting into two. It looks like a mistake to have the tag severed abruptly this way in cases where it can fit on one-line.

I don't get that impression. The missing border where the line box is broken makes it intuitive what is happening, and users are already familiar with the fact that hyperlinks can be interrupted by newlines. Currently the annotation behaves like a fancy type of highlighting, which is easy to understand as some form of highlighting is used by most editors when using similar dialog-driven tasks (such as search and replace). Changing the annotation's layout behavior would be a UX feature that users do not encounter in any other editor, and it would only make the interface more confusing.

This is why I suggested in the exception case to at least have some sort of indicator like an ellipsis for the tag continuing over to the next line.

That is very unlikely to be possible. Breaking an inline element into multiple line-boxes is low-level browser behavior that is, for the most part, not exposed to CSS or Javascript. Maybe Javascript could be used to insert the ellipsis to the right location, but even if that can be done (not sure how easy it is to tell via JS where the line breaks), it would be fragile as the ellipsis changes the length of the text and causes it to be laid out differently, so it could cause flapping and similar issues. Plus we would have to somehow prevent the ellipsis from getting treated like real text and saved.

And in any case, that would just make the interface more confusing IMO. How should the user know that those ellipses have a special meaning and aren't part of the link text?

@RHo @MMiller_WMF I'd like to propose we either put this in the post-release backlog or put it in a later week column (April 26 - 30, for example), after other key features for this project are finished.

In T279706#6999744, @mewoph wrote:

@RHo — what do you think of this solution (that doesn't use white-space: nowrap)? With this, we won't have a hanging empty box and the text won't break unless it does't fit, but the box does cover more area.

Before

After

Thanks @mewoph, I like this proposal! It solves the problem of empty start box fragments and orphaned robot icon end fragments, and keeps the exception case of when links are going over multiple lines on mobile to one single element.

In T279706#7000318, @Tgr wrote:

In T279706#6996028, @RHo wrote:

While it's not terrible in cases where the text goes over one line, it should ideally keep as a single element instead of splitting into two. It looks like a mistake to have the tag severed abruptly this way in cases where it can fit on one-line.

I don't get that impression. The missing border where the line box is broken makes it intuitive what is happening, and users are already familiar with the fact that hyperlinks can be interrupted by newlines. Currently the annotation behaves like a fancy type of highlighting, which is easy to understand as some form of highlighting is used by most editors when using similar dialog-driven tasks (such as search and replace). Changing the annotation's layout behavior would be a UX feature that users do not encounter in any other editor, and it would only make the interface more confusing.

This is why I suggested in the exception case to at least have some sort of indicator like an ellipsis for the tag continuing over to the next line.

That is very unlikely to be possible. Breaking an inline element into multiple line-boxes is low-level browser behavior that is, for the most part, not exposed to CSS or Javascript. Maybe Javascript could be used to insert the ellipsis to the right location, but even if that can be done (not sure how easy it is to tell via JS where the line breaks), it would be fragile as the ellipsis changes the length of the text and causes it to be laid out differently, so it could cause flapping and similar issues. Plus we would have to somehow prevent the ellipsis from getting treated like real text and saved.
And in any case, that would just make the interface more confusing IMO. How should the user know that those ellipses have a special meaning and aren't part of the link text?

@Tgr - I think @mewoph's proposal also solves my earlier brainstorm about including an ellipsis that you pointed out don't work so well for a few reasons (no bad ideas in brainstorming though! :p).

And @kostajh - I agree this is later/post-initial release priority.

I just realized that the fix for the annotation height issue on Firefox in T279684: [Design review] Visual design tweaks for the suggested link tags in Suggestions mode is the same as this solution I was trying before (making the annotation element inline-block rather than inline) so by accident, this should be ready for testing.

@mewoph -- since you put this in QA, does that mean it should no longer be in post-release backlog? (i.e. because you solved it?)

Yes, unless further changes come up post-QA.

@RHo I didn't see any issues anymore (checked both - desktop and mobile). If I noticed some cases during further testing, I'll report them separately.

The screenshots below are for illustration only - no issues are found:

(1) The link is split on two lines, but the recommended link is moved entirely to the next line

Real article	Recommended link surface

(2) "The Evolution of physics" recommended link is kept on one line
"Kitty Hawk, North Carolina" recommended link is kept on one line

Real article	Recommended link surface