This patch promotes a consistent design decision across projects in
MediaWiki core, extensions, and skins. The darker red color meets the
W3C Web Content Accessibility Guidelines (WCAG) at Level AA that text
or images of text must have a contrast ratio of at least 4.5:1 (or 3:1
for large text).
Bug: T343239
Change-Id: I771fec3f567ea7ce5a25f8c63d88c956a27121ef
When content is inverted via CSS filter, this sometimes inverts
CSS variables which have already been themselves inverted. Allowing
markup to explicitly mark itself as invertable would be helpful.
For now, usage is intended only for extensions integrating with
the skin. Since we're not sure this can be considered a stable
interface by editors we intentionally use the `skin-` prefix rather
than `mw-` interface given the note about confusion about what is
stable in [[mw:Stable_interface_policy/Frontend#Writing_code]]
Bug: T356425
Change-Id: I0cd0e36a6abe0bba9e98d1b319e636bef2952301
Add an @import for Codex variables, i.e.
@import 'mediawiki.skin.codex-design-tokens/theme-wikimedia-ui.less';
that adds overrides to the variables from
'mediawiki.skin.defaults.less' to CSSCustomProperties.less.
Bug: T356427
Change-Id: I7c2c3a07899b4de735f7e7fd24e003ab69d449bb
Additional changes:
* Separate CSSCustomProperties.less from skin.less so that
we can obtain the unmodified original values for the colors
Depends-On: I363a97d33d85a9033da753f2a8fe730d80206639
Depends-On: I148eaca747352ffdc9d1423f20d34bd5a1d0e447
Bug: T356427
Change-Id: I916450c276cabb0c7c871525c50f95fb87f498ad
The increase is due to the increase in size of the cdx icon mixin.
This does not impact render blocking CSS so this is an acceptable change.
Bug: T358028
Change-Id: Icea7aa0d2f80f33fc64fd9c7721a371e115a32cb
This fixes the regression introduced in I6331d88e5b73.
Also un-nesting selector to necessary level.
Bug: T357849
Change-Id: I58ed32e63ad4c37aefd79edac5f1376ce4313ee3
In 1.42.0-wmf.17 these had margin 0 in Minerva.
I incorrectly assumed we had defined an explicit margin in content
and for talk pages but apparently none exists, so I have restored
this rule to the list.less file.
Follow up to I6331d88e5b7301fd13249414350a539738cfae53
Bug: T357742
Change-Id: Ib3062bfbffe35415f479bae46ecf02e8a094958b
Right now visited links in night mode are showing the day mode style for
@color-visited, because --color-link--visited is defined, but never set
to a corresponding night mode style. This defines the night mode
variant in the stylesheet, and sets it to the same value as
--color-visited
Visual change only in night mode, which is behind a feature flag
I also added /coverage/ to the eslintignore, as I was getting failures
on the pre-commit hook due to us linting the coverage report 🙃
Bug: T356825
Change-Id: I96695fe4c094b79385e36aef9e29b8d392c06302
Required for proper presentation of page issues overlay
and multimedia viewer.
The div rules were unnecessary.
Bug: T205341
Change-Id: I6fea0f2013a11e5248b71619b795d794c8ed18ad
Following a discussion in the ticket, update the places where `#eaecf0`
has been hardcoded to reflect whether it is intended to be a border or
background style and replace with CSS variables where applicable. Add
`--border-color-muted` as a CSS custom property, and update the night
mode palette to use it. Lastly, add `--color-error`, to be used in a
subsequent patch
Visual changes, but again gated behind night mode feature flag
Bug: T356825
Change-Id: Icb5741190f3e80a20dcedf9b13d6a34fe619b467
