https://bugzilla.wikimedia.org/show_bug.cgi?id=20050

Brad Jorsch <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected].
                   |                            |edu

--- Comment #7 from Brad Jorsch <[email protected]> 2011-11-09 
22:05:29 UTC ---
This has little to do with Cite. It's mostly the parser being simplistic
combined with Tidy making a bad "fix".

As far as Cite is concerned, the ref with the embedded list gets expanded to
wikitext something like this:

    <LI id="cite_note-0">[[#cite_ref-0|↑]] This is a reference with a numbered
list
    # line 1
    # line 2
    # line 3— no newline</LI>

I've capitalized the <li></li> tags to make the next step clearer.

That gets handed to the parser, which doesn't pay any attention to the HTML.
doBlockLevels just blindly converts the wiki-list by inserting "<ol><li>" in
place of the "#" for the first element, "</li><li>" in place of the "#" for all
subsequent elements, and "</li></ol>" after the last list element. The </LI>
from Cite winds up inside the last list element:

    <LI id="cite_note-0"><a href="#cite_ref-0">↑</a> This is a reference with a
numbered list
    <ol><li> line 1
    </li><li> line 2
    </li><li> line 3— no newline</LI>
    </li></ol>

Tidy apparently decides that the last </li> is closing the <LI> and inserts a
"missing" </ol>, and then the real </ol> is interpreted as closing the
<reference>'s list. And then the <li> for the next reference gets a "missing"
<ul> inserted before it. A browser given this tag soup might do the same, or it
might decide that last </li> is extraneous and then insert the missing </li>
when it sees the "<li>" for the next ref.

The reason it works with the newline is because the </LI> is then after the
list instead of inside the last element, so when the parser inserts its
"</li></ol>" it winds up before the </LI> and everything is correct.

We ''could'' work around this in Cite by changing
[[MediaWiki:cite_references_link_one]] and
[[MediaWiki:cite_references_link_many]] to have a newline before the </li>, or
we could insert a newline at the end of the string passed as $3 to these
messages.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to