Last modified: 2014-06-26 00:33:46 UTC
Please provide steps to reproduce - no idea at which stage/keyboard focus I press some key on my keyboard, and which browsers this was tested with Please see https://www.mediawiki.org/wiki/How_to_report_a_bug
go to https://en.wikipedia.org/wiki/User:Jaredzimmerman_%28WMF%29/VEtest 1. place cursor after "line 1" 2. press enter/return on keyboard twice 3. save page expected : there will be two blank lines after "line 1" actual: there are no blank lines after "line 1" see attached images for pre and post save appearance.
Created attachment 15502 [details] pre-save
Created attachment 15503 [details] post-save
Unfortunately MediaWiki has no representation of a blank paragraph, so they get destroyed when you save. We could theoretically not let you insert a second new line (so "enter" in a blank paragraph does nothing), and though this is an extant UX in the wild – LyX does this because LaTeX has the same limitation – I think it's pretty crummy, and probably worse than the current behaviour. What would you expect to happen?
Closing temporarily as there's no proposed action. Please feel free to re-open.
Two possible proposals that we could use one, both, or some variations When consecutive breaks are found we could use <br> <br> which is what you'll commonly see on wikipages when people are trying to do some advanced formatting if the <br> is followed by a [[template]] or == Section == we could strip out any <br> and replace with {{Clear}}
(In reply to Jared Zimmerman (WMF) from comment #7) > Two possible proposals that we could use one, both, or some variations > > When consecutive breaks are found we could use > > <br> > <br> > > which is what you'll commonly see on wikipages when people are trying to do > some advanced formatting … and is horrendous and explicitly deprecated. > if the <br> is followed by a [[template]] or == Section == we could strip > out any <br> and replace with {{Clear}} This is verging on a WONTFIX, but leaving as a possible thing for later consideration.
Where do we draw the line about being paternalistic and disallowing users to do things they want to do but we don't think are "good code" or "stylistically wrong" it seems like in many cases we go to great lengths to make things possible or easy even if we think the outcome may be that users misuse or use in unexpected ways and other times we block on them by saying we don't want to be enablers of bad behavior. Curious in this case how that logic is applied to do, or not do this?
