Last modified: 2013-04-17 10:50:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9651 - Feature change: extra blank lines should not insert more whitespace
Feature change: extra blank lines should not insert more whitespace
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 41767 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-04-21 10:16 UTC by Kef Schecter
Modified: 2013-04-17 10:50 UTC (History)
3 users (show)

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


Description Kef Schecter 2007-04-21 10:16:06 UTC
If I recall correctly, the MediaWiki software used to ignore multiple
consecutive blank lines. I think this behavior should be restored, because I
don't think I have ever seen an instance where this has actually improved the
appearance of a page. I have, however, seen thousands of instances where it just
makes pages ugly and inconsistently spaced. For example, it seems to be typical
to put two blank lines before the first section on a page, resulting in
unnecessary extra whitespace before the TOC. But other pages that are otherwise
formatted exactly the same don't have this extra whitespace. This inconsistency
is annoying, frequent, unprofessional, and unnecessary. But that inconsistency
will always be there as long as this feature persists, with arguably very little
benefit in return.

Fixing these instances of unnecessary whitespace all the time is getting
tiresome (minor formatting issues like these make the majority of my edits on
Wikipedia), and I've been wanting to do something about it for months. If the
user really, really wants to introduce multiple consecutive blank lines, there's
always the BR tag. If the user doesn't know what the BR tag is, chances are they
shouldn't want to introduce extra whitespace in this fashion anyway. I think
that making wikis look pretty and consistent in appearance is more important
than the seemingly intuitive behavior that multiple blank lines create more

(Don't confuse the behavior I dispute with the behavior of one blank line
introducing a new paragraph. That behavior is obviously desirable, and it is
perfectly fine. The issue I have is when there is MORE than one blank line; this
should be treated equivalently to a single blank line. Likewise, a blank line,
an HTML comment, and another blank line should still be rendered as though if it
were a single blank line, which would remove a common source of this problem.)

If for whatever reason forcing this change on everybody is undesirable --
although frankly I can see almost no reason why this behavior could be
considered desirable to begin with -- then perhaps it can be made a page
rendering option in the user preferences.
Comment 1 Titoxd 2007-04-22 05:55:34 UTC
As far as I remember, MediaWiki has processed two carriage returns as one
paragraph break, and more than two as extra whitespace via a <p> block. Nothing
has changed recently in that regard, and changing it to *not* behave that way
would probably break stuff.
Comment 2 Kef Schecter 2007-04-25 22:14:09 UTC
On what grounds was this closed as "worksforme"? The problem is still there and
trivial to demonstrate, and the only argument advanced against fixing it so far
is "it would probably break stuff" -- a valid argument, but apparently we don't
even know that for sure yet, and even if we did, that wouldn't be a nail in the
Comment 3 Jason Potkanski 2007-04-25 22:39:13 UTC
If rendering can be seperated from the ability to "dummy edit" a page with 
extra blank lines or subtracting them. Blocking this ability would break stuff 
unless better methods are created for handling revision "metadata" like minor 
Comment 4 Brion Vibber 2007-04-26 15:39:26 UTC
Because as mentioned this was not a behavior change.
Comment 5 Kef Schecter 2007-04-26 23:47:27 UTC
Even if my recollection is somehow mistaken and the behavior hadn't changed, how
is that relevant? The problem exists whether or not it wasn't there before.
Comment 6 Kef Schecter 2007-05-05 12:43:25 UTC
Reopening because I still think the current behavior is broken. I don't see how
"this was not a behavior change" is even relevant. If you think "it will break
too much stuff" is a good reason to close it, that's fine, but I don't see how
the current reason for closing makes any sense.
Comment 7 Brion Vibber 2007-05-08 15:17:38 UTC
Someone else is just going to ask for it to be the other way. There's  no
pressing reason either way; if there's no particular current breakage there's no
reason to change it at this time.
Comment 8 Andre Klapper 2012-12-21 14:17:27 UTC
WONTFIX as per comment 7 (to get rid of deprecated LATER resolution).
Comment 9 Andre Klapper 2013-01-14 17:25:11 UTC
*** Bug 41767 has been marked as a duplicate of this bug. ***
Comment 10 Eduard Braun 2013-01-14 19:26:03 UTC
I'm somehow unsatisfied with the current solution.

In my opinion good typesetting is only possible if vertical spacing is based on paragraphs which are separated by a fixed amount of whitespace (no matter how many line breaks are between them).
As soon as vertical spacing can be controlled by multiple line breaks, the whole thing gets prone to errors (e.g. to much and/or nonuniform amount of vertical space between paragraphs) and proper typesetting is probably not achieved.
However this is my opinion and can be a matter of taste (as pointed out in comment 7), although I think everyone who sets value on good typesetting will share this opinion.

So firstly I think it should be further discussed if we really want to allow manual control of vertical spacing by means of multiple line breaks.

Secondly - even if we want to allow multiple line breaks to produce additional vertical space - the current interpretation of the MediaWiki Parser is far from optimal! The parser interprets the first and all following odd numbered blank lines as a new paragraph and puts a </p><p> into the HTML document, whereas even numbered blank lines produce a <br> in the HTML document (See the description of the duplicate bug 41769 for details). Therefore the spacing produced by multiple blank lines alternates between even and odd numbers of blank lines (since a <br> produces a whole line of vertical space, a new paragraph only about a half line). This behavior is highly inaccurate and unreliable and should be changed in that case.
Comment 11 Eduard Braun 2013-03-02 15:24:28 UTC
So this seems to be silently suppressed?

At least my second point should be considered and probably isn't disputable.
Comment 12 Andre Klapper 2013-03-05 10:31:02 UTC
Not suppressed, just that the argument in comment 7 still stands so nothing to add.

By the way, a new parser called Parsoid is in the making (product "Parsoid" in Bugzilla, see for more info).

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