We print error messages in red, bold, large text so that they stand
out from content. "<code>" spans, which are prevalent in our messages,
were styled with black text by accident, this patch turns them red.
This should cause less annoyance on readers.
Change-Id: Ic911552909ecc5ace4be927cad5b835e1006355e
All mock screenshots on
https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Topw%C3%BCnsche/Erweiterung_der_Einzelnachweise
show this extra dot.
Note the numbering scheme "1." and "1.1" (without the dot) was not a
mistake. It's not uncommon to only have the extra dot on the first
level.
However, I feel the scheme "1." and "1.1." might be a little more
consistent and less surprising.
Change-Id: I0dc467755926f82d88a48fb7594af0bde8bbee21
This patch applies a few closely related changes:
1. Instead of reusing and possibly messing with the existing
"mw-ref-linkback" counter, I start a new one.
2. I also gave both new counters better names, following the
"mw-ref-…" naming scheme.
3. 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: T239787
Change-Id: Ib6e9de689129b7c2d50e3a1c720c0d2d5a0c0986
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
Adding option for dir attribute in ref tags. The value must be a valid
direction ('ltr' or 'rtl', case insensitive) or the direction will be
stripped out.
The directionality of the li element is set using a css class accordingly.
Bug: T15673
Change-Id: Iff480bc8cc4f81403b310e8efecd43e29d1d4449
This is based on the popular 'count' parameter from Template:Reflist on
English Wikipedia, which has also been adopted by many other wikis.
That template's 'count' parameter allows maximum flexibility on a per-
page basis. This was important because the template can't know how many
references the list will contain. Users typically manually add (and
later, increment) the 'count' parameter when the list exceeds a certain
threshold.
The template currently sets an exact column count (via the CSS3
property `column-count`).
This patch improves on that by instead using the closely related CSS3
`column-width` property. This automatically derives the column count
based on the available space in the browser window. It will thus create
two or three columns on a typical desktop screen, and two or no columns
on a mobile device.
The specified width is the minimum width of a column. This ensures that
the list is not split when rendered on a narrow screen or mobile device.
It also hooks into the raw list before parsing and adds the class only
when the list will contain more than a certain number of items. This
prevents very short lists from being split into multiple columns.
Templates like Template:Reflist on English Wikipedia currently are not
able to set inline styles on the list element directly, which is why
they set it on a `<div>` wrapping the `<references />` output. Because
of this, the feature of the Cite extension must not be enabled at the
same time, as that would result in both the template's wrapper and the
references list being split. The end result would involve sitations with
three columns split in four sub-columns, creating a complicated mess of
nine intermixed columns.
To provide a smooth migration for wikis, this feature can be disabled by
default using `$wgCiteResponsiveReferences = false`. Each individual
template createing reference list can then be migrated, by removing the
wrapper column styles and instead settting the new "responsive"
attribute, like so: `<references responsive />`.
Once any conflicting templates have been migrated, the default for the
wiki can be swapped by setting `$wgCiteResponsiveReferences = true`.
If wikis wish for some templates to keep their custom column splitting
behaviour, templates can also opt-out by setting `responsive="0"`, which
will make sure that it will keep behaving the current way even after the
feature becomes enabled by default for the wiki.
In summary, when disabled by default, pages can opt into this system
with `<references responsive />`. When enabled by default, pages can opt
out of the system with `<references responsive=0 />`.
* Deprecate cite_references_prefix/cite_references_suffix.
This message is rarely used and opens up compatibility hazards.
It was already removed by Parsoid, but the PHP implementation
still had it. It's typically used to add inline styles to the
wrapper which is more appropiately done in Common.css (or
obsoleted as part of the skin or Cite extenion itself nowadays
depending on what style in question).
It was also a HTML-style message with separated open and close
segments, which is an anti-pattern in itself.
* Declare module target explicitly and include mobile. The absence of
this stylesheet caused subtle BiDi/RTL bugs on mobile.
Bug: T33597
Change-Id: Ia535f9b722e825e71e792b36356febc3bd444387
This is needed when the error appears in an element with
a direction that is different from the UI language.
Change-Id: I583c9cc30f5bec24ab92e97ab938463ea0e45c15
A reference that has a group name appears as "[group 1]".
Because of the added space in the middle, this can break in the end
of a line. white-space: nowrap prevents it.
Change-Id: Icfbc8b7e37b77b93b621e424d1f4e1759ac644cd
I think this change causes too many issues on non-LTR wikis
(see the associated tasks) to be acceptable in the current form.
Maybe it should be redone to apply to RTL text only if it's
worth it there (apologies, but I don't quite understand the issue).
This reverts commit e9c1521fca
and commit 59ef3c8678 (which was
the previous attempt to fix it and caused different issues).
Bug: T108493
Bug: T110057
Change-Id: I205400c59a342dcc4cdf89791bc1c761805cd2a8
On I16a701f3b962b5e7f63554be2f28888a938548b0 we incorporated
unicode-bidi: embed; instead isolate but it caused regression on
* https://fa.wikipedia.org/?oldid=15565588
* https://fa.wikipedia.org/?oldid=15552160
where references ([۱]) comes before number with Persian digits.
Using unicode-bidi: isolate; is the clean solution for fixing this
however due to Firefox bug https://bugzilla.mozilla.org/1185987
it is not going to fix the regression on Firefox so using
display: inline-block; in hope to get same effect with Chrome
on unicode-bidi: isolate; but also support IE and older browsers.
Change-Id: I1d62c1fb282acc72ab20d71cc8cd21e3e1d71493
Move the JS which is purely for accessibility purposes into a separate
JS RL module named ext.cite.a11y. Move all pure CSS, which is not dependant
on accompanying JS into a separate ext.cite.styles module
Bug: T101559
Change-Id: I58adcfbcf9af2bb3b6d5dabb6c38c42af78e0416
