Making Minerva use the `elements` feature is not
practical at the current time. In lieu of that, we
update the link colors to use the core definition.
The red links and external link colors
can come from the "content-links" module.
This also adds support for the underlining user link preference
and better plain link support.
Bug: T274717
Change-Id: I600257e6f4430f166331c4ea4f3a72d87aa377d8
Increase the bundlesize test to account for the new
mw-ui-icon-element.mw-ui-button CSS
Depends-On: I429eab0730fb4cda5c69d5af7311f517be525851
Change-Id: Ibabeafe2c40ce718facb3fef4a85e94d453db5fd
In I7407e0451488bc01f2eed1c36ed87a11e7033a71 mw-ui-button will
include styles for compatibility with the checkbox. The change in KB
is minimal, and this will be reclaimed in Minerva when it makes use
of the checkbox hack.
Change-Id: Iaf062de9ec9c857b0d8643aa3f35d4c700d21d3b
Avoid indirection to QuickTemplate variable by using
SkinMinerva (SkinMustache) version.
To test:
* Create User:Admin/sandbox
* Create User:Admin
* Visit User:Admin/sandbox to see the breadcrumb "< User:Admin"
Change-Id: Icdd10bd1406ea047097309b6fcafba399170d019
em values are calculated relative to the parent element's font-size, not
the root or browser-default font-size. However, @font-size-minerva-small
and @font-size-minerva-smallest are supposed to be relative to the
assumed 16px browser default font-size. If they are used in an element
that already has a smaller-than-100% font-size, the resulting font-sizes
will compound and can be smaller than accessability minimums. This change
uses rems instead, so -small and -smallest will be the same sizes
everywhere on the page.
If -small or -smallest were used anywhere where parent-relative font
sizing is expected, this patch will change the size of that text. This
is only a problem if the new size is smaller than the old size, as any
sizes smaller than -smallest are an accessability issue. I looked for
any potential problems, but didn't see any.
Bug: T282315
Change-Id: Ib578f2cc4597b4dbfb5d1f5e4842962433af3748
Placing the text overflow on the span instead of the anchor element
prevents issues like T287522#7272991 from occurring.
Additionally:
* Uses the `text-overflow` mixin on every toggle list item label instead
of just the user link item as it simplifies the logic and presumably
we'd want any text that overflows the menu to be handled the same.
* Changes the anchor element to use flexbox/align-items to vertically
center instead of relying on `vertical-align` both the span and the
icon. Eventually, this should be put into core (see
I029f97ba9d5e7f46c8aa175d9a6bbb45ef9615df) but we have to remove all the
overrides that use vertical-align first.
Bug: T287522
Change-Id: Ie0fbff9dfaf8444c76125df52931a687730b4ad1
`.toggle-list-item__icon` sole purpose appears to have been to apply
`vertical-align: middle`. However, this is already being fullfilled by
.toggle-list-item__label. It is also causing the labels to not be
vertically centered.
This will also fix the ellipsis not being aligned (T287522#7264959) when
the text overflows.
Bug: T287522
Bug: T288306
Change-Id: I2d434d1d2b90eab16fc96fe8bb1f0738e5c6921b
Note: This menu already has text-overflow: ellipsis, but didn't have a
max-width applied.
Bug: T287522
Change-Id: I51fd7f4b822410190290bef6c962997bb5e47e4f
No longer needed now that we use eslint-config-wikimedia
version 0.20.0, which no longer includes that rule.
Bug: T286838
Change-Id: Iab8fc560c21734cde1b6822eccadd7da13645a26
Follow up to 27525d0bf
During task sign off Nick raised the concern that new HTML
can be served with cached CSS for up to 5 minutes after a deploy.
We decided to restore the class for one deploy cycle.
Bug: T172626
Change-Id: Ie5a2e45f31a468bbe425a27236ad1255950807a1
