Currently one has to click save on "Special:Preferences" to reveal
the monobook responsive design option. As of
Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377 we can reveal this conditionally
when the Monobook skin is selected.
Depends-On: Idd06bcfe7935e16732a6a95c1253dbf95c8aca2e
Bug: T246296
Change-Id: Ibd74cc03f3ccbdc0042163c18ab0f71b6aa556f6
Since MonoBook is never cached on Wikimedia wikis, we don't need
to do anything about both modules being loaded in cached HTML.
There should be no differences before and after this change.
The change must apply to skins.monobook.styles and skins.monobook.responsive
as these modules never load at the same time (see setupSkinUserCss).
Bug: T242177
Change-Id: I5e69cd7f37f7b7a2b6325177b6688a426d92d57f
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
That way hook subscribers can use RequestContext and whatnot instead of having to resort to globals.
Change-Id: I1e4be7156aaea12fef75169bd0216140b9d50388
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
Add `@param-taint $contents escapes_htmlnoent` annotation to
MonoBookTemplate::getBox(). The method will escape the $contents
parameter if it's an array, but it will not if it's a string; Phan
can't distinguish the types, and assumes it always escapes. Use
escapes_htmlnoent to suppress warnings about double-escaped output.
Change-Id: Id8ef73f2efbe8d4d5510917d55dbac4e41b2b3a1
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
