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
No longer needed for Wikimedia wikis after the HTML caches expired.
This reverts commit e951a09913.
Change-Id: I5eda153e3368f6a7f9d2f88e336e02b65d01f2b5
Changing 'opacity' from 1 to other values can cause the browser to use
a different text rendering method, producing unpleasant effects.
We still have to use 'opacity' to change the lightness of the arrow
icon, so move it into an :after pseudoelement.
Bug: T179988
Change-Id: I19c5eafb9ab7e652f2661144abc1e03b381f5ff4
Aligning VectorMenu items horizontally with menu handle and
set `padding` consistently to `8px` – taking into account
different `font-size`.
Also removing unnecessary duplication of `margin-top` as `margin`
is set in same rule.
Bug: T179782
Change-Id: I30e9b4e50589ef09a0e5dcb0e6c4486e7779a39d
Remove feature flagging of print styles
Changes:
* Merge experimental module into skins.vector.styles
* Update skins.vector.styles RL class to support LESS variable
* Remove feature flag class in HTML and LESS (update indents in
LESS file)
Bug: T178028
Change-Id: I8d5c59c5c9f415ffbd7fa41a512cbea87887e9e7
Optimize and unify markup of SVGs and align to
WikimediaUI color palette where easily applicable.
Also removing three unused image files.
Bug: T153043
Bug: T178867
Change-Id: Ied457ef84357374e66db9e1936ce1b754d53cfdb
Bringing appearance and behaviour closer to standard widget like
DropdownWidget:
- Amending color to be (closest) aligned to WikimediaUI color
palette, but switch normal and `:hover`/`:focus` state in order not
to be too disruptive of a change and align with rest of Vector tabs,
- removing obsolete JS functionality as IE 6 as only major browser
affected does receive the menu items as tabs nonetheless and replacing
with simple CSS selector,
- removing unnecessary and obsolete images and
- Lessifying selector
Bug: T153043
Change-Id: Ia15480162bb8f923d0e9b6e42ca90c2c880978de
The logo is configured as a relative URL.
CSSMin encodeImageAsDataURI requires a file path.
There seems to be no reason to use a data uri here.
The print stylesheet is loaded on page load so the image
will be downloaded before a print action takes place.
Inspecting I788bcecadf26e4e5558b5b37e6fb1b2e9378277e
using a data uri makes little difference to the synchronous
nature of a print.
Bug: T177800
Change-Id: I0254ae8e360f09fe1c786695510550c7fec02026
