Whitespace treatment in <tt>

[martinthomson]

I have a draft in which there is an important string that is breaking at a space (I have another case that breaks at the '/' character as well):

This particular example isn't that big of a problem, as there are other cases where the space appears correctly. However, as the space is critical to the functioning of the protocol, this is something I'd like to fix. Ideally without having to rewrite this text so carefully that the text and HTML renderings don't both show the issue.

There are probably elements other than <tt> that would benefit from the same sort of treatment, but it would be sufficient for this to be the only one affected thus.

CSS has the property white-space: nowrap; which might be used to prevent this sort of thing. Is there some way we can control the rendering of certain elements that might end up being rendered incorrectly this way?

(I realize that this is probably input to the discussion on RFC 7991 bis, but I've given up on trying to find where that discussion is happening. This issue at least memorializes this requirement.)

[kesara]

A temporary workaround is using   and ⁠ (word joiner).
Example:

<tt>message&#8288;/&#8288;bhttp&nbsp;request</tt>

[martinthomson]

Thanks @kesara, but doesn't that result in the HTML containing extra characters? It appears to include the word joiners, which would mean that someone who copies and pastes the text would get the (potentially invisible) extra character.

[kesara]

Yeah, they end up as invisible characters in HTML output.

[JayDaley]

Wouldn't it be straightforward to use CSS to ensure that the correct text is copied? (e.g. by wrapping the word joiner in a span that is made unselectable by CSS)

[jrlevine]

If it's important that the string be unbroken on one line, I'd make it <artwork> or maybe <sourcecode>

[martinthomson]

@JayDaley, that's even more complicated than what I was suggesting.

@jrlevine, that's possible, but it would be difficult in this case to ensure that all uses of the string appear on a separate line like that. We use the same string about 5 times. Ideally, all instances are available for copying without error. And a newline is problematic in the middle of a list (as in the image).

[cabo]

Handing through the equivalent of css nowrap has come up more than a few times for <tt. Much of the &nbhy and &wj usage would go away.
(&nbsp is often needed for text and harder to get rid of, unless we have a neutral span for nowrap, which is maybe better than a new attribute just for <tt.)
Definitely up for v3.1 or preferably the iterative process leading to that.

[JayDaley]

I've spent a bit of time building a web page with wj/nbhy/nbsp to see what gets copied to the keyboard and to see if that can be controlled with CSS. It looks as if that is a hard problem to solve, if it is solvable.

We should instead consider a new element such <term> that is rendered in HTML as no-wrap but has no specific visible styling applied. We should allow this to be used inside <tt>. This would be better than changing the styling of <tt> because a) we would have to check how that has been used elsewhere and b) people might not want the constant width formatting just to achieve a no-wrap.

[martinthomson]

That would work for me.

[cabo]

On 10. Mar 2022, at 20:56, Jay Daley ***@***.***> wrote: We should instead consider a new element such <term> that is rendered in as no-wrap but has no specific visible styling applied. We should allow this to be used inside <tt>. This would be better than changing the styling of <tt> because a) we would have to check how that has been used elsewhere and b) people might not want the constant width formatting just to achieve a no-wrap.

Exactly this. We might even call it <nobr>. (Ducks) Grüße, Carsten … and then we have to figure out how to represent this in markdown. Maybe together with sup, sub, … It also would be great to have a featureless span one can hang IALs on…