Last modified: 2014-03-16 12:52:07 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 T10318, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8318 - Two linebreaks between wikilists should add <p></p> to source
Two linebreaks between wikilists should add <p></p> to source
Status: RESOLVED DUPLICATE of bug 1115
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/User:Sim...
: parser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-19 11:53 UTC by Jeremy M Wilton
Modified: 2014-03-16 12:52 UTC (History)
1 user (show)

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


Attachments

Description Jeremy M Wilton 2006-12-19 11:53:23 UTC
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>
--------------

-------------------------------------------
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-19 23:32:20 UTC
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.
Comment 2 Jeremy M Wilton 2006-12-20 06:34:21 UTC
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==
#Test 0
#Test 1

#Test 2


#Test 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)....
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-20 18:39:25 UTC
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:

# A
# B

# C
# 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.
Comment 4 Jeremy M Wilton 2006-12-20 22:33:04 UTC
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...
Comment 5 Jeremy M Wilton 2006-12-21 01:05:59 UTC
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?
Comment 6 Jeremy M Wilton 2006-12-30 04:50:35 UTC
I found issue with titles and text as well... I added exmaples to the URL ( http://en.wikipedia.org/wiki/User:Simetrical/8318 )...
Comment 7 Nemo 2014-03-16 12:52:07 UTC
(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 ***

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


Navigation
Links