[whatwg] Handling of collapsed whitespace in contenteditable

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
> &nbsp; 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.  WebKit already handles &nbsp;
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'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.

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.  If the current
element has white-space pre or pre-wrap, everyone but IE will just
insert regular spaces.  (IE only does this for <pre>, not other
elements with non-default white-space values.)  But in that case, the
behavior would be entirely undiscoverable, so no one would use it.  If
pre-wrap were the default, the discrepancy in display between editable
and non-editable would quickly lead savvy authors to figure out that
they need pre-wrap on their content too.

Received on Monday, 20 June 2011 15:00:27 UTC