Looks like the SkinVector::getPageClasses is doing nothing, only
calling the Skin::getPageClasses and returning the output.
Change-Id: I5becaa1505d46cbf9a07b8bfe73ddf324b740876
Also bumping headings to not go smaller than running text and
leaving footer text unchanged.
Bug: T183105
Change-Id: Ifb57a6261b6908f23dca52e4544c58ec1935009a
Some LESS parsers will get confused with the lack of file extension.
It's better to be explicit and in alignment with recent change in core
I379334d7729e587a2a00.
It was already weirdly mixed in this repo with some imports featuring
extension and some not.
Change-Id: If5065cf9e30289de9b4fd33315bd65b75959ecb7
Applying calculation measurments to have full pixel equivalent to
`em` based properties that are necessary for user font scaling
preference ability.
Also:
* Changing watchlist icon to `em` based sizing and remodulate positioning
by putting it on `:before` elements.
* Changing calculation of `.vectorMenu h3` to acommodate down arrow indicator.
TODO:
* Remove the extra <span> (in separate commit, to make it easier
to rest cache compat during code review).
Bug: T236410
Change-Id: I8237976e05870378be3430e3e14c3e6993de3dc1
Removing
- `clear` when used with `position: absolute`
- `float` when used with `position: absolute`
Change-Id: I14661c4078e4d5f776596842674cef7e7ddcf708
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
Replace raster image gradients (before base64 embedded) for modern
browsers by CSS gradients. Only relying on conventional image URLs
in browsers that don't support linear-gradient.
Also
- adding a darkened border for inactive tabs to harmonize visual
perception of border as one continuous line and
- DRYing tab separator selectors, saving ~8 bytes gzipped.
Bug: T63099
Bug: T121730
Change-Id: I76d32b84ddff06a2c7ef983e6f89ca6e74257a67
Replace raster image gradients (before base64 embedded) for modern
browsers by CSS gradients. Only relying on conventional image URLs
in browsers that don't support linear-gradient.
Also updating color to Wikimedia Design Style Guide color and
removing obsolete *-ltr/*-rtl images that have been introduced in
MW core 1.16.0beta1 but have been replaced by unified 'portal-break'
image afterwards.
Bug: T63099
Bug: T121730
Change-Id: Id0ab5eb7d4a5751316ce750aff2dffbda62f6b09
Have been in since before Idfc38503d8397ffe where 'portal-break.png'
was still applied on `div.portal` and not ever after on `.portal .body`.
Change-Id: Icbaed3f9d41a46a0f5d17266c29703024ffc1412
