Personally, I think it is helpful for readers to immediately be able to see when text has multiple citations, because that implicitly has the information that editors have considered it worth giving multiple references, which might indicate that the information has been questioned, or is controversial in some way. E.g. the second sentence at https://en.wikipedia.org/wiki/Homeopathy !

Anything that partially-hides that kind of contextual information, would make it slightly harder to readers to notice and thus access citations.

Additionally, Readers are accustomed to the pattern of [1] leading to more info, and they would have to learn the new pattern of [†] and [‡]. Whilst not complicated, that is also a significant change which might not be clear to many less-well-educated readers.

Lastly, the glyph of [†] is somewhat problematic because it is already used to denote "date of death" in some projects, e.g. German Wikipedia, see example at https://de.wikipedia.org/wiki/Joseph_Haydn

In conclusion, I'd recommend against this change at Nowiki (though I do understand the desire to simplify the reading experience). Hope that helps!

In T224741#5227187, @Quiddity wrote:

[...]

A lot of this comment seems focused on the implementation of the presentation. I could just as easily present these references as [1-3], [1, 3, 6-10], [a, c, 3, 2], rather than [1][2][3], [1][3][6][7][8][9][10], or [a][c][3][2], or the suggested daggers, with subsequent appropriate linking. A solution to the presentation of references here might allow us to get rid of the group citations that are responsible for T49544: <references/> list item must not wrap the text in <span>.

The real problem with a request like jeblad's is what the user-without-Javascript would do to access the "collapsed" references. If I want to access reference c in the group above without Javascript, how do I do that? It seems like a large accessibility degradation to force people to ctrl+f instead for the reference number in question.

I guess the "rewrite" of the reference links could be done with Javascript instead of PHP, but that would cause reflow and friends.

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

In T224741#5227187, @Quiddity wrote:

Personally, I think it is helpful for readers to immediately be able to see when text has multiple citations, because that implicitly has the information that editors have considered it worth giving multiple references, which might indicate that the information has been questioned, or is controversial in some way. E.g. the second sentence at https://en.wikipedia.org/wiki/Homeopathy !

This discussion started after it was observed that some infoboxes would be provided with way more references than just a few from Wikidata. Quite a few well-known people has more than 10 references, and the numbers are growing.

Anything that partially-hides that kind of contextual information, would make it slightly harder to readers to notice and thus access citations.

Additionally, Readers are accustomed to the pattern of [1] leading to more info, and they would have to learn the new pattern of [†] and [‡]. Whilst not complicated, that is also a significant change which might not be clear to many less-well-educated readers.

I can't really see this as a real problem.

Lastly, the glyph of [†] is somewhat problematic because it is already used to denote "date of death" in some projects, e.g. German Wikipedia, see example at https://de.wikipedia.org/wiki/Joseph_Haydn

The most well-known note marks are Dagger and Double Dagger. Perhaps make it localizable? :D

In conclusion, I'd recommend against this change at Nowiki (though I do understand the desire to simplify the reading experience). Hope that helps!

I guess this is an example (!) of the problem with giving examples. The examples are misinterpreted for the real thing. I guess I forgot to put in "the green button". (The green button is usually some failing part of a demo that has a sole function to divert the discussion from other minor design choices.)

In T224741#5227349, @Izno wrote:

In T224741#5227187, @Quiddity wrote:

[...]

A lot of this comment seems focused on the implementation of the presentation. I could just as easily present these references as [1-3], [1, 3, 6-10], [a, c, 3, 2], rather than [1][2][3], [1][3][6][7][8][9][10], or [a][c][3][2], or the suggested daggers, with subsequent appropriate linking. A solution to the presentation of references here might allow us to get rid of the group citations that are responsible for T49544: <references/> list item must not wrap the text in <span>.

The real problem with a request like jeblad's is what the user-without-Javascript would do to access the "collapsed" references. If I want to access reference c in the group above without Javascript, how do I do that? It seems like a large accessibility degradation to force people to ctrl+f instead for the reference number in question.

I guess the "rewrite" of the reference links could be done with Javascript instead of PHP, but that would cause reflow and friends.

I have already implemented this in Javascript, but by doing some preparation server side it is possible to avoid the reflow. You switch between two different classes, where one layout for the note marks is defined if Javascript isn't enabled and the other one if Javascript is enabled. Thus it will be no reflow.

(A string of note marks can be hidden and replaced by generated content, all as styling alone.)

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

I can't see how this relates… Can you clarify?

In T224741#5228101, @jeblad wrote:

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

I can't see how this relates… Can you clarify?

When you have many references in a row, you can consider a construct like:

Fact.<ref>
First ref
* Second ref
* Third ref
</ref>

This is how en.wp deals with the problem. I just wasn't able to find where we document that solution else I would have linked it.

The solution in T224741#5228174 will fail badly when you have permutations of references. Permutations of references in such a list will spawn new entries in the references tag. This will be a real problem with references in infoboxes.

In T224741#5228096, @jeblad wrote:

This discussion started after it was observed that some infoboxes would be provided with way more references than just a few from Wikidata. Quite a few well-known people has more than 10 references, and the numbers are growing.

Ah! That makes more sense as a significant problem. Thanks for clarifying. :-) I don't have any alternative suggestions, so, good luck!

In T224741#5238124, @Quiddity wrote:

Ah! That makes more sense as a significant problem. Thanks for clarifying. :-) I don't have any alternative suggestions, so, good luck!

[slightly off-topic]

What I did in a module for adding references to infobox rows was to use a fixed ordering and then create a hash for the name part of the ref-tag. It is the content that is hashed. You can repeat the content if it has the same name and it will not spawn new entries in the reference section. Sorting the entries can be done with the standard ordering function, and that is sufficient unless a property in the reference is repeated. The most common problem is several authors. Those are a bit difficult, as you should not change the ordering of authors. As the order of statements are a bit random, it will be a problem.

I did something slightly simpler, I reused the existing hash from the wb-reference, which exposed the problem with the statement order. Someone spotted the error and made a whole lot of fuzz about. It should only be a proof of concept, but in the end I had to kill the code to calm down two-three users that went completely ballistic.

You can't inspect results from processing other rows, unless you abuse an slight error in Scribunto, thus you must use the information available during processing of each row. If you could inspect the other rows, then you could reorder statements until a match is found with a previous reference.

Without a proper fix on statement order I doubt it is possible to reuse multiple references from Wd in the infobox.

Just an off-the-bat suggestion: Keep multiple footnote markers, as in T224741#5227188, but make them clickable as a group, popping up a reference preview pane with all references in the group expanded, a bit as if we had a magnifying glass over the References section.

Also, I'd love to give the footnotes click target a wide margin, e.g. 10px. Somehow this should take second priority to any other links in the text, z-index won't work but maybe there's CSS for that?