Page MenuHomePhabricator

<references/> list item must not wrap the text in <span>
Open, LowPublic

Description

Currently, the code of reference item in reference list is:

<li id="cite_note-1">
  <span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span>
  <span class="reference-text">Lorem ipsum.</span>
</li>

This is wrong, because it disallows block elements in references. (In fact, if one puts the block elements there, they are being converted by Tidy in very unpredictable way.)

The easiest solution is to remove the <span class="reference-text"> wrapper.


Whiteboard: usability

Details

Reference
bz47544

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:29 AM
bzimport added projects: Cite, good first bug.
bzimport set Reference to bz47544.
Danny_B created this task.Apr 23 2013, 11:51 AM

mr.heat wrote:

Could you please add an example URL or explain a common case that contains block elements?

rohan.j.verma wrote:

I tried to find a case where this could be a problem but even with a table within the reference it just simply puts a span before and after the table element. If anyone finds a case where this is unpredictable or a block element that doesn't work please post it and I will look at this further.

mr.heat wrote:

(In reply to comment #2)

it just simply puts a span before and after the table

Which is semantically wrong. It's not allowed to put block elements into inline elements. Web browsers are able to deal with almost every bad HTML but it is still wrong.

rohan.j.verma wrote:

Just to confirm we are talking about the same thing:
<span> span1 </span>

<table> stuff </table>

<span> span2 </span>
Is wrong?
when I said before and after I meant it creates a separate span before and after the block element for the rest of the reference.

mr.heat wrote:

I'm sorry but it seems we are not talking about the same. When I enter this:

<ref name="t">
{|

t
}</ref>

<references />

in a local MediaWiki with Tidy disabled I get this:

<ol class="references">
<li id="cite_note-t-1"><span class="mw-cite-backlink"><a href="#cite_ref-t_1-0">↑</a></span> <span class="reference-text">

<table> <tr> <td>t </td></tr></table></span> </li> </ol> This HTML is wrongly nested. Because of this Tidy tries to fix it. It becomes: <ol class="references"> <li id="cite_note-t-1"><span class="mw-cite-backlink"><a href="#cite_ref-t_1-0">↑</a></span> <table> <tr> <td>t</td> </tr> </table>

</li>
</ol>

As you can see the class="reference-text" is simply deleted. This is not good. The class should be there no matter what is inside of the reference.

mr.heat wrote:

(In reply to comment #0)

The easiest solution is to remove the <span class="reference-text"> wrapper.

I was playing around with different possible solutions (switching to a DIV depending on the text, adding default styles) and I agree. The wrapper should simply be removed.

(In reply to comment #6)

The wrapper should simply be removed.

The class refernce-text is used in some places to detect the actual content of a reference, including in the script ext.cite.popups.js provided by the extension itself. The fact that Tidy sometimes removes that class is bug 38661.

The class refernce-text is used in some places to detect the actual content
of a reference, including in the script ext.cite.popups.js provided by the
extension itself.

so it should still remain in ext.cite.popup.js ?

mr.heat wrote:

*** Bug 38661 has been marked as a duplicate of this bug. ***

mr.heat wrote:

(In reply to comment #8)

so it should still remain in ext.cite.popup.js ?

The most simple and straightforward fix is to use a <div ...> instead of the <span class="reference-text"> and add

.reference-text { display: inline; }

to all screen and print CSS files (don't forget print). This solution may need additional tweaking. But in my opinion it should be done in any case. If it causes other issues these issues should be fixed separately.

Krinkle updated the task description. (Show Details)Dec 10 2014, 1:59 PM
Krinkle added a project: Technical-Debt.
Krinkle set Security to None.
fbstj updated the task description. (Show Details)Apr 12 2016, 7:09 AM

Change 276183 had a related patch set uploaded (by Aashaka):
Use div element instead of span around reference text

https://gerrit.wikimedia.org/r/276183

Izno moved this task from Unsorted backlog to Doing on the Cite board.Apr 13 2016, 2:51 PM

Please review :)

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 1 2016, 5:26 PM
Jdforrester-WMF closed this task as Declined.May 4 2016, 2:47 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Not allowing block elements in references is absolutely intentional; I'm Declining this.

Tagging major functional changes like this as "Easy" is pretty disrespectful to people, given that it's a huge change and reversing a very long-standing intentional choice.

Sorry that I didn't see this until now, especially to @Aashaka.

Change 276183 abandoned by Jforrester:
Use div element instead of span around reference text

Reason:
Sorry you spent time on this; the task shouldn't have been tagged as "Easy", and I've not Declined it.

https://gerrit.wikimedia.org/r/276183

Majr added a comment.May 5 2016, 12:41 AM

The problem is that cite does allow block elements in references, and then breaks the output by wrapping them in a span.

I said in the task that was merged into here, that cite should either support block elements or not, not just break.

jayvdb reopened this task as Open.May 5 2016, 2:49 AM
jayvdb added a project: Wikisource.
jayvdb added a subscriber: jayvdb.

Not allowing block elements in references is absolutely intentional; I'm Declining this.

What the ... ?
Block elements have been allowed in Cite's ref tag, and it is quite common for this to be used in 'Notes' on Wikipedia, and of course on Wikisource we do not have a say in when a published book chooses to use a blocky reference.

Here is an example of where a real academic work dares to use block elements in references:
https://en.wikisource.org/wiki/The_Descent_of_Man_(Darwin)/Chapter_II#cite_note-13
https://en.wikisource.org/wiki/Page%3ADescent_of_Man_1875.djvu/45

In that example, the wikitext is quite sophisticated, and the block elements are moved outside the <span class="reference-text">...</span>.
There are many simpler examples available on Wikisource if we want to see how the html renders.

Tagging major functional changes like this as "Easy" is pretty disrespectful to people, given that it's a huge change and reversing a very long-standing intentional choice.

Well, the code does look quite easy...

Izno added a comment.May 5 2016, 12:01 PM

For an example on en.wp, see Barack Obama#Notes 11, 13, 14, and etc. This use is increasingly common.

Change 276183 restored by Legoktm:
Use div element instead of span around reference text

Reason:
Per Danny B's request

https://gerrit.wikimedia.org/r/276183

Per discussion above I've requested restoring of the patch for the time being.

01tonythomas removed 01tonythomas as the assignee of this task.Jun 10 2017, 3:12 PM
Izno added a comment.EditedAug 3 2017, 4:01 PM

I think that the current user-level behavior will block moving to a strict HTML 5 parsing model, though there may be a more appropriate parent task. I don't much care how this task gets fixed (whether by some other work around or by allowing the suggested patch to move forward), but I expect that Bad Things Will Happen if the user-level behavior of including block tags inside of <ref> is disturbed.

What blocks the current patch besides "it was deliberately designed that way"? I seriously doubt that statement--the majority of changes I've seen made to Cite indicates it has not been a carefully designed extension.

Framawiki moved this task from Backlog to Doing on the good first bug board.Dec 2 2017, 1:40 PM

This does need to be fixed; people *all the time* use block elements in reference citations, most commonly paragraph breaks and short lists, though I've also encountered reasonable uses of small tables, block quotations, divs that do block indentation of material that is not a direct quotation, and so on. This is not a mistake or bad user behavior, it is editors doing what they need to do in references and non-reference footnotes (which also pass through the <ref> system, with templates (at en.Wikipedia) like {{efn}}, etc.).

The two most obvious solutions to me are a) move the span class(es) to the surrounding li, since the span(s) only seem to exist as carriers of the class(s); or b) convert the span(s) to div(s) styled to not induce extraneous linebreaks, but only take this route if there's an important reason to retain these containers that are presently spans.

Once Tidy is replaced with RemexHtml (T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool), I expect this will be fixed. Let us revisit after that happens.

Izno added a comment.Apr 11 2018, 8:32 PM

Once Tidy is replaced with RemexHtml (T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool), I expect this will be fixed. Let us revisit after that happens.

I would recommend against closing it even then, regardless, until each list item supports an internal block structure, given that we have ample examples of users using blocks inside the list items. (That might be removing the problematic span, or that might be changing the span to a div.)

Izno moved this task from Doing to Defect backlog on the Cite board.Apr 9 2019, 5:42 PM
Izno added a comment.Apr 19 2019, 6:38 PM

Once Tidy is replaced with RemexHtml (T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool), I expect this will be fixed. Let us revisit after that happens.

The output of ref 11 in my Barack example is:

<span class="mw-cite-backlink">...</span> 
<span class="reference-text">Obama (1995, 2004), pp. 9–10.
    <ul>
        <li>Scott (2011), pp. 80–86.</li>
        <li>Jacobs (2011), pp. 115–118.</li>
        <li>Maraniss (2012), pp. 154–160.</li>
    </ul>
</span>

<span> has as its content model "phrasing content", whereas <ul> has its content model "flow content". This means that this is not conformant HTML, but at least the entire list is now wrapped.

I've added some other testing on my user page; in general, I don't think any of them are the expected behavior, which is that the list element be presented next to the backlink, but I guess that's probably because the sublist is a block itself and isn't floating next to the backlink span (or the backlink span floating left).

Keep the existing functionality and have <footnote> <footnote follow=> </footnote> instead to handle the block level cases?

I'm also wondering if <footnotes> collation should use CSS counters and ::before ::after selector in a style sheet on a .refeference class block instead of the current formatted list arrangement. However I would have concerns about that approach given that ::before selectors can be used to insert unwanted sequences.

Xover added a subscriber: Xover.Jul 11 2019, 6:30 AM

In respect of the discussion at English Wikisource this is also slightly related to: T226395

Another example of where wrapping references in a span is not a good thing-
https://en.wikisource.org/wiki/Robert_the_Bruce_and_the_struggle_for_Scottish_independence/The_Making_of_Scotland

This didn't even generate a warning from linthint when the underlying pages were examined more closely (this suggests a new linter is needed that is aware of what goes inside REF tags.)

cscott added a subscriber: cscott.EditedJul 17 2019, 3:46 PM

From the parsing perspective, I have no problem with making the wrapper a <div> and using CSS to style this as inline (or whatever the desired appearance is). Whatever CSS styles you use is out of my hands.

The alternatives (solely from the parsing perspective) is to either (a) "magically" figure out whether the contents are inline or block and use the appropriate wrapper (this seems to be the expected behavior of some language converter constructs), or (b) declare the contents as one type or the other (say, inline) and enforce this by stripping out bad stuff (say, block constructs). A variant of (b) declares the contents as block, which requires less stripping, but presumably more styling. I don't know whether CSS can handle the "sometimes inline, sometimes block" nature of the contents any better than the HTML parser can.

That said, I'm not weighing in on whether "no block content in refs" is actually a Deliberate Feature or an Accidental Bug. That's for others to decide.