Commit graph

7 commits

Author SHA1 Message Date
jdlrobson 0ba99a1e97 Make sure Vector skin preferences always follows skin
Sections can be nested. Using rendering/skin as the parent
means that Vector's skin preference will always come straight
after the skin preference and before Popups.

A change in core is needed to update the selector for the element which
shows/hides the subsection as well as provide a generic message key to
replace the one inside this repository.

Note: If the "Vector" specific heading is needed, we can achieve this
with a little more work but that is a conversation for another time.

Depends-On: Idd06bcfe7935e16732a6a95c1253dbf95c8aca2e
Bug: T246162
Change-Id: I4be9764ddca186e5bfd493678afd62d446072e8f
2020-02-29 00:35:50 +00:00
Stephen Niedzielski de76ab59c1 [Special:Preferences] [PHP] Add skin version user preference and configs
Add a Vector-specific user preference to Special:Preferences for
toggling skin version, either Legacy Vector or the latest Vector.

The presentation of the new preference section and the default values
for anonymous, new, and existing accounts are configurable via
$wgVectorShowSkinPreferences, $wgVectorDefaultSkinVersion (to be used by
the feature manager in T244481),
$wgVectorDefaultSkinVersionForExistingAccounts, and
$wgVectorDefaultSkinVersionForNewAccounts. These configurations default
to the fullest experience so that third-party configuration is minimal.
See skin.json for details. The configurations are each tested in
VectorHooksTest.php.

When presentation is enabled, the new preference appears as a checkbox;
enabled is Legacy mode and disable is latest. There are a number of
unfortunate details:

- Showing and hiding a checkbox is supported by OOUI. Showing and hiding
  a whole section (Vector skin preferences, in this case) is not so this
  additional client JavaScript functionality is added in Core (see
  Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377).
- Stylization as a checkbox is wanted. However, the implied storage type
  for OOUI checkboxes is a boolean. This is not wanted in the event that
  another skin version is added (e.g., '3' or 'alpha'). As a workaround,
  the preference is converted from a boolean to a version string ('1' or
  '2') on save in Hooks::onPreferencesFormPreSave() and from a version
  string to a checkbox enable / disable string ('1' or '0') in
  onGetPreferences(). There a number of test cases to help cover these
  concerning details.

Documentation for overriding the skin version as a URL query parameter
is provided in anticipation of T244481.

Bug: T242381
Bug: T245793
Depends-On: Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377
Depends-On: Ifc2863fca9cd9efd11ac30c780420e8d89e8cb22
Change-Id: I177dad88fc982170641059b6a4f53fbb38eefad6
2020-02-26 12:56:10 -07:00
Volker E 5a4a589916 Unify user messages for Vector.js and Vector.css
Those messages have been untouched since introduction, but should be
unified. They are put on top of corresponding pages like
https://en.m.wikipedia.org/wiki/MediaWiki:Vector.js

Change-Id: Ib40a38dba553bf10070fedf368ba8ea581d2b4b9
2020-02-19 14:10:42 -08:00
Timo Tijhof b843094a2d Re-implement and improve mw-jump links with pure CSS
* Improve their accessibility by giving both links
  a full label "Jump to x" and "Jump to y" instead
  of "Jump to: ", "x", "y".

  This also makes things much better for localisation, for which
  we generally discourage use of concatenation.

* Use pure CSS for the toggling of the visibility on focus,
  instead of relying on JavaScript. Especially given the
  JS comes form core's 'jquery.mw-jump' module, which is
  considered technical debt per T195256. Alternatively,
  that could be copied to vector.js, but pure CSS
  is possible, so why not.

* Use plain <a> links in the HTML instead of wrapped in a <div>.
  This solves the long-standing problem whereby the margin
  between #contentSub and #mw-content-text had to be awkwardly
  negated and overridden in core and on various to make sure that
  the wrapper itself would become visible as needed, in a way that
  has margin around this. This whole problem doesn't apply when
  simply using inline links that aren't part of the regular flow
  with .mixin-screen-reader-text. On focus, the individually
  focussed link appears in regular flow, without the need for
  any custom styles.

* This uses :not(:focus) to naturally make it render in the default
  way on focus, and visibibly hidden/clipped otherwise.
  This is supported in IE9+ and Android 2+.
  There is a way to make it work with CSS2 for IE7-8, by applying
  the mixin to '.mw-jump-link' only and then undoing all of
  'position', 'width', 'height', 'clip', and 'margin' on :focus.
  But I'm not sure that's worth it here. The fallback in IE7-8
  for not supporting ":not(:focus)" is that the accessibility
  link is simply visible always, which seems like a good fallback
  for accessibility, and doesn't hurt anything.

Bug: T195256
Change-Id: Icaadb290f692b3617688d32cbb66dfb007f1c82c
2018-05-24 00:08:02 +00:00
Siebrand a5496bcd75 Revert "Update namemsg to convention"
My bad... skinname-<skinname> is used in core to get the skin name.

This reverts commit ac0d123ba8.

Change-Id: I3c7780f9f08081238744fde094804ea8f5dd191a
2015-09-28 09:42:39 +00:00
Paladox ac0d123ba8 Update namemsg to convention
Bug: T113632
Change-Id: I86323ac69d420927c852eb9197fba3d589e73f1b
2015-09-25 18:26:57 +01:00
Bartosz Dziewoński d28f09df31 Move Vector skin from core
This is the final step of the process described at
<https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki>.

Corresponding core change: Idfc38503.

Change-Id: I84fcf7ce6385b8323544cafe6912a00f1886d20d
2014-08-07 13:38:34 +02:00