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
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
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
The hover effect is not a basic usability requirement.
Having this ancient cruft in our HTML depresses me.
Change-Id: I0ca5b3b6a6037a9ec733283c656996969cc020e3
The installer hardcodes and expects to find a "skin.vector.styles"
module in skin.json, so moving it into a hook broke the styles. Moved it
back into skin.json, and left a comment so future developers don't make
the same mistake.
The responsive code is now a separate module,
"skins.vector.styles.responsive", which is only added to the page output
if VectorResponsive is enabled.
Bug: T106747
Change-Id: I7540b7871531ef650e799f012477cef6cdd32fb7
Vector's own configuration properties should be fetched from
Vector's own config object, instead of core's config object.
Follow up: Ib611357bbce739b1d193abaf89c228ba52613d6a
Change-Id: I358a5c1876098a85d77e90b11b3bf4e77c0f6c78
The fields separator is a , not a ;
This is a common mistake, because it was in one of the first
blogposts that discussed viewports.
Change-Id: I0b88db484c906f3c717aced67360d0f899af8f1f
This functionality is off by default, behind a configuration variable
($wgVectorResponsive) by popular developer demand.
CSS/LESS code by James Hare, with tweaks and testing by Jack Phoenix.
Bug: T46387
Change-Id: Ib611357bbce739b1d193abaf89c228ba52613d6a
* Don't require a Config instance to be passed in the constructor,
as that breaks skins that extend it.
* Don't manually register the skin with SkinFactory, use $wgValidSkinNames
Change-Id: Ie8539027c17caff35c1fc52a56676763df667fd9
They do more harm than good.
We still have the "HD" and "non-HD" styles, just no smooth transitions
between them.
Bug: T85614
Change-Id: I52dd9883eb4e7df00f0613182d4adaa3f28fe5b7
