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
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
To some degree the literal HTML was (maybe) useful and self-documenting
at some point when the template was really simple, but until and unless
we really use an Html template for this, it's probably a lot easier to
maintain, understand and review (incl. from security perspective) if
we consistently use the Html class abstraction.
For now, I'm only focussing on cases where there is mixed literal HTML
with embedded PHP statements. The cases where HTML is created plain without
embedded PHP I'm leaving untouched for now.
Any case where attribute or content comes from PHP, use the Html class
instead to clearly indicate which values are escaped, and which are not.
Change-Id: Ib2d6425994918b0c17ef29c1b5d0f9893f61a889
Consistently do the following in this file:
* Consider '<?php' the start of a block indented level, like other code blocks.
* Don't increase indentation between the opening of '<?php' and the top scope
within, consistent with other PHP files and most of this file.
* Don't manually create tabs or new lines to try to align with the HTML,
this is a pointless excercise that already doesn't line up anyway. It just
creates more arbitrary whitespace. Most portlet, personal, sidebar stuff
is already not doing any indentation, this removes some of the remainder,
at least in places where it was manually being emulated. The natural stuff
stays for now.
* Remove some arbitrary line breaks.
Change-Id: I42627ac8473604c7c1309db370302f5ee5f1df0e
