Vector is the only skin that does this, setting 'position: relative'
for .oo-ui-windowManager-modal (normally 'position: static') and for
.ve-ui-overlay-global (normally 'position: absolute').
The override for .oo-ui-windowManager-modal caused it to create a new
stacking context, which is the only reason the 'z-index' override
worked. Use the right selector to override 'z-index' instead.
The override for .ve-ui-overlay-global was completely pointless and
it's surprising that it never broke anything.
Change-Id: Icd1dec43e2da9ef2090b18145099838de3a7890a
Add an example from the Math extension showing how the print styling
rule for font family is relevant.
Bug: T181138
Change-Id: Ib5a35b7a555c898d354c16077f44acf1e50f5ebb
When printed, math formulas appear best rendered in the same font as the
body, serif. Override dl and other sans-serif styling rules for all
printed images. e.g.: https://en.wikipedia.org/wiki/Frame-dragging.
Bug: T181138
Change-Id: I9755a23cbec8388964c27d938a7aea8e25fe2f7f
The revert looks like it has been performed incorrectly,
and I found a much better solution to the task anyway.
This reverts commit 7d2fc6df27.
Bug: T178028
Bug: T183640
Change-Id: Ib46c69b061b522fc6365459297ad3f3d4f4d0d0d
Override default font size for .oo-ui-defaultOverlay (0.8em) to the
same as content in Vector (0.875em).
Make it appear on top of the personal menu too.
Bug: T183069
Depends-On: I53888581f9e1da3b036166613c46cbc1085aa55e
Change-Id: I459aad271c0c15248e54e312b8bdc44ed244733b
In attempts to fix RCFilters menu overlap with other UI elements when
opening upwards, I1fe6b8b2c9 adds `z-index` rule to overlay element.
But as part of the same rule, `position: relative` is added which
cascades the absolute positioned overlay, causing it to appear in
natural flow of document, which causes menu positioning parameters
to render the menu detached from RCFilters.
Bug: T183442
Change-Id: I3f7db005730d045b2278753cfd655169a96c60a9
Currently the personal bar displays on top of it. This wasn't
visible until some popups started opening upwards rather than
downwards. We should fix this better some time...
Bug: T182711
Change-Id: I1fe6b8b2c9c1e4d12a9a4d2d1edd1ead269780cf
The issue I'm fixing here is described at
https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Hard_to_read_titles
The code I'm touching here is from 2014. I believe the issue is not new, but
pops up extremely rarely. Multiple conditions must met:
1. The user must use an extreme zoom (or an extreme font size), or a
super-narrow browser window. This is also how you should reproduce
this: make your browser window very narrow, and then start zooming in
extremely.
2. The issue only appears in namespaces where you can not move pages! This
is the case for the vast majority of pages on Wikidata and the reason why
it appears to be a Wikidata-only issue (which it is not). If you can move
a page, the right-most button is "Move", which is wide enough to be worth
collapsing, or is already collapsed.
If the right-most (":last") button is the watch star, the code believes it is
not worth collapsing it because the "More" button would consume more space.
This is true, but does not consider the other buttons that can also be
collapsed.
My code considers all collapsible buttons.
Change-Id: I6e94750b3b80940005f4d655e5e9b426d44b2ffb
The previous indicator was removed in 7a42af066b because of a position
transition. The new indicator has no animation.
An indicator is useful to distinguish between the hover and the click
actions.
Change-Id: Icf765d4985aea36e4f4f6653e769aafaf3c30d07
Translation updater bot
jenkins-bot
Bartosz Dziewoński
Stephen Niedzielski
libraryupgrader
Paladox
Moriel Schottlender
petarpetkovic
Rafid Aslam
Yifei He
Albert221
Umherirrender
Thiemo Mättig
Ed Sanders
Fomafix
Timo Tijhof