If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or convert surrounding spaces to nbsp's.
This causes all sorts of problems:
* An nbsp at the end of a line makes the last word longer, so when you
hit space, the last word on the line might jump to the next line.
Then when you type a letter, the nbsp gets converted to a regular
space and the word jumps back to the previous line. (I observed this
in Opera. IE and Gecko seem to have some special-case to avoid this;
WebKit avoids it with a more general hack that I'll note later.)
* An nbsp that winds up immediately before a word will cause the word
to be indented if it happens to start a line. Gecko seems to be very
careful to avoid this case, but all other engines do it sometimes.
* A long run of spaces of which some are spaces and some are nbsp's
can result in nbsp's at the beginning of a line. Thus if you type
three spaces in between two words for whatever reason, in some cases
the second word can be indented. This is probably not what users
want.
The behavior we really want here is to output regular spaces, and use
white-space: pre-wrap. This matches the word processors I tested
(Word 2007 and a moderately old OO.org): spaces don't collapse, and a
line break can never occur before a space, but it can always occur
after a run of spaces, and words followed by spaces don't get pushed
to the next line. (This is how pre-wrap behaves in IE and WebKit, at
least. In Gecko and Opera a long sequence of spaces will push the
preceding word to the next line, but I'd say that's a bug.)
If anyone here thinks it's practical to just set [contenteditable] {
white-space: pre-wrap } in UA stylesheets and output spaces all the
time, please say so. (I know the selector isn't quite right.) I
assume it's not, because it will make existing contenteditable areas
containing hand-authored content look wrong. If we did this, of
course, authors would have to set white-space: pre-wrap on the
resulting non-editable content as well, but at least then it would
work exactly as we want. If they don't set it, it won't look quite
the same as when the user edited it, but probably it wouldn't look
drastically worse.
It seems WebKit already does something kind of like this: in
contenteditable areas, line breaks are allowed at nbsp, they just
don't collapse. Thus user-created whitespace is partly nbsp's, and
breaks but doesn't collapse. Pre-existing author-added whitespace
doesn't contain nbsp and so collapses. And when you convert it to
non-editable content, it still doesn't collapse but breaking might be
different. This seems like a kind of evil hack, though.
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable content. So given that, I wish we could make this happen by
default and avoid all the complexity. Failing that, I'll have to work
out the least damaging way to use nbsp's here, but it's never going to
behave right in some cases.
