1948666 - leading hyphens should not be considered for line wrapping

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Benno Schulenberg]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Looked at https://nano-editor.org/dist/v7/nano.1.html#gohere .

Actual results:

Saw:

...other files for viewing, unless --
restricted is given too.

and:

...the opposite of -b (--
breaklonglines)

Expected results:

Should have seen:

...other files for viewing, unless
--restricted is given too.

and:

...the opposite of -b
(--breaklonglines)

In other words, the double hyphen is a special kind of "code": none of its hyphens should be considered as a place after which the line can be wrapped.

Another example: imagine a piece of text contains "Do something like: grep --recursive word." One does not want to see this wrapped as:

Do something like: grep --
recursive word.

(Which is exactly what I saw while typing this into this text field.)

Comment 1

[Francesco Lodolo [:flod]]

I see exactly the same behavior in Chrome, so I expect this might be by design.

Comment 2

[Jonathan Kew [:jfkthame]]

Yeah, I see the same in Safari as well. And in non-browser text editors (e.g. TextEdit.app, Pages.app).

And it's not just about double hyphens: on that same Nano page, I can get a line-break to occur between the single - and b in "the opposite of -b ..." if I adjust the window width slightly.

That's just how hyphens are: they introduce a potential line-break position immediately after themselves. (Actually, Chrome and Safari even allow a break to occur between the two hyphens of something like --breaklonglines. Firefox avoids this; it keeps successive hyphens together as a unit.)

Trying to prohibit breaks after double hyphens would almost certainly have unwanted effects on other examples, such as when people write a double hyphen (standing in for an en-dash, perhaps) in a range like "1997--2013", and want the line to be able to break if necessary.

An author who wants to write things like this should probably do something like <code>--breaklonglines</code> with code { text-wrap: nowrap } in their styles, instead of just making the --flags part of the normal inline content of the paragraph.

Comment 3

[Benno Schulenberg]

Isn't the idea of a hyphen that it joins two things — two pieces of a word, two parts of something? That is: there should be both something before the hyphen and something after it? But with -b there is nothing before the hyphen, other than whitespace, and this hyphen should thus not be be considered as a possible place for wrapping. When finding the phrase "it was -5 degrees", one wouldn't want to see it wrapped between the "-" and the "5", right?

So I would suggest that Firefox implements a stricter way of wrapping after a hyphen. It should consider a hyphen as a possible wrapping place only when:

1. The strong rule: the hyphen is preceded by an alphanumeric character (Unicode categories Lx or Nx).
2. The lenient rule: the hyphen is not preceded by whitespace, opening quote, opening bracket, or another hyphen (Unicode categories Zs, Pi, Ps, and Pd).

I would prefer the strong rule, because I wouldn't want to see the classic smiley :-) wrapped either.

(Prohibiting a wrap after a double hyphen would not create a problem for a range written like "2014--2025", because one would want this to wrap between the two hyphens, not after the second hyphen.)