I copied these from the visualdiffing repo, but I may have
over-generalized these from some wiki that might have customized
this to all wikis. enwiki doesn't use this, for example.
In any case, this styling should be left to individual wikis.
similar to the argument in 8412fb64 where I removed CSS rules
for standard refgroups as overreach.
Change-Id: Ie37408d7a92af88e39e345eb464c6fa2210d57e3
* This has always been a bug but was hidden because enwiki
uses lower-alpha custom rendering and so we never noticed it
when we tested this on enwiki.
* Fixing the default gets rid of the need to override this for
every single language that defined a non-decimal counter.
* This also eliminates the need for some rules where the overrides
were identical to the baseline definitions (counter-type is
decimal and separator is '.').
Bug: T86782
Bug: T156350
Change-Id: I51f8a06c80bb897b66a0978b117fbc5560efd6cb
* This was obviously a mistake for 'decimal' since the previous CSS
would have rendered refs with the "decimal" group and refs without
any group identically making it hard to distinguish between the
two ref types.
* But, not all wikis define custom messages for these "standard"
ref groups. So, by providing default rendering for these, we would
need custom overrides for wikis that didn't define them (the vast
majority). Instead, for wikis that define them, define wiki-specific
CSS for these groups that can be added to their Common.css pages.
* Discovered as I set about trying to update CSS on wikis and my
test wikitext with different groups were rendering decimal groups
differently and I had no custom CSS for it anywhere.
Bug: T86782
Change-Id: I5598580e96eead94bb09574b2af5cef3ce4241c5
* Turned out there were 2 counters defined on references li nodes.
* One was added as part of the extends functionality added by WMDE's
book referenceing project.
* The other one was added as part of Parsoid's Cite CSS work.
* Since the counter increments were defined separately and applied
to the same node, only one of the increments would apply.
This breaks counter rendering on wikis where custom wiki-specific
rules aren't defined in that wiki's Mediawiki:Common.css
* Discovered after running visual diff tests after ad919e37
was deployed.
Change-Id: I826faac3564d63b8a4fbd80015fd5cc8f0069b7a
* The default formatting for linkbacks for multiple named refs is
determined by the "cite_references_link_many_format" message.
It is only defined in en.json as "<sup>[[$1|$2]]</sup>". $2 is
the output of referencesFormatEntryNumericBacklinkLabel.
So, change the default Parsoid CSS rule to match that.
* But, since we have shipped Parsoid CSS all this while with the enwiki
default, temporarily add "ext.cite.style.en.json" with that enwiki
default so that on deploy, enwiki citations in VE continue to display
as before.
Change-Id: I6f4b0e25189284ad0950977752739e7dc2951fec
When these styles are loaded on a normal MediaWiki page containing
output from the old parser, they cause references to be duplicated.
Use .mw-ref for now, which is only present in Parsoid output.
This partially reverts d6705eb3f8.
Bug: T323343
Change-Id: I6f2d43a060bea7aa175bed80f1be2c3d8a4924b0
* Some wikis need a X.Y style numbering where X is the
counter for the reference number in the list (mw-references),
and Y is the named-ref counter (mw-ref-linkback).
* Rather than have the mw-references counter be defined for
specific languages, it is useful to have defined for all
wikis and use it where needed.
* Not sure why the ol.mw-references reset the mw-ref-linkback
counter. It needed to be reset for every item.
* While at it, made a couple CSS rules in kn and fa be more
specific so it is clearly what they are used for.
Change-Id: I6dd35303f134cc4996e134867ecc2c0db7a5411f
* The default separator (' ') should be set up as an :after selector
and individiual wikis that define the _many_sep and/or _many_and
messages can override this appropriately.
* Update frwiki overrides accordingly. It has an additional <sup>
in the Cite_references_link_many message. frwiki also defines the
Cite_references_link_many_and message.
Change-Id: Ia9ce6ac8eaa5b8386d4a586c620959465da73ef1
* As part of T265930, in order to reduce the CSS rules that needed
to be added, we started using the .reference class that the
original Cite implementation uses.
* Let us migrate styles to using that original class as well.
* Since Parsoid emits a <sup>, we no longer need some of the
CSS rules on .reference. With the class name change, the
other rules are duplicates since we inherit the rules from
ext.cite.styles.css. This effectively eliminated all CSS
rules for ".reference" from ext.cite.style.css
* Admins on wikis will get the following guidance:
- where similar styles apply to legacy output and Parsoid output,
use the .reference class in Commons.css
- where specific styles apply to Parsoid output but not legacy,
use the .mw-ref class in Commons.css
* Once we have fully migrated all wikis to Parsoid output, we can
migrate all the ".mw-ref" rules to ".reference". We then stop
emitting the ".mw-ref" class in Parsoid output.
Change-Id: I5a8c540dc5b045ffff8c280262595f5281cd167d
* Most wikis seem to either use lower-alpha or seem to use
use language-specific custom numbers. decimal usage is lower
and is better used as CSS override on those wikis.
Change-Id: I3e4c3e7b96ab5a9704fe700f62154e51930c975a
This patch is probably not necessary per se, because Cite creates and
controls the mw:referencedBy rel attributes, but it popped up in my code
search, it is technically more correct and it doesn't hurt.
Bug: T315209
Change-Id: Ie796c8a69988c6a546a15d998028c0e6f4c5b2e9
This lets us remove the inlined style on follow refs.
It will be used in I8bfc4ee3df162e2040e3c6f0c37fbf2a7c30d7f6
Bug: T263052
Change-Id: I351516b81566aba0adb4d298e39806dfb4fc7b03
* See T251983#6159540 for a more detailed summary, but these should
have always been in sync in the first place.
Bug: T251983
Change-Id: I92d2ec19c70c31374fabc9540678b1bb6eb2728c
Same as Ib6e9de6.
We must reset the build-in "list-item" counter to make this code behave
sane in Firefox. It looks like this is even described in the CSS spec
and it is not Firefox having a bug, but Chrome being "clever" and not
following the spec.
Bug: T229307
Change-Id: I955786e2b68d087c819a962ded3c571946c61f78
Forked from Icd933fc983.
Bugs and unimplemented features are documented as TODOs in the parser test
fixtures.
Bug: T237241
Change-Id: I9427e025ea0bcf2fa24fd539a775429cc64767cc
There is almost never a situation where this is desirable, yet it
happens quite a lot due to table headers etc having bold styling.
It confuses editors and tends to be less readable.
These style rules have been in en.wp:MediaWiki:Common.css for over 10
years or so, so probably a keeper.
Change-Id: If3d12383853a83d8ef14f1ec54c8c381b6c8f6a2
This happens while editing in VisualEditor and ContentTranslation.
This is done by adding unicode-bidi: embed to .mw-ref.
Bug: T105605
Change-Id: I1d03063cad1fa0f2ae8cc792aaaefc715066f17e
* Add a new module ext.cite.style to load the new CSS.
* Add a ResourceLoaderFileModule that adds the correct CSS file
depending on the content language, so that the visual style of
citations can be changed per-language.
The main ext.cite.style.css file renders similarly to MediaWiki's
default Cite style. Also, an example CSS for Farsi numbering is
included.
Bug: T86782
Change-Id: I487095df8a7c4241a14f7b4480360f6774130bec
