Last modified: 2014-07-11 21:31:33 UTC
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.
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. :-)
*** Bug 50797 has been marked as a duplicate of this bug. ***
*** Bug 50295 has been marked as a duplicate of this bug. ***
Does this include the line of whitespace right at the start of articles?
It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.
(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.
(In reply to comment #4) > Does this include the line of whitespace right at the start of articles? Yes.
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 :).
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.
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)
Suggestion: http://i.imgur.com/39QQi8U.png
Created attachment 12988 [details] Copy of http://i.imgur.com/39QQi8U.png Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
*** Bug 52172 has been marked as a duplicate of this bug. ***
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 :)
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.
I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336
(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 [details], 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.
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.
Change 109307 had a related patch set uploaded by Esanders: Collapse block slugs, and expand on hover/focus https://gerrit.wikimedia.org/r/109307
Change 116742 had a related patch set uploaded by Esanders: Vector style tweaks for collapsible slugs https://gerrit.wikimedia.org/r/116742
Change 109307 merged by jenkins-bot: Collapse block slugs and expand on hover/focus https://gerrit.wikimedia.org/r/109307
Change 116742 abandoned by Esanders: Vector style tweaks for collapsible slugs https://gerrit.wikimedia.org/r/116742
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.
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: * https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit * https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit * https://nl.wikipedia.org/wiki/Rijn?veaction=edit * https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit * https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit 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.
