Re: [css-text] pre-wrap / pre-wrap-auto

> On 21 Nov 2015, at 16:15, Koji Ishii <kojiishi@gmail.com> wrote:
> 
>> One more thing I tested[1]; so the behavior on IE/FF is only for textarea, not for normal div, nor for contenteditable.
>> [1] http://output.jsbin.com/lopave/
> 
> You forgot "word-wrap: break-word;" It's in the UA stylesheet for textareas, but not for divs. If you put it in, FF gives the same behavior on textareas and divs. IE doesn't.
> 
> And if you also add: "word-break:break-all" you get the behavior you described as your favorite one for code editors and terminals.
> 
> Added, but I still don't see Firefox does (b).

http://jsbin.com/pafevacolu/1/edit?html,css,output

The spaces are not overflowing the end of the line (and they are not collapsed either), therfore we have (b).
What we do not have is (e), so the line will first break before bar first, rather than keep foo and bar on the same line and only break the line in the spaces.

For an example of not having (b), open the same link in IE or Edge. The spaces are preserved, but not wrapped.

For an example of not having (a), open the same link in Chrome or webkit. The spaces are neither wrapped nor overflowing, they are collapsed.

What firefox does in this example is one of the possible behaviors that I find acceptable, since it has (a) and (b). Among all the possible behaviors that have (a) and (b), it is not my favorite one, that's secondary.

Note that I am not saying IE or Chrome's behavior should be banned. They are appropriate for example for the word processor use case (with a preference for IE). But if they are the default, with some combination of properties we should be able to opt into a mode which has both (a) and (b).

>> I've tried to explain multiple times (many mails, some short, some long, multiple conf calls, f2f...) what I want to solve and why, but it seems I'm not getting my point across, so let's try another angle. Since you're reopening the case after we had a WG resolution, can you clarify what your goal is?
>> 
> I've tried too, unfortunate to fail to even understand each other.

You've been very clear about not liking a+b+c+d+e. I understand that, and I am ok with it, since a+b+c+d+e is not the only thing that is acceptable to me.

What isn't clear to me is whether anything other than status quo is ok for you. I hope not, since status quo means spec violations and no interop. (see https://lists.w3.org/Archives/Public/www-style/2015Mar/0386.html).

If I understand correctly, if the spaces are preserved, you want overflow-wrap:break-word to let them overflow rather than wrap them. This is not the status quo. Firefox (and Presto, and Prince) wraps them, IE sometimes does depending on the type of element. (Webkit/Blink neither wrap nor overflow since they don't preserve the spaces in the first place)

If you have a proposal, I'd like to hear it. The set of things that seem acceptable to me is broader than the specific proposal of mine that you're rejecting, so maybe what you have in mind would work for me.

> I'm against the combination of a+b+c+d+e.

That's fine, since I do not require it. I merely required the ablity to have (a) and (b). The rest is a debatable preference.

> 1. I want to understand what user problem you're trying to solve.

I want to solve 2 things:

1. The status quo has no interop at all. Every browser does everything differently.
2. There is no interoperable way to get spaces to be preserved and not overflow.

>  Real use cases? User complaints?

Both.

> 2. I believe what you're proposing makes editing experiences much worse. To prove I'm wrong:
Worse than what? Everybody behaves differently today.

I am not proposing a single behavior. You keep objecting to one of the behaviors that I have proposed as a possible solution to the problem, but I am ok with other solutions. I have proposed not one, but many solutions, including "do the same as firefox" or "do the same as IE in textareas", or "do what we resolved to do at the NY f2f" and a few other variants.

I reject the idea that all behaviors in a set which includes what some existing implementation do "make things much worse".

> 2.1. I want to see single apps/sites that does what you're proposing.

Firefox and IE/Edge in textarea elements with default styling do something I'm ok with.
Firefox on any element with white-space:pre-wrap and word-wrap:break-word; does something I'm ok with.
Vim does something I'm ok with.
Emacs does something I'm ok with.
Textedit.app does something I'm ok with.
Notes.app in 10.10 does something I'm ok with.
Chrome in elements with contenteditable=true and white-space:normal does something I'm ok with.

I do not ask for a+b+c+d+e. I ask for a+b+ one or more sensible options for line breaking. I believe c+d+e is sensible, but I am ok with alternatives if others disagree.

I am not ok with being unable to prevent the spaces from being collapsed.
I am not ok with being unable to prevent the spaces from overflowing.
I am not ok with no interop.
Everything else is negotiable.

> 2.2. I want to see what other editor developers think to understand how common the proposed behavior is.

Here are a few other people having issues with spaces being collapsed or overflowing.

* https://bugs.webkit.org/show_bug.cgi?id=110023 (someone wanting a+b+d, with Ojan saying that the current behavior "is likely something we'll change in Blink once we find the time.")
* https://stackoverflow.com/questions/14676036/google-chrome-bug-with-pre-wrap (Someone wanting and a and b and d)
* https://w3c.github.io/editing/historic-editing-apis.html#canonical-space-sequences (spec emulating a+b+c+d+e with &nbsp; and spaces)
* https://stackoverflow.com/questions/23504739/firefox-white-space-pre-wrap-wraps-words-if-theyre-too-long-including-traili (someone wanting e or not b)

 - Florian

Received on Saturday, 21 November 2015 09:57:40 UTC