Last modified: 2012-11-24 11:45:40 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 T43965, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41965 - VisualEditor: Prepending to lists difficult
VisualEditor: Prepending to lists difficult
Status: RESOLVED WONTFIX
Product: VisualEditor
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: Unprioritized minor
: ---
Assigned To: James Forrester
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-10 12:49 UTC by Jarry1250
Modified: 2012-11-24 11:45 UTC (History)
3 users (show)

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


Attachments

Description Jarry1250 2012-11-10 12:49:52 UTC
At the moment, prepending to lists is not obvious. I think most people would try to do it by pressing enter on the preceding line to create a new paragraph, then pressing the make (bulleted) list button.

For some reason, this creates a list at the caret, but retains the blank paragraph afterwards (so you have list-para-list). Okay, so now you try to delete the para, but you can only deletes too much, for example merging the last list item on the first list with the first list item on the second list. In fact, pressing enter now works, but in any case the process is rather confusing.
Comment 1 James Forrester 2012-11-14 22:09:09 UTC
Firstly, I disagree with you about what users will expect. Behaviour in most visual editors, notably including Google Docs and Microsoft Word, is that you cannot prepend to a list other than by splitting the first item (i.e., by placing the cursor between the first bullet or enumerator and the start of the content on the first list item, and pressing 'Return').

If you follow your instructions, you're creating a second, separate list before the original list, and then wanting the software to magically know that you want them merged, which is somewhat complex behaviour that we don't currently support well, so we should create a bug for that. However, I'm inclined to close this as a WONTFIX. Thoughts?
Comment 2 Jarry1250 2012-11-14 23:15:30 UTC
(In reply to comment #1)
> Firstly, I disagree with you about what users will expect. Behaviour in most
> visual editors, notably including Google Docs and Microsoft Word, is that you
> cannot prepend to a list other than by splitting the first item 

I believe going to a preceding paragraph and clicking the "make list" button also prepends to a list in Word. Google Doc's list handling is different, admittedly. I'm having trouble reminding myself of what annoyed me about the VE's current response ("Error loading data from server: Invalid response from server") though -- so it could have been something relatively minor that just bugged me for a while.
Comment 3 Jarry1250 2012-11-14 23:17:30 UTC
s/a preceding paragraph/the preceding paragraph (line)/
Comment 4 James Forrester 2012-11-14 23:20:01 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Firstly, I disagree with you about what users will expect. Behaviour in most
> > visual editors, notably including Google Docs and Microsoft Word, is that you
> > cannot prepend to a list other than by splitting the first item 
> 
> I believe going to a preceding paragraph and clicking the "make list" button
> also prepends to a list in Word.

Yeah; we may want to ape this, but it's a lot of work for relatively little benefit and I think we can punt it to a later date - see bug 42115.

> Google Doc's list handling is different,
> admittedly. I'm having trouble reminding myself of what annoyed me about the
> VE's current response ("Error loading data from server: Invalid response from
> server") though -- so it could have been something relatively minor that just
> bugged me for a while.

Yes, sorry, we're midst-deploy right now, hence errors. Give us five minutes. :-)
Comment 5 Jarry1250 2012-11-15 00:09:38 UTC
Okay, right, figured it out. It's the randomly inserted blank paragraph that's annoying me. Even GDocs doesn't do that (it assumes you've got two lists next to each other); moreover, it's not the same behaviour as when you've got a paragraph next.
Comment 6 Jarry1250 2012-11-19 23:38:38 UTC
Any thoughts James on preventing the creation of that weird blank paragraph?
Comment 7 James Forrester 2012-11-24 02:16:40 UTC
The "weird blank paragraph" is what a "slug" - a place in the editing interface where the user can insert some content. It needs to be there so that users can successfully place content between blocks, but it isn't an entire line (depending on your User Agent) - once you start entering content, it expands to be the same size as a "real" paragraph, however.

An example of this is nested lists - in MediaWiki you can jump straight down to a second level of lists, but in HTML editing you still need to give the user some way to edit the list they're not in. This is why this wikitext:

Hello
** There

... produces this in the VisualEditor:

Hello
* 
** There

... the middle "line" is a "slug" that will disappear once you save, but if you need to insert text that's where you can go.

We're considering coming up with a little icon, perhaps a little like the cursor character, to make it clear that it's an insertion point rather than an actual blank line, but we're at early days yet.
Comment 8 Jarry1250 2012-11-24 11:45:40 UTC
Hmm, yes. I can certainly understand the case with (pre-existing) lists. But witness that neither of the two other editors mentioned put a slug (or indeed anything else) between the two adjoining lists created when one inserts a paragraph before a list and then presses the listify icon.

(For Word, it would make no sense for them to because it's not two adjoining lists, just two adjoining list items; for GDoCs they just don't.)

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


Navigation
Links