With these optimisations applied, there is no longer any need for
the width value during most page views, and even for most resize
operations. As such, eagerly computing it ahead of time, even from an
idle callback, no longer makes sense.
It is still memoised because it's worth avoiding a recalc during
some of the code paths that need it. Also because this way the
logic stays compatible. I don't know for sure if all involved logic
would be able to handle the value changing over time.
Optimisations:
* Where possible, don't depend on jQuery width() working on invisible
elements. Specifically, don't depend on it giving you the width of the
element *as if* it were visible when it is invisible. When logged-out and,
when navigating special pages (e.g. Special:Blankpage), the #p-cactions
element is an emptyPortlet with `display: none;` set.
The animation logic was depending on initialCactionsWidth() providing
the width the element would have if it were visible. This is because
jQuery width(), will actually change 'display: none' to 'display: block',
force render virtually, compute the width, and then change back.
Instead of depending on this discouraged feature [1], move this calculation
to the code dealing with the animation and calculating it there, ourselves,
right after making it visible for real (but before shrinking it for the
hidden-to-visible growing expansion animation).
* Document our reliance on this discouraged feature for the remaining two
callers in expandCondition() and collapseCondition(). Both of those
need the initial width as-if visible and generally are not in charge
direclty of making it visible (so there's no better place to measure
it), and are in fact almost always called when the element is invisible,
thus pretty much exclusively depending on it, not even as an edge case.
* In collapseCondition(), optimise the logic to remember whether
collapsing is needed. This way, it won't need to call initialCactionsWidth()
if the loop iterated zero times (turns out to be impossible, but not
obvious from the code).
Follows-up 46f1d41 and 9b2bcbb.
Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
requestAnimationFrame (rAF) is called before styles are computed.
Performing a style read there can require a forced style
recalcution which interrupts the browser's natural rendering
life cycle.
To gracefully observe layout of the page without inducing the
cost to render it, it should be accessed after rendering.
A suitable API to schedule time there is requestIdleCallback.
In any event, if the code that needs this measurement executes
very early for some reason, it is still computed on-demand which
means it can't cause any functional regression.
Change-Id: I0d8d3a0b158fa3d9e0895760d0691757f918d91d
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 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
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 .vectorMenuFocus class was being added on the wrong element, so
the styles for it never kicked in. I think this has been broken since
4fabc910d2e1bb4581ac7a80f019bd22758d089b (August 2013), which is
understandable since the style change is near impossible to notice
(the little triangle arrow turns a slightly lighter shade of grey).
Change-Id: I0f7881afde9e01061aacf009033255774d0acd8d
The <div> was introduced in aba11a7b but this is not valid in HTML 5.
This change ommits the <div> and attaches the background image to the
existing <span>.
Cached HTML with the <div></div> does not matter for the result.
Bug: T169551
Change-Id: I04f7032b6f6bafe10548fde690f55de66b56f61f
This change is a follow-up to aba11a7b1c.
Do not deploy this change until HTML cache from before aba11a7b1c expired.
Change-Id: I631260d58229b1b70e2d4e55f8302f9769de3511
This change prevents that a middle click opens a new tab with the URL "#" and
prevents a wired outline around the button when selected of focused in Chrome.
The selector "> a" will be removed in a separate change which must get
deployed not before the HTML cache has expired.
Bug: T44241
Bug: T68388
Change-Id: I7255552d3bdec9e40727721b91630623ae24a08b
> JQMIGRATE: jQuery.fn.bind() is deprecated
Note that bind() is not removed in v3, merely deprecated.
Even after the jQuery Migrate phase, it will continue to work.
https://jquery.com/upgrade-guide/3.0/
Ref I3c3dedaa.
Bug: T124742
Change-Id: I6bbd8f829ecf987228c6a5abd32c84e4e088a9bd
Follows-up f354aafebc.
Avoid forced style calculation during page load. Instead calculate
in the very next animation frame. This is only a few ms later, but
makes a big difference by doing this outside the critical path.
Change-Id: I5805958781bf64d1e4a30f441ed7f57807072284
We were adding a .first CSS class to the portlet from JavaScript
instead of just using a smarter selector, which caused the incorrectly
styled portlet to visibly flash sometimes.
This was only useful for IE 6 (even IE 7 supports the sibling selector
'+', which we can use here), and we don't serve JavaScript to it
anymore. It would be neater to use ':first-of-type', but that's not as
widely supported.
Bug: T89542
Change-Id: I1904b3899c43bca52a6c996b8ce08c8bdf764aa0
