Page MenuHomePhabricator

Two linebreaks between wikilists should add <p></p> to source
Closed, ResolvedPublic

Description

Author: user

Description:
The issues is that after a <ul> <ol> or <dt>, you can't have just one extra space (<p> </p> - or something like that), though you can have 2 spaces
(<p><br /></p>) or more.

Obviously one could enter <p> </p> or <br> after one of these, but the parser should be able to do this properly on it's own.

((The output will only contain information that is important to showing the issue at hand...))

Example 1:
-------------------------------------------

--- INPUT ---
* Example Text
-------------

--- OUTPUT ---
<ul><li>Example Text</li></ul>
--------------

-------------------------------------------

Example 2:
-------------------------------------------

--- INPUT ---
* Example Text
(blank line)
-------------

--- OUTPUT ---
<ul><li>Example Text</li></ul>
--------------

-------------------------------------------

Example 3:
-------------------------------------------

--- INPUT ---
* Example Text
(blank line)
(blank line)
-------------

--- OUTPUT ---
<ul><li>Example Text</li></ul><p><br /></p>
--------------


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/User:Simetrical/8318

Details

Reference
bz8318

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:34 PM
bzimport set Reference to bz8318.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

What is it you're putting after the blank line(s)?

*Example text
(blank line)
More example

displays as expected,

<ul>
<li>Example text</li>
</ul>
<p>More example</p>

See URL. Is this 1.6-specific? If so, please be aware that 1.6 is no longer
maintained except for security, and this bug appears to be fixed in trunk.

user wrote:

Apparently not just 1.6.8 since I just tried it in http://mediawiki.org/wiki/Sandbox and got the same results (unless that's what mediawiki.org is
using)...

Below is what I used...

test1

Trash 0
Trash 1

Trash 2

Trash 3

test2

*Test 0
*Test 1

*Test 2

*Test 3

test3

;Test 0
;Test 1

;Test 2

;Test 3

It pretty much produces the same results... There's nothing extra added for one space, only two (producing two spaces)....

ayg wrote:

Ah, so the text after the blank line is another list. What do you expect?
Normally two consecutive line breaks (one blank line) starts a new paragraph,
but paragraphs can't contain lists, so that can't happen here. Should <br /> be
added in this case? Wouldn't that interfere with just starting a new list?
Currently this produces two consecutive lists with almost no visual break, but
restarting the numbering:

  1. A
  2. B
  1. C
  2. D

There would be no way to do that if this were changed without resorting to HTML
lists. On the other hand, it's possible to add a <br /> manually if you want
that, and that's a lot less ugly than entire lists in HTML. I'm inclined to
WONTFIX.

user wrote:

A blank space should produce a blank space just as if it were text. It's completely non intuitive to have a blank space not produce a blank space, yet
two blank spaces produce two blank spaces in these instances... I would suggest you pay attention to how lines of text on their own output results,
they should react in the same manner and they don't...

One blank space = <p></p> with text (ol's, ul's, and dt's don't do this)
Two blank spaces = <p><br></p> with text (ol's, ul's and dt's do this, as they should)

As for lists, if you don't want a blank space you don't put one in, it doesn't interfere with the way they look - the problem is that the parser may
need a semi complex code to know when not to add <p></p> like in any of the other windows that aren't the main body of the article...

As for my examples, it doesn't just happen with lists above or below them, it happens in all cases....

Simply put, a <p></p> should be added when there's a blank line after a list...

I'm not sure what you mean by HTML lists, the last I checked these are HTML lists with CSS keeping them in sync, but I could be wrong...

user wrote:

Ok, someone else explained this a bit more to me... Basically the parser is using the 1st instance of a blank space to close off the list... Then the
solution would be something like 2 blank spaces should produce 1 space, 3 should produce 2 and so on after a list is closed, or maybe an identifier to
a new list perhaps?

user wrote:

I found issue with titles and text as well... I added exmaples to the URL ( http://en.wikipedia.org/wiki/User:Simetrical/8318 )...

(In reply to Jeremy M Wilton from comment #5)

Ok, someone else explained this a bit more to me... Basically the parser is
using the 1st instance of a blank space to close off the list...

This is bug 1115.

Then the
solution would be something like 2 blank spaces should produce 1 space,

Sounds unlikely>

3
should produce 2 and so on after a list is closed,

?

or maybe an identifier to
a new list perhaps?

That would be bug 13642 or the opposite bug 25587, or their superset bug 1584. Your original summary which Simetrical commented on is more specific, I'm restoring it; in practice this overlaps so much with bug 1115 that I'm merging them for joint consideration.

  • This bug has been marked as a duplicate of bug 1115 ***
tstarling set Security to None.