Change Details

The reference list currently renders footnote numbers using built-in browser <li>. This is fragile but works in most simple cases. It's worth fixing so that we can guarantee accurate numbering—here is the list of known issues with the status quo (TODO: provide examples): * visual editor numbering can be out of sync when template-produced references are present * symbols can differ when browser rules aren't available for the content language * numbers aren't included when copy-pasting from the reference list The issue affects the legacy parser, Parsoid, and a separate code path in the visual editor. Currently, rendering is done using two different mechanisms: * Send a CSS variable holding the number as a string. A stylesheet applies this variable to the `li::marker`. * Rely on browser `<ol>` `<li>` numbering, which fails for many use cases like custom groups and different alphabets. Be aware that the numbering style includes some decoration around the number, which is specific by language, eg. "1)", "1.", "(1)" and so on.

The reference list in both read modes (legacy and Parsoid) currently renders footnote item numbers in the reflist using built-in browser <li>. This is fragile but works in most simple cases. Replacing with explicit text numbers is analogous to {T369614} but for the reference list. Only this will guarantee accurate numbering—thereby solving this list of known issues: == Wrong symbols in reflist when the browser lacks explicit language numbering support == For example, with firefox 133.0 on linux, the footnote markers for [[ https://kn.wikipedia.org/wiki/%E0%B2%B8%E0%B3%81%E0%B2%B6%E0%B3%80%E0%B2%B2%E0%B3%8D_%E0%B2%A6%E0%B3%8B%E0%B2%B7%E0%B2%BF | knwiki articles ]] are written in Kannada script, {F58185480} while the reference list incorrectly shows fallback numbers, {F58185487} == Numbers aren't included when copy-pasting from the reference list == Select any number of reference list items from [[ https://my.wikipedia.org/wiki/%E1%80%80%E1%80%94%E1%80%85%E1%80%AD%E1%80%AF%E1%80%B8%E1%80%9B%E1%80%BD%E1%80%AC%E1%81%8A_%E1%80%99%E1%80%AD%E1%80%AF%E1%80%B8%E1%80%8A%E1%80%AD%E1%80%AF%E1%80%99%E1%80%BC%E1%80%AD%E1%80%AF%E1%80%B7%E1%80%94%E1%80%9A%E1%80%BA | any article ]] and copy. {F58185516} When pasting as plaintext, there is no number or even indication of list item start: {F58185526} When pasting as HTML results vary, you may see an `<ul>` item or various English numbers with interesting formatting, {F58185554} == Some browsers can't search for a reflist number == For example, go [[ https://en.wikipedia.org/w/index.php?title=Castle&oldid=1268726548 | this revision ]] and search for footnote number "186". Firefox 133.0 correctly finds the footnote number "[186]" in article text, and reflist item number "186", {F58185647} but Chrome only finds the footnote marker, {F58185656} == Follow-up == Gotcha: Be aware that the numbering style includes some decoration around the number, which is specific by language, eg. "1)", "1.", "(1)" and so on. The visual editor numbering also needs some CSS touch-up to style explicit text but this is strictly a refactor to remove the unnecessary CSS var and li::marker content, and is functionally equivalent to explicit numbering from the user perspective.

The reference list in both read modes (legacy and Parsoid) currently renders footnotete item numbersers in the reflist using built-in browser <li>. This is fragile but works in most simple cases. Replacing with explicit text numbers is analogous to {T369614} but for the reference list. It's worth fixing so that we can guarantee accurate numbering—here is the list of known issues with the status quo (TODO: provide examples):Only this will guarantee accurate numbering—thereby solving this list of known issues: == Wrong symbols in reflist when the browser lacks explicit language numbering support == For example, with firefox 133.0 on linux, the footnote markers for [[ https://kn.wikipedia.org/wiki/%E0%B2%B8%E0%B3%81%E0%B2%B6%E0%B3%80%E0%B2%B2%E0%B3%8D_%E0%B2%A6%E0%B3%8B%E0%B2%B7%E0%B2%BF | knwiki articles ]] are written in Kannada script, {F58185480} while the reference list incorrectly shows fallback numbers, {F58185487} == Numbers aren't included when copy-pasting from the reference list == Select any number of reference list items from [[ https://my.wikipedia.org/wiki/%E1%80%80%E1%80%94%E1%80%85%E1%80%AD%E1%80%AF%E1%80%B8%E1%80%9B%E1%80%BD%E1%80%AC%E1%81%8A_%E1%80%99%E1%80%AD%E1%80%AF%E1%80%B8%E1%80%8A%E1%80%AD%E1%80%AF%E1%80%99%E1%80%BC%E1%80%AD%E1%80%AF%E1%80%B7%E1%80%94%E1%80%9A%E1%80%BA | any article ]] and copy. * visual editor number{F58185516} When pasting can be out of sync when template-produced references are presentas plaintext, there is no number or even indication of list item start: * symbols can differ when browser rules aren't available for the content language{F58185526} When pasting as HTML results vary, you may see an `<ul>` item or various English numbers with interesting formatting, * numbers aren't included when copy-pasting from the reference list{F58185554} The issue affects the legacy parser, Parsoid, and a separate code path in the visual editor.== Some browsers can't search for a reflist number == CurrentlyFor example, go [[ https://en.wikipedia.org/w/index.php?title=Castle&oldid=1268726548 | this revision ]] and search for footnote number "186". Firefox 133.0 correctly finds the footnote number "[186]" in article text, rendering is done using two different mechanisms:and reflist item number "186", * Send a CSS variable holding the number as a string. A stylesheet applies this variable to the `li::marker`.{F58185647} * Rely on browser `<ol>` `<li>` numberingbut Chrome only finds the footnote marker, {F58185656} == Follow-up == Gotcha: Be aware that the numbering style includes some decoration around the number, which is specific by language, eg. "1)", "1.", which fails for many use cases like custom groups and different alphabets"(1)" and so on. Be aware that the numbering style includes some decoration around the number, which is specific by language, eg. "1)", "1."The visual editor numbering also needs some CSS touch-up to style explicit text but this is strictly a refactor to remove the unnecessary CSS var and li::marker content, "(1)" and so onand is functionally equivalent to explicit numbering from the user perspective.