* Standardise the menu markup. This means all menus in Vector will now
be wrapped in a div and will have a heading.
* All menus now have the vector-menu class. Styles specific to personal tools
are moved to layout since these are concerned with placement.
* The ul class will always have menu class.
* emptyPortal class is generalised into vector-menu-empty for consistency
with other classes and moved from common.less into Menu.less
* Standardise hooks - BaseTemplateAfterPortlet can now be run on any
menu.
Changes to HTML:
* lang and dir attributes are moved from the h3 up to the div element
.vectorTabs, .portal(s) and #p-personal now has hidden span element inside h3
* for non portals ul.menu" is now wrapped in a div.vector-menu-content
This change does impact the following CSS selectors which will need to be updated:
I see no matches for these selectors in code search.
```
#p-variants > ul
#p-namespaces > ul
#p-personal > ul
#p-views > ul
#p-cactions > ul
```
Using global-search.toolforge.org I see one match
for p-variants, 26 for p-namespaces, 30 for p-personal,
36 for p-views and 7 for p-cactions. I see this as acceptable
breakage provided a user notice is sent out which it has been
(T252447)
Bug: T249372
Change-Id: Id59234aa6b822a24848386bdc04d8d7ed37ca145
This unblocks reverting HTML5 elements.
A longer term fix is brewing in
If6b10b0ddcbd4b21dd13a2813e60b604c3a23415
Change-Id: I85659d22dc2f2a803c2a7b1e57033b18900353df
Hope you enjoyed the pun, as this is an unfortunate bug to have
slipped into production.
While previously we breaked after finding the selected items
prior to I098e6921e8f7ef65dacacf09b9c25f70c945e58e we shouldn't do
that any more as we're using the same loop to iterate through and
generate our items!
Bug: T251521
Change-Id: I92c28e8fba684d7977dfd207ff939ac07a7a07af
To complete the refactor, the Portal is also refactored
as a Menu using the getMenu function.
An old code path supporting portals outputted by hooks with
strings is marked as deprecated to simplify this code in future.
array-portals-first -> data-portals-first (the value is not
an array)
Changes:
* $this->getLanguages and $this->getToolbox() always returns an array (see BaseTemplate)
but we previously supported portals made using raw HTML. Let's move away from that
behaviour and deprecate it.
* Hooks are moved into buildSidebarProps and marked as deprecated where possible
(SkinTemplateToolboxEnd). SidebarBeforeOutput can be used instead.
Bug: T249372
Change-Id: I2549af3e24e5d51c09e9a88ca50a0d9b2e154c3f
The classes were recently changed so provided this is merged before
next branch cut no need to worry about cached HTML.
Bug: T249073
Change-Id: Ib20c7a359bda858df89ebb245e682d321dd5acd0
the PersonalMenu should be generalised. In future we will use it as
the template for all menus
Bug: T249372
Change-Id: Id1c43d2e9eefef1d7aec45f0137e27f10ad935df
The get method while well intended, adds an unnecessary level of
indirection to our code and can't be easily typechecked. Using
the methods directly (which if you review core code, these all
directly map to those methods) makes the code much more of a pleasure
to read.
Bug: T251212
Change-Id: Ibb2a69801d3b004a0a174308d3ac04d1d228807c
The opt-out link was missing a tooltip which is important for
accessibility and to help people gain more context as to what it does.
Bug: T250093
Change-Id: Ie6cbaf5c941615d1662700415b8f1823987a563d
Changes to support feature:
* ResourceLoaderSkinModule logo features are dropped
* New layout provided given the fork in layout between legacy and new.
* Legacy sidebar styles now pulled out
* breakpoint styles are not carried over from legacy Vector
The new Vector layout for now has one breakpoint.
Changes to storybook:
* The storybook script now pulls down image assets so that the logos can
be shown in storybook. The script is adjusted to make use of a static folder to
serve these images.
Note:
* The legacy mode is not touched as part of this patchset.
* The personal menu is unaffected by this patch and is out of scope.
* The alignment issue is noted, but will be solved at a later date.
* Changes to portal are out of scope.
* Adding storybook for modern descoped, given its not possible to load
both legacy layout and modern layout inside a storybook at current time.
Sample config:
$wgLogos = [
'icon' => 'https://di-logo-sandbox.firebaseapp.com/img/globe.png',
'tagline' => [
'src' => 'https://di-logo-sandbox.firebaseapp.com/img/tagline/en-tagline-117-13.svg',
'width' => 117,
'height' => 13,
],
'1x' => 'https://en.wikipedia.org/static/images/project-logos/enwiki.png',
'wordmark' => [
'src' => 'https://en.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-en.svg',
'width' => 116,
'height' => 18,
],
];
Coauthor: Aron Manning
Bug: T246170
Change-Id: Ibc4b055150761388a6b78f9127da342c451ce0e7
In future we'll convert VectorTemplate to SkinVector. In preparation
for this we create wrapper functions getMsg and getConfig so that
the interface for VectorTemplate is more similar to SkinVector.
Bug: T251212
Change-Id: I1f839d3147499d67e1c7cf71cf934bb7d20beedb
Move all the sidebar generation logic into a new VectorTemplate
function.
The name mirrors the function name in SkinVector. In future,
( I7a14f74728703c50874935e9d77b35ad9434b436)
we will move this code into SkinVector where it will be able
to call parent::buildSidebar()
Bug: T251212
Change-Id: I0a4838120f6ffd3d3d798f876e3463a3f16af95b
Going into the new version of Vector, we'll want to rewrite the layout
rules entirely and decouple the sidebar from the logo.
To prepare for this we will move the layout file into a legacy folder.
We also separate Sidebar styles needed for the legacy mode from the old mode.
This will allow us to make changes to the header in new Vector without having to touch
or test the legacy codebase via a new file layout.less and using the existing sidebar
code.
Bug: T246170
Change-Id: Ieb4f8f2b2f0e4f48d76a210ab30acd08e3e83bcb
In new Vector, the logo will no longer be present, so we need a more
future proof way of determining what the first portal is.
A new class `portal-first` is added (no decision about adopting BEM
has been made yet).
Cached pages will continue to use the old selector for now.
Change-Id: I6ac4493bb1f63686b48ff0c22b18d50d9fffb51d
VectorTemplate has various functions that repeat themselves, only
differing in their choice of names.
This refactor begins by focusing on the personal menu and introducing
a generic getMenuData function. Hardcoded `p-personal` is replaced with
an `id` template key and `msg-label` is renamed `label`.
Future patches will simplify VectorTemplate by using this new
function.
You'll note the resulting PersonalMenu.mustache file is identical
to VectorTabs. These will be merged in I098e6921e8f7ef65dacacf09b9c25f70c945e58e
Bug: T249372
Change-Id: I5ae44a1008b065381eeff93f9fa625be5c5a9de9
Adding `margin-top` property only with sibling selector for now
until cache is cleared.
Also removing already inherited from
`.mw-body-content` properties `position`,
`font-size` and `line-height` of same value.
Bug: T248761
Change-Id: I1ea5e08927a96ac69c1b65f248ae0420968b4d00
The new template 'index.mustache' drops the Navigation
template partial (component) - instead embedding it in
the master template given its lack of usability.
Note to reviewer: Please ensure index.mustache and
legacy.mustache are identical.
Change-Id: I580fe55ca6aeb35dae8afee41e87172a5a729c7b
It is not the most useful of components and adds an additional layer
of complexity similar to multiple inheritance chains that we find in
Object oriented programming.
I suggest we use index.mustache going forward for laying out the different
components and use components/template partials for reusable components.
Change-Id: I6fd5fe1c3d3826d737ccd8ed5a38890305664876
This commit is singularly focused on adding a link to the sidebar for
Vector, logged-in users. It does the bare minimum to fulfill the
requirements of T243281.
Additionally, it will help to answer the question "Do we need to use
abstractions (other than maybe different templates) to separate Legacy
Vector from Vector" by intentionally leaving out any abstractions in
order to make it easier to compare with a follow-up patch
(Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions.
It is a good thing to question whether or not we need addtional
abstractions in VectorTemplate and if they will help us as unnecessary
abstractions can have the opposite effect and just lead to further
frustrations down the road.
Therefore, I urge you, the reviewer, to let me know your thoughts! If
abstractions are viewed as not making our lives any easier, the
follow-up patches may be completely discarded and that's totally okay
with me. :) I think it's a good think to talk about now though.
Important changes:
* The VectorTemplate constructor was changed to allow injecting the
config, templateParser, and isLegacy boolean (only the config was
allowed before this commit). According to MediaWiki's Stable Interface
Policy, "Constructor signatures are generally considered unstable unless
explicitly declared stable for calling" [3]. Given that VecorTemplate's
constructor is not marked as stable, it is justified to do this without
warning according to the policy.
* Due to the above, the 'setTemplate' method is no longer needed and was
marked as deprecated.
* VectorTemplateTest was made to adapt to the new VectorTemplate
constructor. Additionally, it now extends from
MediaWikiIntegrationTestCase which my intelliphense server can pick up.
I *think* MediaWikiTestCase is just an alias to
MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed
to MediaWikiIntegrationTestCase in [2], but I'm willing to change it
back if there is pushback to this.
Open questions:
* What are VectorTemplate's responsibilities? To me, it acts right now
as a controller (because it echos the full HTML string from the
template), a model (because SkinTemplate::prepareQuickTemplate sets data
on it which it later retrieves through `$this->get()`), a presenter
(because it adds data tailored for a web-centric view), and a view
(because it renders HTML strings instead of letting the view/template be
solely responsible for that). Arguably, some business logic might be
mixed in there as well (because it checks to see if a User is logged
in/has necessary permissions to show x which my changes here add to).
This might not be a problem if we keep VectorTemplate relatively small,
but will it remain this way as we progress further in Desktop
Improvements?
* How do we write tests for VectorTemplate without exposing unnecessary
public methods? For example, if I want to test the `getSkinData()`
method to see what state will be sent to the template, how should I do
this? One option might be to use `TestingAccessWrapper` to expose these
private methods which is what
`VectorTemplateTest::testbuildViewsProps()` does. Another option is to
accept this method as public. Is there a better way? Keep in mind that
even with access to this method, there might be many things to mock.
[1] 0030cb525b/tests/common/TestsAutoLoader.php (L64)
[2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
[3] https://www.mediawiki.org/wiki/Stable_interface_policy
Bug: T243281
Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
This allows us to insert HTML underneath the first portal or wrap
the portal in a containing element in future if we want to target
additional CSS to it
Change-Id: Ied28d95407b8d59fc819bb07a2cce3242bd93088
Separate value type from value groups, to clarify that e.g.
something coming from a hook does not mean it should not have "html-".
Change-Id: I52fdd6995241e1d64f23fd8154997de813f674f4
CHANGES to index.mustache:
Changes can be understood by looking at the diff of
the file stories/skin.stories.js
The additional changes in stories folder export the data passed to
those templates. A new file is used as exporting any variable in a
file suffixed stories.js will be assumed to be a story entry.
The changes to index.mustache are as follows:
* html-footer is replaced with data-footer and Footer
component is rendered via template partial
* html-navigation is replaced with data-navigation and
Navigation component is rendered via template partial
CHANGES to Navigation.mustache:
Changes are best explained by looking at the diff to
stories/navigation.stories.js
and navigation.stories.data.js
* html-personal-menu is replaced with data-personal-menu
Bug: T245456
Change-Id: Ie96e92447a932b8a7f3844df277a1d31a2af423c
For better encapsulation and future possibility to create Skin API
we have to stop accesing properties and start using getters/setters
instead. Once we start doing that we should be able to provide a
clear interface for our templating system.
Bug: T246161
Change-Id: Ib3539b1e3bc12341c79913af3c95acad8619cff4
Moving all the templateParser calls to one function
so its easier to see how the template is composed.
The diff of changes to the stories folder highlight
the internal changes which are:
* html-portals replaced with html-sidebar in main template
* new Sidebar template added which outputs to html-sidebar
* Mention of "MainMenu" replaced with better understood "Sidebar"
This is precursory work to adopt templatePartials
Change-Id: I6b2196e39087f818e774d04b2d1b9ab8cb8816a1
The renderNavigation function provides an unnecessary level of
abstraction which I'd argue hurts readability of these functions.
Let's remove it.
Change-Id: Iad1c4db606404fecf4d5ae98981df9f05d3f661e
Use a template variable only for html attributes of the logo
Move static HTML into Navigation.mustache
Change-Id: If37015b9ce4f37e264b6f25956e4d0ca35e8cdff
Vector provides two vector specific hooks:
- VectorAfterToolbox
- VectorBeforeToolbox
Instead of supporting Vector specific stuff we should aim
for a nice global skin api and allow other 3rd party to
extend MediaWiki functionality no matter which skin is currently
on.
Bug: T240062
Change-Id: I245f1316e79f814ba04f4e0a0223d4f0596cf39e
This will allow us to render in Storybook without having issues
with unclosed tags. it also mirrors how html-headelement works
(obscuring the opening of the body and html tags)
Bug: T240062
Bug: T242674
Change-Id: I216a920c68bf3da9de55a75fc53451c68c9cc753
A Portal (or portlet) in the Vector context is a section of the
sidebar menu (e.g. Tools, Languges etc.).
The hook that places content between the portals (or portlets?)
such as `SkinTemplateToolboxEnd` and `otherlanguages` has been
enclosed inside of an output buffer so that any content it
produces can be passed to a template.
Bug: T239248, T240062
Change-Id: I882db161e5462cf88aa48c9cfd91448eb97a4a77
Extracts a new VectorMenu mustache component from VectorTemplate.
VectorMenu is the "more" menu that appears at small widths instead of the
Read/Edit/View History menu near the top of the Vector skin.
Bug: T239248, T240062
Change-Id: I41b1ec949d81303abddadb981741445572c939e3
PersonalMenu is the login/logout notifications etc. menu at the very
top of the Vector skin.
Bug: T239248, T240062
Change-Id: Iae224cbd838e44669a9f27e6dd303c6c3b402d41
For consistency with VectorTabs, rename SearchComponent to only imply
component. At least two word names seems like a good target (instead of
just "Search") for grepability and standard component style conventions.
Bug: T239248
Change-Id: I1e4f7270ba29c2f35f08e92f8a28cd8a2ec8fe87
The tab attributes were mistakenly being echoed instead of passed by
value. E.g., http://localhost:8181/wiki/A?uselang=he.
Bug: T239248
Change-Id: Ia0af96df717948743a2d66f8432b47e6f8a9c8f1
Creates a new VectorTabs.mustache component and uses it to render
the namespace & view tabs.
Bug: T239248
Change-Id: I859e4e95a2a12470f66564db547679c9f0a16727
Extract SearchComponent.mustache from VectorTemplate. The "search"
message is now escaped by the template parser. As is, htmlspecialchars()
for "wgScript".
A later patch will change each component renderer function as well as
renderNavigation() to return a string.
Change-Id: I3084b7e0ef73d320c85ee780c9eff13ecea92906
Move template logic outside of the template and into variables. This
will allow a future refactor to move the template to a separate
template-only file.
Change-Id: I91c2df11106cf09428a890a2d96ecbddb18ef0fe
Cut up renderNavigation() into several discrete methods. Smaller methods
are easier to read and reason about.
Change-Id: I4e55d858ab1745fb2baddef02f7046ec842eb149
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
DannyS712
jdlrobson
jenkins-bot
Nicholas Ray
AronDemian
Stephen Niedzielski
Volker E
Timo Tijhof
polishdeveloper
Jan Drewniak
libraryupgrader
Vedmaka
Simon Legner
Jdlrobson
Isarra
Fomafix
Max Semenik
