Bug 12828

Summary: Typing Option-space should insert  
Product: WebKit Reporter: Dan Wood <dwood>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: applestore, ap, ayg, enrica, justin.garcia, nickshanks, osweb, rniwa
Priority: P2 Keywords: InRadar
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   

Description Dan Wood 2007-02-20 07:26:45 PST
When I type in the following, with _ representing option space:

We use Blammo_2, the Quicker_Picker_Upper, for our tapestry needs here in Nova_Scotia.

I want to ensure that the space in those places is explicitly non-breaking, meaning that they won't word-wrap.

When typed into TextEdit, resizing the window does the expected -- those nonbreaking spaces never break.

When typed into Blot (not TOT, but I don't think there's much difference), this doesn't happen at all.  The HTML is:

<HTML><HEAD><META http-equiv="Content-Type" content="text/html; charset=UTF-8"></HEAD><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">We use Blammo 2, the Quicker Picker Upper, for our tapestry needs here in Nova Scotia.</BODY></HTML>


Note that there is *no* distinction between what I typed as option-space and space.  They are all plain spaces.


What I would expect, and hope, to get would be something like this (ignoring the special styles):

We use Blammo&nbsp;2, the Quicker&nbsp;Picker&nbsp;Upper, for our tapestry needs here in Nova&nbsp;Scotia.




Anything other than this just doesn't make any sense to me!  (IMHO)

(Note: this is submitted after some description on the webkit-dev list)
Comment 1 Jean-Noel Chavannes 2007-04-12 03:23:30 PDT
Many thanks in advance for taking care of this bug !
Comment 2 mitz 2007-07-27 04:43:08 PDT
*** Bug 14779 has been marked as a duplicate of this bug. ***
Comment 3 Alexey Proskuryakov 2009-02-06 04:42:55 PST
<rdar://problem/5731681>
Comment 4 Aryeh Gregor 2011-08-19 11:43:15 PDT
The problem here is that nbsp is used in editable regions to ensure that adjacent spaces don't collapse.  To make this work sanely, you have to interchange nbsp and regular space sometimes to avoid multiple nbsps in a row when the user typed regular spaces.  This was discussed on whatwg:

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

Relevant reading in my spec as of now includes the note at the beginning of <http://aryeh.name/spec/editing/editing.html#canonical-space-sequences>, and the comment (expand using button on right) at the beginning of <http://aryeh.name/spec/editing/editing.html#the-inserttext-command>.  It's a huge headache.

I'm thinking it would be feasible to respect nbsp vs. regular space distinctions if the element has white-space: pre-wrap specified.  Then none of the magical overuse of nbsp is needed, so they can be treated normally.
Comment 5 Olivier 2011-08-20 03:40:19 PDT
(Background: I come from Bug 14779, which concerns Apple Mail and is where the issue is bothering me.) 

And what about (if the pre-wrap option turns out not to be practical) “cheating” by using another kind of space, either (a) to prevent collapsing of adjacent spaces or (b) when the user inserts an nbsp? The following characters seem good candidates as they don’t break or collapse in WebKit, apparently :

U+2008  PUNCTUATION SPACE
U+2009  THIN SPACE
U+2002  EN SPACE
U+2003  EM SPACE
U+2007  FIGURE SPACE
U+202F  NARROW NO-BREAK SPACE

Of course, those are non-ASCII characters*, but if the final output is HTML, then they get encoded as entities anyway, I guess, and it get converted to plain-text (still thinking of Apple Mail), they can be safely converted to (a) regular spaces or (b) nbsps depending on which of the above options was chosen. There already aren’t many people complaining about nbsps getting downgraded to regular spaces in their e-mails, I don’t think there will be many who will notice that their Punctuation Spaces are being downgraded to nbsps. :D

* <bait type="flame">But ASCII must die anyway.</bait>
Comment 6 Aryeh Gregor 2011-08-22 11:53:27 PDT
nbsp is non-ASCII too.  In general, CSS only collapses ASCII spaces, so any non-ASCII space would be fine.  The problem is, AFAIK, there's no space character that's the width of a regular space, except space itself and nbsp.  All the ones you suggest are either noticeably wider or noticeably narrower.

Ideally what we'd want is a space that doesn't collapse but does break.  Unicode doesn't know about collapsing, so there is no such thing.  pre-wrap, however, makes all regular spaces behave that way.