VisualEditor: Slugs should be more obvious to the user that they're not "really" blank lines
Closed, ResolvedPublic

Description

Simple test case, see URL:

  • foo

: bar

adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.


Version: unspecified
Severity: normal
URL: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60535

bzimport set Reference to bz47790.
Raymond created this task.Via LegacyApr 28 2013, 4:27 PM
Jdforrester-WMF added a comment.Via ConduitApr 28 2013, 5:26 PM

This is deliberate - the line is a "slug", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really "there" and are just places items can go.

Re-purposing this bug to talk about that. :-)

Jdforrester-WMF added a comment.Via ConduitJul 5 2013, 5:55 PM
  • Bug 50797 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJul 15 2013, 2:21 AM
  • Bug 50295 has been marked as a duplicate of this bug. ***
Ironholds added a comment.Via ConduitJul 15 2013, 9:18 AM

Does this include the line of whitespace right at the start of articles?

Raymond added a comment.Via ConduitJul 15 2013, 5:38 PM

It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.

Jdforrester-WMF added a comment.Via ConduitJul 15 2013, 6:36 PM

(In reply to comment #5)

It looks like this bug was fixed somehow. I cannot longer reproduce it on
dewiki.

Yes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely.

Jdforrester-WMF added a comment.Via ConduitJul 15 2013, 6:36 PM

(In reply to comment #4)

Does this include the line of whitespace right at the start of articles?

Yes.

Ironholds added a comment.Via ConduitJul 15 2013, 6:39 PM

Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).

bzimport added a comment.Via ConduitJul 20 2013, 11:11 PM

joedecker wrote:

I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.

As a separate question, can you undo deletion of slugs? If not, I think that would explain another set of problems others and I have observed.

bzimport added a comment.Via ConduitJul 21 2013, 8:55 AM

JohnCD67 wrote:

This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press "Delete" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press "Delete" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)

MZMcBride added a comment.Via ConduitJul 27 2013, 9:25 PM

Created attachment 12988
Copy of http://i.imgur.com/39QQi8U.png

Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)

Attached:

jayvdb added a comment.Via ConduitJul 28 2013, 9:44 PM
  • Bug 52172 has been marked as a duplicate of this bug. ***
Elitre added a comment.Via ConduitSep 12 2013, 4:52 PM

Today JohnCD asked again about this and I got another report from fr.wp, https://fr.wikipedia.org/w/index.php?title=Osmium&diff=96605232&oldid=93301425 .
Hoping this gets some love soon :)

Eloquence added a comment.Via ConduitOct 5 2013, 6:11 AM

I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions.

Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.

Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.

That seems like the simplest solution to me and does not require a redesign of the slugs.

Esanders added a comment.Via ConduitOct 5 2013, 9:02 AM

I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336

bzimport added a comment.Via ConduitOct 5 2013, 9:14 AM

jonathan_haas wrote:

(In reply to comment #15)

Why don't we just suppress the delete key when pressing it would delete the
object the slug is associated with?

This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.

I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.

Eloquence added a comment.Via ConduitOct 5 2013, 9:24 PM

Thanks, Ed, for splitting the issue and working on a patch for bug 55336.

Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.

I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.

gerritbot added a comment.Via ConduitJan 24 2014, 4:39 PM

Change 109307 had a related patch set uploaded by Esanders:
Collapse block slugs, and expand on hover/focus

https://gerrit.wikimedia.org/r/109307

gerritbot added a comment.Via ConduitMar 4 2014, 2:09 PM

Change 116742 had a related patch set uploaded by Esanders:
Vector style tweaks for collapsible slugs

https://gerrit.wikimedia.org/r/116742

gerritbot added a comment.Via ConduitMar 5 2014, 5:21 PM

Change 109307 merged by jenkins-bot:
Collapse block slugs and expand on hover/focus

https://gerrit.wikimedia.org/r/109307

gerritbot added a comment.Via ConduitMar 5 2014, 6:08 PM

Change 116742 abandoned by Esanders:
Vector style tweaks for collapsible slugs

https://gerrit.wikimedia.org/r/116742

Jdforrester-WMF added a comment.Via ConduitMar 6 2014, 3:42 AM

Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.

AdHuikeshoven added a comment.Via ConduitJul 11 2014, 9:31 PM

On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on "white lines" as a blocking issue for turning VE on as default.
On top of pages like:

as well as on other places on the page "white lines" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue.

Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.

This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.

(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)

How can I help to resolve this 'bug'? I will also copy to bug 55336.

Add Comment