Updating 'svgo' to v2.8.0 and newest Wikimedia SVG guidelines –
mainly around new whitespace features of SVGO.
Change-Id: I860dc7f00a6a3ce3f1bed56978a7cf560187146e
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
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
* 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
Set the top offset for notifications to match the height of the
top tab and link area. Also move this height to a common Less
variable to use in both places it's used.
Bug: T260262
Depends-On: I12db7c1745d17851f6421123a145de4cb916ad51
Change-Id: I679b7bba8d0c43c36c5911b30540e86a77125497
Having module definitions living inside SkinMonobook makes them
less discoverable. It also shouldn't be necessary - even if there
are soft dependencies on other modules.
A new file resources/optional-enhancements.js is added which will
load the two optional dependencies based on whether they have been
installed on the client.
Bug: T203023
Change-Id: If9a88db52deb0cc91d58cbb40693d4cd448eabbc
Hide the accessibility jump navigation links when printing
Also only show the last modified and copyright footer info and hide
all the footer 'places' links by default.
Bug: T250232
Bug: T136786
Change-Id: I039b523d009ddb4f5948dff456ef2845a93439fa
Use normal `background-image` properties with SVGs now
that IE 8 and Android 2.1 are removed from Grade C.
Also removing all fallback images.
Bug: T248062
Change-Id: Icd9cb9ea2a102467b5af3829f4dad0f2c5707aee
Turning it into a class selector similar and amending the distances
to not rely on `line-height` in order to prevent unwanted side-effects
in non Latin scripts.
Follow-up to I85b5172a851bcfbf00606f355453f591782f9cc2
Depends-On: I2edf9f40e5b4b9296195cb581e216f82b28933ca
Bug: T239657
Change-Id: Ia27b48d45ad3fa4ab2f517734bd0cbe0d94f5ed4
If RelatedArtcles uses the SkinAfterContent hook (depends-on patch)
and we move the hook out of the main content block (parent patch),
it needs some styles to remain consistent.
Bug: T181242
Change-Id: I9fc00c22fb5e5b7d363455abe9d85062e67c7dfa
Depends-On: Iebd759c0d1a536768d18953f372664df762d9e04
If the page was long enough to have a vertical scrollbar, the check
for `$( window ).width()` would be incorrect because of the width of
the scrollbar itself. The correct value is `$( window ).outerWidth()`.
But rather than deal with that, we can instead use the API
specifically for matching media queries [1], then copy-paste the
media query from CSS and not have to think about it at all!
[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia
Bug: T227916
Change-Id: I79478040620391f5391b10aee52134fde0b88adf
When the icons are clicked for the first time, they are replaced with
a JS interface by Echo code, so don't cache them in a long-lived variable.
Otherwise if the user clicks one of the notification icons, then
resizes the browser to a mobile width, and then resizes it back, we
would insert duplicate Echo icons.
Also rename the temporary variable per conventions.
Bug: T227916
Change-Id: I08f2e3d2e293d727ac4492d1fb6fe2c7c65df4ad
When the personal menu bar is wider than the screen (browser window),
it gets cut off on the left (and the overflowing links slide under the
logo and then off the screen, making it impossible to click them).
This is caused by the `float: right` rule added in 5a7e620. To avoid
this, add `max-width: 100%`, which results in the menu being cut off
on the right again (which lets the user view the overflowing links by
horizontal scrolling).
Bug: T226875
Change-Id: Id4186215cc069f283f8ebeca0db587e1f1369062
on personal tools
Echo badges, like all OOUI buttons and quite a few other elements,
hide their labels with a negative text indent. This does not work
properly with backwards text alignment (align: right in ltr
scripts). We can achieve the same visual effect as the text-align:
right on the personal tools, however, by floating the entire list
right instead, thus unbreaking the default badge label hiding
method and also rendering the skin more consistent with Vector,
Example, etc.
And this should negate the need for bonkers workarounds.
Bug: T226684
Bug: T226594
Change-Id: I0ed21a78feb1b1298c30b969a1c80a4323e74043
See core commit 1890f315a2d756b9fa31856f59437ade8aafea7a for the full explanation, but tl,dr: these classes haven't been used since 2005.
Change-Id: I52d7facccce955da9f66102b657a0e3627904167
Separating the two background images out is unnecessary when we already
have a single-image fallback jpeg for old browsers, and also breaks
extensions such as Theme and user/site css affecting the background image.
Change-Id: Ic869b84fb6d0c10b91a171fb1f842e2290d3bc0a
These removed styles match no elements in the
Special:Preferences page since the OOUI transformation.
Bug: T208923
Change-Id: If7df130c53bcbbc199a6e10a6d84dbcc8b4e087d
