Make sure the print wordmark is readily available for printing. In
addition to embedding, pre-render the wordmark outside the viewport so
that the print dialog doesn't block image rendering in the print view.
Bug: T169826
Change-Id: I788bcecadf26e4e5558b5b37e6fb1b2e9378277e
Logo cannot be displayed as a background image because it won't be
visible in print unless the user prints backgrounds too.
A sample configuration looks like this:
$wgVectorPrintLogo = [
'url' => 'https://en.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-en.svg',
'width' => 174,
'height' => 27
];
The solution presented in the patch has a downside of not being able
to scale images down if their dimensions are bigger than the
dimensions specified in the config variable. For example, if we want
to go with an SVG image, then IE8 won't be able to render it.
Alternatively, if we want to go with a PNG image, its dimensions need
to match the exact dimensoins in the config variable, otherwise the
image will show up larger or smaller depending on its dimensions.
A more complicated approach of scaling images using `transform: scale`
hasn't been used because we wanted to keep the configuration simple
while supporting the majority of our users. With the current change,
we can reuse the existing configuration options from Minerva, for
exmaple. It would look something like this:
$wgVectorPrintLogo = [
'url' => $wgMFCustomLogos['copyright'],
'width' => $wgMFCustomLogos['copyright-width'],
'height' => $wgMFCustomLogos['copyright-height']
];
Bug: T169826
Change-Id: If8f9f8d95fd3c955ece37d6c8ab6995596189667
This affects the four tabs menus (namespaces, variants, views, actions).
Other menus (personal menu and sidebar) have already been using it.
We need some minor overrides to get the same results as the hand-built
HTML, but I think this still makes the code a lot nicer.
The output is the same as before, except for unimportant whitespace
differences and the order of some tag attributes.
I tested this with several extensions and configuration options that
mess with the tabs:
* $wgUsePigLatinVariant = true
* VisualEditor extension
* FileAnnotations extension
* FileExporter extension
* Viewing the page as administrator
Change-Id: I2d1255442abf5fa4bac2de1b084d0bcacbba7d0f
Tones down license information
and makes last updated primary information in
printed view
Additional changes:
* variables now inherits from mediawiki.ui
Bug: T169823
Change-Id: Ie678967a27baec8715cf86b6a0f7e7651f867be1
Additional changes:
* Define variables for fonts and use them
* Group and make clearer where fonts apply
Bug: T169823
Change-Id: I0b7d557048859936f2eb2f646202bc8071bb84ba
Less doesn't allow to nest like this. It creates the invalid selector
`.vector-experimental-print-stylesbody`
This is a follow up to I453ae43099796a74c39d965b796f2fa13942106c
Bug: T169823
Change-Id: I9cc2f474fdcafdcc68378185391607b72b0f667a
Removing irritating dropdown arrow position transition
on menu tabs. It is the only place we're using this and it seems obscure
and not helpful to the users from UI Standardization point of view.
Bug: T68698
Change-Id: I8d30108b86b47358349de2ea424c0ba7f67ee7e2
These are feature flagged to allow editors to test before making
them the default. A class is added to the body tag to allow us
to switch between old and new styles at a later date.
To start with we introduce some typography improvements.
Further iterations will focus on other elements.
Changes:
* headings were previously diluted in the body content and difficult to spot.
This evens out the spacing between last content and its own content block.
* clear ownership of <p>s with its heading
* We would like to match Latex style body typography with single column.
The new styles reduce the number of pages by around 20-25%
* hyperlink underline -
This is a community requested feature. We do not use color in print styles
because it's printer friendly. Because of this, it is not possible to indicate
blue links in articles. If a user wants to know if this article exists on wikipedia,
it's not possible given solution.
We would like to underline the <a> tags in print styles.
it's better for accessibility as well.
Bug: T169823
Change-Id: I453ae43099796a74c39d965b796f2fa13942106c
Ensure vertical alignment of menu tabs (for example “More” button)
with link-only tabs by setting:
* `padding-top: 1.25em;` as on `div.vectorTabs span a`
* `line-height: 1.125em;` as on `div.vectorTabs ul li`
Bug: T171142
Change-Id: Ic4ef86589c6c3d442035f3d768cb9036e1ecc237
This was inherited from Monobook (r2881, b52a2a1567).
The #mw-panel (sidebar) was at `top: 160px`.
The #p-logo was at `top: -160px`.
This looks hacky so I set #mw-panel `top: 0`.
Bug: T170053
Change-Id: Ifb99ff36e3a9c530c944df2ea0a6c75759045c1c
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
With MobileFrontend installed applying
?useskin=vector&useformat=mobile will ensure that responsive vector
mode is invoked.
I'm keen to do this, as it would help to have more examples of skins
that are MobileFrontend aware as part of the work I am doing in
T166748
Change-Id: I81edd855a5e96400d1179fb10907fcc30ea43ef7
