NEW 12828
Typing Option-space should insert   
https://bugs.webkit.org/show_bug.cgi?id=12828
Summary Typing Option-space should insert  
Dan Wood
Reported 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)
Attachments
Add attachment proposed patch, testcase, etc.
Jean-Noel Chavannes
Comment 1 2007-04-12 03:23:30 PDT
Many thanks in advance for taking care of this bug !
mitz
Comment 2 2007-07-27 04:43:08 PDT
*** Bug 14779 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 3 2009-02-06 04:42:55 PST
<rdar://problem/5731681>
Aryeh Gregor
Comment 4 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.
Olivier
Comment 5 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>
Aryeh Gregor
Comment 6 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.
Note You need to log in before you can comment on or make changes to this bug.