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
Reducing selector specificity and cleaning up CSS as in reducing
properties and putting main colors on top of selectors.
Change-Id: I91959f07404382fcc143607ab4cd5cf0c9aed13e
Aligning
- `border-color`
- `:hover` `border-color`
- `border-radius`
and introducing `transition` to be on par with inputs elsewhere.
Bug: T177808
Change-Id: I41c2719c13935d07f4310c0c752bdfc7377d8670
Removing fallback color from Vector tabs, that isn't part of
WikimediaUI color palette and isn't needed at all resulting
in a worse than necessary appearance.
Bug: T153043
Bug: T168420
Change-Id: Ia9790435dd3ec4df47b70d1a007fca7af79686c9
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
Both of these survived across many rewrites, I tracked down the
original commits that added them:
* footer.less: Added in 6d5dca5a899d45512c1031c4235f26cc755b933b in
MediaWiki core (rSVN62030) as a workaround for "weirdness" in IE 7.
Users of IE 7 experience much worse weirdnesses when viewing pages
these days.
* tabs.less: Added in 299d1f328c2ad1475c8a1ac19b4fa07fc087d239 in
MediaWiki core (rSVN53247) under a generic label of "RTL fixes".
After change 5d0a07bf9d this is
actually a no-op.
Change-Id: Iac3d2a26438226a3e23e067780c4b2810ac4903f
Follow-up to 5d0a07bf9d.
As it happens, it actually doesn't matter whether this
element has 'float: left' or 'float: right', the
rendering is exactly the same. Let's remove the @noflip
for consistency with .vectorTabs, .vectorMenu etc.
Change-Id: I167c5f6cab7fb85344a558b632b38cbca85fa37c
Follow-up to 5d0a07bf9d.
See T48947#3641618 for a detailed explanation of the
problem this is fixing. Essentially, our CSS has to be
compatible with both new and old HTML to avoid problems
with cached pages on Wikimedia wikis. To do this, we
add a CSS class to the body and make the new CSS only
apply on pages that have this class. This patch should
be reverted when the caches expire.
Bug: T48947
Change-Id: Icf26e6690b59f470765b2634534d18d2df25ee2a
I really should not have merged I30e0642d3cb93c4d9a8b2bdfb7f04912d8ca8649
without getting this fixed first.
Bug: T56919
Change-Id: I870591e63b89f05d7e3714081340c76dcf9f55ac
By changing the display of the table of contents we'll make sure that it
doesn't try to occupy the whole page width. This is useful when an infobox is
floated to the right of the table of contents.
Bug: T174957
Change-Id: Ifc808bdd2b65867d14278b12735103c761fb8111
tabs such as read/view source are collapsed into more in screens
whose resolution is less than 700 px so that they don't wrap to
the next line and cover the content of the page
Bug: T56919
Change-Id: I30e0642d3cb93c4d9a8b2bdfb7f04912d8ca8649
