* renderPortals() - Takes array only, enforce this with a type hint.
* renderPortal() - Actually takes either array or string as $content,
fix the type doc to match the code.
* renderNavigation() - Simplify by removing support for non-array
$elements, fixing one caller.
This and other minor changes are tracked under T140664, which intends
to reduce code complexity in Vector to (potentially) make it portable
to an HTML template.
Change-Id: Idc95d023a55c83450b041109745cfbcbcd04f580
The naming the parent classes of these is quite confusing.
Specifically how "SkinTemplate" is not a skin template, rather it is a Skin
subclass that *uses* a template.
The "skin template" itself, is VectorTemplate << BaseTemplate << QuickTemplate.
Change-Id: Ie8997c5390d24cd38cdb12f97a87f8868a0b00d2
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
Instead of implementing keyboard (and mouse click) handling in
JavaScript, put an invisible <input type="checkbox"> into the
dropdown handle. It can be focused and toggled using keyboard
actions like a normal checkbox. This checkbox also takes over
the duties of handling mouse hovering and clicking.
Old JavaScript and CSS are left in place for compatibility with
cached page HTML, to be removed later in a follow-up.
Bug: T168080
Change-Id: I27532140b06c97921f1cfb64e44bff814d99a358
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
