In situations where anon account creation is disabled or when
combined login link would be used, the usermenu array contains
single element (for 'login' or 'login/create') instead of two
elements ('login' and 'create account' items separately)
If $wgWikimediaMessagesAnonDonateLink is enabled through the
WikimediaMessages extension, the third element 'sitesupport'
exists, making the number of anon items either 1 or 2 or 3.
This patch fixes $isDefaultAnonUserLinks variable to account
for all the cases
Additionally, if even login is disabled, the element count can be
zero and in such case we need to hide the dropdown in all cases
(not only on large viewports) because it would always be empty.
This patch passes the userlinks count to ::getDropdown() and adds
CSS class when appropriate to hide the drowpdown completely.
Bug: T332743
Change-Id: I1ce5e1ea30917a6e80ef00f3c1703cbd0ecb6968
To make sure this is code-ified I have added the rule selector-max-specificity
to check specificity and error if we ever attempt to change this and to also
prevent us from writing overly complicated selectors (for now the default is
based on the status quo)
Additional change is required to skinStyle file to accomodate the new rule.
Bug: T373989
Change-Id: I3921d1fb3a098faae8f5a8bdc895783f1b298daa
Add `cursor: inherit;` to the class `mw-selflink` to get back
the expected behaviour of these 'links'.
Bug: T375876
Change-Id: I52d54dc1265fd1a64bc461892e69475a3b3d50b2
This was introduced in I16411a7ea47, which only documented the
changes to the colors used. An unintended side effect was inheriting
the standard border-radius, but that should be applied in a
more targetted manner to avoid conflicting with existing
UI components (e.g. OOUI toolbars).
Bug: T373989
Change-Id: I0615ce1594d66cb5207cd119597ae4d0765e94af
Visual changes are subtle, but impact 43 scenarios. The color
and positioning is slightly modified to match Codex.
Bug: T363920
Change-Id: Ie5c88e0aa243f73f2dc9f310d18fd59b831edc64
Follow-up to badd229bab. Moving
`position: sticky` to the same element as `contain: paint` defeated
the workaround. Move it to the parent elements again to make it work.
Bug: T373066
Change-Id: Ic942bfd599661a29cf7b2dbb6c6cc2ec521b8c82
This reverts commit b3ca12e628.
Reason for revert: Icons are appearing black on black in dark mode
in origin/wmf/1.43.0-wmf.18.
Change-Id: Ifdf3970c77b66e5a7835ca44eb45deec2b44eb43
Prevents dark-mode styles from affecting print media
by adding `@media screen` to dark-mode related styles.
Bug: T371331
Change-Id: I2ed7fbfc078c6d738c13a71c677783f7ccea2582
What:
Add styles for the footer buttons that reduces the padding from 15px to
8px on each side and adds an explicit background color.
Why:
This makes it follow the design spec outlines in T256190#9770626 and
fixes showing the buttons in the dark mode T256190#9900443
Bug: T256190
Change-Id: Iae144d554b5023fd3589ea29ae2d3c57c17e679f
This is in order to enable dark mode in echo and VisualEditor
Depends-On: Ibdfeb69c7c6f9dbf0e237c04c7f0f38a8306629a
Bug: T366322
Bug: T366737
Change-Id: I01cdde979b2ddf64d54013466a3fe51a493860cc
Visual changes: blue and red link colors have been updated to match codex, including hover/focus/active state colors
Bug: T366515
Change-Id: I16411a7ea47ae26c7e67a71f83e0521962c8ce61
These require JavaScript to work, so hide it by default and then
style it once JavaScript has loaded.
Change-Id: I34ded9f279600945ab18dd7ecfd69d22e141a324
@OOUIIndicatorSelectors was accidentally added to
the selector that prevents double inversion.
Bug: T365764
Change-Id: Idc3e2ac9ef50270512b9786db4f525a9ba4754a3
Follow up to I584491c280d93f18a48d8c90c4d8a6628f1a672f
Since these selectors are nested, this was generating unexpected
selectors, meaning the invert wasn't applying correctly to indicators.
This is evident on Special:Search
Bug: T365764
Change-Id: I40f8a8ad6598d145a6284c831e0cef944c5d7e75
In order for most OOUI black icons and indicators to be inverted
correctly, we need to apply the inversion to a limited number of
elements by a general class.
Applying here to keep OOUI library MediaWiki agnostic.
Bug: T365764
Depends-On: I792e89a8253a426b8c723486b96cb87bf9e1d85d
Change-Id: I584491c280d93f18a48d8c90c4d8a6628f1a672f
A number of icons using the vector-icon class that have been converted
to codex are being double inverted by this rule. Instead, switch it to
enumerate the full list of OOUI icons and invert them, so that
subsequent codex migrations can be easier as well
Also bumps the bundle size to account for the increase in bytes
Visual change for the table of contents arrows being fixed, ideally not
for anything else
Bug: T365951
Bug: T365580
Change-Id: Ia389e73c72432eb5f7a2df4ff9b48593751bc184
This reverts the revert commit 4da9b57dcf
and adds updated hardcoded values.
Note that we're also planning a better maintainable solution
with JS constants as Codex library output in T366622
Reason for revert: Working CSS changes now including hardcoded values
Given the issue described in T367103 with max width breakpoints,
these are left hardcoded at their new values with a FIXME to update
these later.
VISUAL CHANGES: there are 3 visual changes with Pixel with this change
- all 3 apply to legacy Vector and look like false positives.
Bug: T349793
Change-Id: I7d151c4ba608cabebe9375b960c0c18b3992954f
This reverts commit dd5b98515d.
Reason for revert: There are some hard-coded values in JS that reference these breakpoint, and need to be updated along with this change.
Change-Id: I4a16959d98c12ea1ca8b5b848f9cea0b9cea66f5
Adds hue-rotate( 180deg ) to the
.mixin-vector-arrowed-dropdown-toggle() mixin so that
the language icon doesn't appear with an orange
chevron in dark-mode.
Bug: T366337
Change-Id: If8f07e5924a31d761ac0af7efe0d982886bf6984
For now, let's exclude VisualEditor's toolbar from the night theme.
This should result in no visual change, but will make sure it and
its associated icons are not impacted by the roll out of OOUI.
Bug: T365764
Change-Id: Id626a75dbdeddc8809e4ea75eba3c0fd6d2b08fe
Replacing Vector specific variable with standard token that is meant
for exactly the applied use cases.
Note, I've left `border-color-subtle-transparent` because of that
extra engineering leg. I assume it was meant for animating the property,
which is not there. It seems better to me to replace this variable too
with `border-color-transparent`.
Change-Id: If264e04e576f044b98ec0d61b085f65af0110b6d