Last modified: 2014-03-16 12:52:07 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> -------------- -------------------------------------------
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.
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)....
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.
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...
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?
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 ***
