[Webkit-unassigned] [Bug 23997] Inserting spaces at end of line, causes spaces to wrap in designMode, but not contentEditable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=23997


Aryeh Gregor <ayg at aryeh.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ayg at aryeh.name




--- Comment #5 from Aryeh Gregor <ayg at aryeh.name>  2011-08-19 12:38:42 PST ---
(In reply to comment #1)
> The example which fails in Safari is:
> 
> "foo  bar"
> 
> the space before "bar" will wrap with bar at times.

The way I worked around this in my editing spec is . . . messy, but it avoids this problem:

http://aryeh.name/spec/editing/editing.html#canonical-space-sequences

Effectively, I make sure that runs of whitespace are normalized such that there's never an nbsp immediately before a word.  If the user types a bunch of consecutive spaces in between two regular words, they become

 _
 *_
 _*_
 _**_
 _*_*_
 _*_**_
 _*_*_*_
 _*_*_**_

etc., where _ is a regular space and * is non-breaking.  This does cause runs of spaces to wrap sometimes, but it minimizes the pain.

I don't see any way around all this stuff.  You can't just match Word here, because the content has to look the same if contenteditable is set to false, and in that case we have to follow regular HTML rendering rules.  That means we have to do something within CSS, but also supporting non-CSS clients if possible.  So horrible nbsp hacks are the only option.  Discussion:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032187.html

My conclusion is that authors who want sane behavior have to set white-space: pre-wrap on the editable area and also on any place where they use the output (so that it looks the same).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.