Page MenuHomePhabricator

Feature change: extra blank lines should not insert more whitespace
Closed, DeclinedPublic

Description

Author: furrykef

Description:
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
whitespace.

(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.


Version: unspecified
Severity: enhancement

Details

Reference
bz9651

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:36 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz9651.
bzimport added a subscriber: Unknown Object (MLST).

titoxd.wikimedia wrote:

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.

furrykef wrote:

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
coffin.

jpotkanski wrote:

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
edit.

Because as mentioned this was not a behavior change.

furrykef wrote:

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.

furrykef wrote:

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.

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.

WONTFIX as per comment 7 (to get rid of deprecated LATER resolution).

  • Bug 41767 has been marked as a duplicate of this bug. ***

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.

So this seems to be silently suppressed?

At least my second point should be considered and probably isn't disputable.

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 http://www.mediawiki.org/wiki/Parsoid for more info).