Summary: | Typing Option-space should insert | ||
---|---|---|---|
Product: | WebKit | Reporter: | Dan Wood <dwood> |
Component: | HTML Editing | Assignee: | 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
Many thanks in advance for taking care of this bug ! *** Bug 14779 has been marked as a duplicate of this bug. *** 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. (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> 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. |