The SkinVector implements IContextSource, thus it has to provide
the getConfig() method. Vector skin is currently using
it's own `vectorConfig` in one place and it passes the VectorConfig
to the VectorTemplate class. Sadly the VectorConfig is the same
thing what $this->getConfig() provides. There is no need to make
this code more complex by handling two different config containers
which at the end are the same GlobalVarConfig instances.
If we decide to handle VectorConfigs differently, let's thing it
through, for now we should simplify code and remove all uncessary
logic. Thanks to that, there is also no need to override the
setupTemplate().
Change-Id: I89c8a77f7d96f867c8c72e61f9e104e14d9512d9
With this change the constructor of the parent class gets called like if
there is no local constructor. This allows the ancestor classes to
initialize themself in their constructor.
Change-Id: I4ec1ec935afa25b59be4020fca9ac71f23e62ad0
Regression from 74b9803d9a, caused by a bug in LightNCandy which
caused {{foo}} to render "0", and {{#foo}} to pass as true with "0", but then
in {{#foo}}<b>{{foo}}</b>{{/foo} render as empty string producing "<b></b>".
In other words, the conditional is passing and the inner block is executed,
but the placeholder is mistakenly converting "0" => null => "" (empty string),
causing the <h1> to render but without any text in it.
Work around this bug by simply removing the conditional. Several other skins
already don't have this conditional and it's unclear why or in what
situation MediaWiki would send OutputPage to SkinTemplate without a title.
I think it would make sense in such rare case to still have a consistent
layout for extensions and gadgets to interact with and not omit the H1
element, but render it with the value that OutputPage gave it, even if it
is the empty string.
Bug: T219864
Change-Id: I6e04b512d2fe2e949ff5385cb38ceebe392fb255
This reverts commit a3ca2c3e16.
Reason for revert: This requires wider discussion before moving
forward, and a more complete implementation even once we do have
consensus.
No associated task exists on which to view or continue this
discussion: linked task briefly mentions Mustache in general as an
option as part of a much wider topic, but doesn't concern this
specifically.
Issues that should be discussed include:
* What the intent even is here: is this for one skin only? Is this
the intended path forward for all of them? Depending on which, we
have other issues: for the former case, that it is quite
unhelpful in terms of maintenance and further development having
more random code diversity out there, especially in this
half-completed state; or if it is indeed intended for all of them,
that an RfC is needed before anything is merged, as that is a very
significant change.
* That using Mustache in MediaWiki does add (usually minor)
performance overhead; we need to clearly establish in the task that
this is indeed worth it here.
Change-Id: I0bafa55b554aa8a38553e20c75859ec5eec2c062
The VectorTemplate class extends BaseTemplate, which has defined
this method since MW 1.25. The Vector skin master branch supports
MW 1.29+ only.
Change-Id: I83c6add9e8c02df028ca5905934e7d367dbe2209
Xml::expandAttributes() outputs a space at the beginning before it
outputs the attributs.
This change avoids a double space between the attributes.
Before this change the HTML contains:
<a class="mw-wiki-logo" href="..." title="...">
After this change the HTML contains:
<a class="mw-wiki-logo" href="..." title="...">
Change-Id: I486d26bd56a4410766f40b78466c2f3559f3a1ff
Before this change the HTML contains:
<div id="p-personal" role="navigation" class="" ...>
or
<div id="p-personal" role="navigation" class=" emptyPortlet" ...>
After this change the HTML contains:
<div id="p-personal" role="navigation" ...>
or
<div id="p-personal" role="navigation" class="emptyPortlet" ...>
Change-Id: Ic686b958940afc958693d0031ac31e5f783960a9
Unordered lists can be absolute positioned down to IE 7.
Outdated selector `.vectorMenu ul` remains for a release cycle
until HTML cache is renewed.
Bug: T209558
Change-Id: Id18ca9a8d705572b1f7e17920ef52b80e9aec373
* 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
