[whatwg] Handling of collapsed whitespace in contenteditable

[Ojan Vafai]

It is certainly the case that some large subset of users use spaces to align
content, not to mention really care about things like two spaces after
periods, etc. One way or another, contentEditable needs to support this.

If we were starting with a clean slate, the editing behavior we want is
likely whitespace:pre-wrap + some logic about what to do when you put extra
spaces at the end of a line*. We should make sure the pre-wrap editing works
as well as possible (e.g. doesn't do any of these NBSP shenanigans), but we
have to support non-pre-wrap even if it's not the default. So, one way or
another, we need to spec this behavior.

The only way we could make pre-wrap the default is if we made it more
backwards-compatible (assuming proper browser support for the CSS). A couple
things we'd need to do:
1. Getting innerHTML would need to be special-cased for contentEditable
nodes to wrap it in a span with whitespace:pre-wrap or to propagate the
whitespace down appropriately.
2. Copy would need to do the same. Copy is a whole can of worms that we'll
need to discuss anyways. As it is, WebKit will already do the copy
propagating styles if you're contentEditable node is whitespace:pre-wrap.

I'm not sure if there are other things we'd need to do, but I expect (1) to
be pretty controversial and I can't think of alternatives at the moment that
would provide sufficient backwards-compatibility.

* Most word-processors stop showing the spaces at the end of a line. They
insert the spaces but don't actually move the cursor or scroll until a
non-space character is inserted. This behavior is insane to me, but again,
it's what some non-trivial subset of users expect.

Ojan


On Mon, Jun 20, 2011 at 3:13 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:

> On 11-06-20 6:00 PM, Aryeh Gregor wrote:
>
>> On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari<ehsan at mozilla.com>  wrote:
>>
>>> There's a very good reason why existing browser engines have to resort to
>>>   hacks.  It's the only practical way to make sure that "foo__bar"
>>> (s/_/ /) entered into an editable element would appear the intended way
>>> when
>>> the innerHTML of the editable area is submitted to a server and later
>>> displayed in another documents.
>>>
>>
>> Is that really such a problem?  At worst, there will be annoying
>> mismatches between the same content when it's editable and not
>> editable.  Usually these won't really mess up the document, but if the
>> author notices and compares in a debugger, they'll easily be able to
>> figure out that the different white-space value is what's causing the
>> problem, and be able to fix it.
>>
>
> I think so, yes.  There are lots of people who use the space key to format
> the output to match what they want it to look like, and using preformatted
> whitespace means that what they would get is not what they would see on the
> screen.
>
>
> > WebKit already handles 
>
>> differently in contenteditable and not -- have they received any
>> complaints from authors about it?  Granted, that discrepancy isn't as
>> drastic as white-space: normal vs. pre-wrap.
>>
>
> I'm not talking about handling non-breaking spaces differently in editable
> sections (I do believe that's a problem, but it's not relevant to my point).
>  I'm talking about using ASCII space characters and relying on preformatted
> whitespace to format stuff correctly in editable areas.  Since preformatted
> whitespace is not the default, the generated HTML fragment would render
> completely differently in non-editable mode.
>
>
>  I'd have thought the bigger problem would be making hand-authored HTML
>> contenteditable.  pre-wrap would seriously mangle it if it uses any
>> indentation, and there might be lots of that out on the web.
>>
>
> That is also a valid concern.
>
>
>  On Mon, Jun 20, 2011 at 5:47 PM, Smylers<Smylers at stripey.com>  wrote:
>>
>>> Can you detect when an author has set white-space: pre-wrap, and specify
>>> that browsers have the sane behaviour in that case?
>>>
>>
>> That's effectively how it already works, except in IE.
>>
>
> True, but I agree with Smylers in that we need to specify that behavior.
>
> Cheers,
> Ehsan
>