Core mediawiki.feedlink sets `a.feedlink {padding-left: 16px;}` to
establish proper spacing around the feed icon background-image. That
rule was overridden by a much more specific rule for the mobile menu,
causing the text to overlap the icon.
This change duplicates the padding-left rule at a higher specificity,
fixing the overlap problem.
This could also be fixed by significantly increasing specificity for the
rule in mediawiki.feedlink, but that would break the existing skins and
extensions that intentionally override it.
This patch has a soft-ish dependency on I897b85d3e77233b858ee85be263a14e401fe5fd2
to work correctly when the page is loaded in mobile format. Without that
patch, an empty space would be visible where the icon should be unless
the page was loaded in desktop format.
Depends-On: I897b85d3e77233b858ee85be263a14e401fe5fd2
Bug: T291274
Change-Id: Id427653eb21194085853de903624b9a537eeece6
Changes in HTML markup that fix various bugs and lead to consistencies
with other skins:
* firstHeading now has `dir` attribute
* `tagline` message no longer parsed - plain text only - this is consistent with
other skins
* printfooter now child of #bodyContent
* #ca-view is outputted (but hidden with CSS)
* Order of attributes on #p-search-label changed
* Search input form elements are no longer self closing
* The #mw-searchButton element gains class mw-fallbackSearchButton
* The generated-sidebar class is no longer present on sidebar portlets,
consistent with other skins
* The print link disappears when ElectronPdf is installed so there
are not two print links.
Changes in functionality:
* Previously (in getCactions) a nomobile class would be added if
less than 2 tabs.
If not 1 tab, more would be appended. This is dropped.
Bug: T285989
Change-Id: I03d0dc1dad23894e7e64ceeb8956692316265144
* Link color comes from the elements ResourceLoaderSkinModule feature
* MonoBook link colors are overriden in skin variables
Depends-On: I799b46664f01c5631fb9d1ae4f5c43caeeaac818
Bug: T288739
Change-Id: Ifbe2394f2f5beb417a4aa5b288a0e906ed10a691
Follow up to c1ca90ce4b
the #p-personal li a is trumped by
the skin--responsive selector. Store the rule next
to the existing link rule to avoid this.
This stylesheet loaded by both modes so works in both.
One with the skin--responsive prefix and one without.
Bug: T288788
Change-Id: Ief4fa9dbbd48f2c6f73a58a73d64255438cd938e
Cleaning up the `text-transform` mess and making this specific
rule simpler for the different languages and skin variants like
responsive skin.
Follow up to c1ca90ce4b.
Bug: T97892
Change-Id: Id4b3a3c23396728fa5910b7acfcf618b281390ca
This is already added in `skin-responsive.less` so adding it
a second time means the selector no longer matches.
Bug: T288681
Change-Id: I4b08561f8848dc5f8545f5dc42add8b5ec286ca8
MonoBook supports two modes - one that is responsive and one that
is not. To do this it adds 3 modules. These can be reduced to 1
module by loading all the code and adding client side checks to
determine whether to use it.
The skin--responsive class is added by core for responsive skins so
can be used to make that check.
This does lead to additional download for all users (particularly
the addition of oojs-ui.styles.icons-alerts) but given the default
behaviour is to load these, and non-responsive skin requires an opt
in I don't see this as a problem.
Thanks to gzip the increase in render blocking styles is minimal:
Before:
skins.monobook.styles: 15.21KB
skins.monobook.responsive: 16.14KB
After:
skins.monobook.styles: 16.63KB
See bug for QA plan.
Bug: T285492
Change-Id: I76bb644145539c8ec0220704c8fe9a78a4819c03
This was moved to a core preference as part of T285402
The migration was handled by a #user-notice
Bug: T285402
Change-Id: I25fe3d32ad929924034db06b5a95bab6a3a3a727
