Page MenuHomePhabricator

Cite extension doesn't use native digits
Closed, ResolvedPublic

Description

See the references numbers, they are in "Arab" digits [1] [2] instead of [۱] [۲] etc.

http://parsoid-lb.eqiad.wikimedia.org/fawiki/%DA%AF%D9%88%DA%AF%D9%84?oldid=13402018
http://parsoid-lb.eqiad.wikimedia.org/fawiki/%DA%86%D9%BE%D9%82%D9%84%D9%88_(%D8%B1%D8%B2%D9%86)?oldid=10111059

Needs to respect formatNum() like behaviour.


Version: unspecified
Severity: major

Details

Reference
bz71803

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:55 AM
bzimport added projects: Parsoid, I18n.
bzimport set Reference to bz71803.

Note that the digits at the bottom are in localized digits. It's just the inline references where are in arabic numerals.

It was suggested that Parsoid might want to eventually move to a native CSS solution here.

This isn't viable in the short term because:

  1. The set of digits supported in browsers is very small. https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type lists a decent number of different digit scripts, but most of these are firefox only and not included in the official spec yet. The official spec is http://dev.w3.org/csswg/css-counter-styles-3/ and includes a means for us to manually specify additional native number styles -- but this isn't implemented anywhere yet AFAICT.
  1. Styling the actual inline reference numbers would seem to want to use:

display: inline-list-item;

so that it doesn't start a new paragraph box. (See http://dev.w3.org/csswg/css-lists-3/#list-item ). But not that this is (again) not yet implemented in browsers.

  1. We might also need to explicitly set the citation counter? That might require using <li value="..."></li> to represent the reference number, but then that would need to be enclosed in some sort of <ol> tag. I'm not certain whether there is a pure-CSS way to set the value of a counter.

So: probably possible in a few years. Not possible yet today.

@Scott: Are we sure that most of the list types in https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type are not supported in Chrome for example?

Re 2): Could you explain why that would be necessary? We don't use lists afaik, only counters.

Re 3): Last I looked we were working on setting the counter with counter-reset, inside a style attribute. This does not require lists.

FWIW, in Chrome most of the list styles in https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type seem to render fine in Chrome.

Re 2) -- I agree that

content: counter(references, <list-style-type>)

should work, according to http://www.w3.org/TR/CSS2/generate.html#counter-styles. So you're right, inline-list-item support shouldn't be required.

Re 3) good point.

Latest Chrome is not so bad: http://jsfiddle.net/ky3htxde/ shows that cjk, ethiopic, and tamil are missing. But of course support across the VE browser base will be not nearly as good.

(And @counter-style is not supported anywhere yet AFAICT.)

See https://gerrit.wikimedia.org/r/158852 which implements CSS styling of references in parsoid.

Once this lands, I probably need to open a separate OCG bug to fake this same styling in the PDF renderer.

Thanks for setting a priority. Whatever the priority for development, however, "major" is correct severity when a wiki is "contaminated" by interface elements in wrong locale.

I've pushed a new version of https://gerrit.wikimedia.org/r/158852 with support for fawiki. The numbers appear correclty, as well as the backlinks, but I couldn't test pixel accuracy as phantomjs doesn't support all list-style-types yet (I think).

(And @counter-style is not supported anywhere yet AFAICT.)

Firefox 33 supports @counter-style. Some of the Vietnamese wikis are using it to make alphabetic ordered lists use the Vietnamese alphabet (example).