Last modified: 2012-07-05 22:22:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35108, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33108 - VisualEditor: Highlighted trailing whitespace should not have styles applied
VisualEditor: Highlighted trailing whitespace should not have styles applied
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
ContentEditable (Other open bugs)
unspecified
All All
: Normal normal
: VE-deploy-2012-07-09
Assigned To: Rob Moen
:
Depends on:
Blocks: 33053
  Show dependency treegraph
 
Reported: 2011-12-14 15:06 UTC by Dan Barrett
Modified: 2012-07-05 22:22 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Barrett 2011-12-14 15:06:25 UTC
This is a classic problem in at least 10 other "web page editors" for other products, plus VisualEditor.

Consider the sentence:  Hello world.

1. Highlight the word "Hello " including the space character after it.
2. Click the "Bold" button.
3. It renders:

  <b>Hello </b>World

when what the user REALLY wanted was:

  <b>Hello</b> World

Even if the user highlighted the whitespace, 99.9% of the time he/she doesn't really want it bolded. VisualEditor should bold only "Hello" and not the space after it.

The original MediaWiki edit page is the only editor I've ever seen that gets it right. If you highlight "Hello " with a trailing space and click the bold button, you get '''Hello'''.  Hooray!  Please don't lose this in VisualEditor.

This may be related to bug 22487, but that's for UsabilityInitiative and linking.
Comment 1 Helder 2012-06-22 02:27:54 UTC
Just a note: the behavior described at
https://www.mediawiki.org/w/index.php?title=Visual_editor/Feedback&oldid=552919#Double_click_selects_spaces
makes it very common to have spaces in the end of the selected text.
Comment 2 James Forrester 2012-06-22 18:45:44 UTC
Confirmed that this is still the behaviour of the new version.

Should we trim-and-then-apply? Or apply, but then trim on save? If the latter, won't that screw with wikitext<->Visual Editor cleanness of conversions? If the former, will this be unexpected (e.g. people selected the space deliberately so that they could later insert some bold text after it)?
Comment 3 Dan Barrett 2012-06-22 18:52:38 UTC
The use-case is:

1. User double-clicks a word
2. User clicks the Bold button

So "trim-and-then-apply" is the right thing to do 99% of the time.

If this helps... in 25+ years of editing, I can't think of a time I intentionally selected the space after a word in order to style it.
Comment 4 Dan Barrett 2012-06-22 18:54:11 UTC
Actually, "trim-and-then-apply" is not precisely correct. You want "trim and move the highlighted space to be after the closing bold marker."
Comment 5 James Forrester 2012-06-22 22:06:12 UTC
Mass-moving items into VisualEditor product
Comment 6 James Forrester 2012-06-23 01:24:18 UTC
Agree that trim-selection-then-redraw-then-apply is appropriate iff the user has used a bulk-text-auto-selector (like double-click on word).

But are we sure on when they have actively gone out of their way to select the preceding/trailing space (shift-cursors, etc.)?
Comment 7 James Forrester 2012-06-23 01:38:40 UTC
Mass-move out of "General" to "ContentEditable".
Comment 8 James Forrester 2012-07-02 19:30:00 UTC
Standardise title.
Comment 9 James Forrester 2012-07-02 21:54:42 UTC
Add to "VE-deploy-2012-07-09" milestone per this morning's meeting.
Comment 10 Rob Moen 2012-07-05 22:22:34 UTC
Fixed in https://gerrit.wikimedia.org/r/#/c/14108/

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links