Last modified: 2013-04-22 16:15:28 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 13073 - ref might add a newline
ref might add a newline
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/User:Eve...
:
: 41243 (view as bug list)
Depends on:
Blocks: tidy
  Show dependency treegraph
 
Reported: 2008-02-19 17:01 UTC by Allan Crossman
Modified: 2013-04-22 16:15 UTC (History)
3 users (show)

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


Attachments

Description Allan Crossman 2008-02-19 17:01:37 UTC
When the very first <ref> tag in an article is followed by a newline, e.g.:

<ref>
This is reference 1
</ref>

It adds a newline in the reference itself:

But this does not occur with later references, e.g.:

<ref>
This is reference 2
</ref>

What these refs actually render as is this (but see the example on en.wikipedia):

1. ^
This is reference 1
2. ^ This is reference 2
Comment 1 Allan Crossman 2008-02-19 17:05:50 UTC
Correction: this only seems to occur when <div class="references-small"> is used.
Comment 2 Nicholas Wilson 2009-08-27 22:13:56 UTC
I have tested this both with reflist and without and cannot reproduce. Please provide a link (or perma-link, better) to an actual example. If you can reproduce this, reopen it; otherwise, this bug cannot be reproduced using the information you have given, so will be closed.
Comment 3 Nicholas Wilson 2009-08-29 20:07:08 UTC
My bad. I didn't notice the link given as well as the code in the post. The example given at the test page on WP does indeed demonstrate the bug, but it does not on my own MW.

So, we have a strange parser oddity to track down. The newline does not appear on third or fourth references, just the first, so there is an off-by-one error in the parser going on here. I have not yet had time to track down why it works on my setup and not yours, but I think this is the same as bug 11224.
Comment 4 Brad Jorsch 2011-11-09 22:00:59 UTC
This has little to do with Cite; it's mainly a Tidy issue.

Consider the following test case:
    <ref>
    foo
    </ref>
    <ref>
    bar
    </ref>
    <div><references/></div>

As far as Cite is concerned, it outputs wikitext something like this for the <references/> tag:

    <ol><li id="cite_note-0">[[#cite_ref-0|↑]]
    foo
    </li>
    <li id="cite_note-1">[[#cite_ref-1|↑]]
    bar
    </li></ol>

The page output handed to the parser is therefore something like this:

    <div><ol><li id="cite_note-0">[[#cite_ref-0|↑]]
    foo
    </li>
    <li id="cite_note-1">[[#cite_ref-1|↑]]
    bar
    </li></ol></div>

When Tidy sees the <div> on the same line as the <li>, it decides it has to wrap the rest of the lines in that <li> with <p> tags, which causes the odd output noted in this bug.

We ''could'' work around this in Cite by outputting newlines around the contents of the references list. Then the parser would see something like this:

    <div><ol>
    <li id="cite_note-0">[[#cite_ref-0|↑]]
    foo
    </li>
    <li id="cite_note-1">[[#cite_ref-1|↑]]
    bar
    </li>
    </ol></div>

Since the <div> on not on the same line as the <li> anymore, Tidy won't insert the problematic <p> tags.
Comment 5 jeblad 2012-10-30 06:43:56 UTC
*** Bug 41243 has been marked as a duplicate of this bug. ***
Comment 6 Brad Jorsch 2012-10-30 16:26:17 UTC
Gerrit change #30795 implements what I suggested in comment 4.
Comment 7 Brad Jorsch 2012-11-26 22:17:51 UTC
Merged.

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


Navigation
Links