[wp-trac] [WordPress Trac] #26842: Contenteditable, multiple spaces, &nbsp, and U+00A0

[WordPress Trac]

#26842: Contenteditable, multiple spaces, &nbsp, and U+00A0
------------------------------+-----------------------------
 Reporter:  azaozz            |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  Future Release
Component:  TinyMCE           |     Version:  4.7
 Severity:  normal            |  Resolution:
 Keywords:  needs-unit-tests  |     Focuses:
------------------------------+-----------------------------
Changes (by CK MacLeod):

 * version:   => 4.7


Comment:

 Replying to [comment:21 galbaras]:
 > Last change seems to be from 2 years ago, but I'm not seeing any changes
 in the editor yet.
 >
 > Making non-breaking spaces visible in text mode would make them possible
 to track and fix, if necessary, so why not add them and be done with it?
 Is there even a downside?

 I agree that would be a good change - showing all invisible characters in
 Text mode or at least providing the option to view the "real" source, even
 though in this instance, apparently, the problem is even deeper than HTML,
 and seems to have to do with how different browsers interpret the deeper-
 underlying unicode character.

 Just to keep everyone current, the issue appears in WebKit-derived
 browsers - so far Chrome and Brave in my testing - but not in Firefox,
 Edge, Sleipnir, just to name three. I hesitate to attempt to work up a
 list, since I suppose the problem could evaporate tomorrow, even if it's
 been going on for years. Also, to be clear, it arises for users (at least
 for users like me and like other participants in this support thread
 https://wordpress.org/support/topic/unwanted-non-breaking-spaces-nbsp/) as
 a text-replacement problem mainly, not a "multiple spaces" problem: When
 the user highlights and replaces selected text (but not words including
 following spaces, default word-highlight behavior), following white space
 gets converted into a non-breaking space, screwing up word-wrapping.

 Another possibility would be to introduce "elimination of all ` `'s
 in post content prior to save to database. The following function works,
 but, like most of the other fixes proposed on other threads, or that you
 can find around the Web - some focusing on WP php functions, some on
 tinyMCE or other Javascript methods - it doesn't allow users who want non-
 breaking spaces to keep them:

 {{{
 add_filter( 'content_save_pre', 'remove_nbsps' ) ;

 function remove_nbsps( $content ) {

      $content = str_replace( ' ', ' ', $content ) ;

      return $content ;

 }
 }}}

 It could be improved upon in various ways, no doubt, but, like I said, it
 works. If this functionality were the default, then you could introduce a
 settings option to disable substitution globally. Alternatively, a metabox
 or editor button (probably from a plug-in) could supply an option to turn
 off nbsp-replacement selectively for individual posts (or conceivably for
 spans).

 Finally, I'll also note that, if you use the tinyMCE Advanced plug-in, you
 can (dealing with a big of hinkiness) highlight the spots in the Visual
 Editor where the invisible characters appear. I still haven't found an
 Editor extension that shows the code in the same way an inspection tool
 will, however: That would be a good function, and helpful for developers
 and other users apart from the nbsp bug.

 In the meantime, the best I could do for a user dealing with this problem
 was to advise him to use a different browser for editing posts in WP, or
 to be more careful when performing edits on a WebKit browser (highlighting
 properly and always over-writing white spaces).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26842#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform