* 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
skins.monobook.mobile which was incorrectly identified as
a ResourceLoaderSkinModule is removed. This module was always
loaded in JavaScript alongside one of the modified modules
Bug: T287410
Change-Id: Ia1e15b606b3eee1ae442bd71765778269d11fd38
If the general skin-responsive setting is set, let it overide
monobook-responsive preferences
Eventually remove monobook-responsive when the affected users
have migrated to the general pref (or they're migrated, if necessary)
Bug: T285402
Depends-On: I4e567199a92c0492dac0561a5c7844f6c5c239e6
Change-Id: If6e405eaf1e4c3ac396fdcf2da31501ea3f65b53
For consistency with other skins, its easier to see how hooks are
invoked when they are separated from the skin.
The skin is also updated to use namespaces and modern skin registration
which has been available since MediaWiki v1.36.
Change-Id: I1c93d4e817b53c93eba47ee9086c86c5d75443e5
* Removes the class from site notice - this provides no styling benefits
inside MediaWiki and is inconsistent with other skins. If site styles
need to target this element they should use the siteNotice id
* Replaces mw-body-content class with monobook-body and adapts existing
styles. The mw-body-content class will soon be applied to
$this->get( 'bodytext' ) instead. The core change
I3a91b294fcb3724cd46743e497dff723de0490a6 will shift this class to the
child element. There are no styles outside Monobook that rely on this
class and only 45 Monobook specific site/user styles that could be impacted.
The new class is prefixed monobook to avoid confusion with classes that
originate in core that are prefixed `mw-`
Bug: T279388
Change-Id: I90d85c21f4a62e6697f24e3ce388445a0a53c2b0
As already mentioned on the task, this has already been made available in
the interface ResourceLoaderSkinModule feature, hence redundant in here.
Bug: T278364
Change-Id: I071f43836bed9991bbefd71b7b0348c2eb13bbec
