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
Amending Base10 to slightly darker `#202122` to fulfill WCAG
requirements in connection to Accent50.
Also sligthly adapting hover derivative to `#404244` and amending
corresponding opacity hover value.
Bug: T248393
Change-Id: Id72829d837d9e8d37bbec6092e5055f7c182db7a
This unblocks work on the header which will rewrite the layout
code.
This corresponds to a 0.06kb increase in CSS size, which is zero
after gzipping.
Bug: T249073
Change-Id: I23f18fc5f078da3331cad540bbaf533d348f2108
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
Move all Vector JavaScript to ResourceLoader `packageFiles`[0] which are
much more compatible with modern development practices:
- The entrypoint is the first `packageFiles` entry (unless specified
otherwise). All other JavaScript must be explicitly executed.
- Remove a level of indentation due to IIFEs from every JavaScript file.
Regretfully, ESLint does not support modules except in ES6+ so the
otherwise useful `no-implicit-globals` rule must be disable. The
change comes with a comment so we always remember.
- IDEs and other tooling understand Node.js-like `module.exports` /
`require()`.
This change seemed the most sensible way to start developing new
JavaScript in Vector needed by the collapsible sidebar.
[0]: https://www.mediawiki.org/wiki/ResourceLoader/Package_modules
Change-Id: I287e604d5b1055aa97b5f987c24872755757ea1a
The Mustache templates were a bit of a mix of tabs and spaces. I like
spaces personally but dislike inconsistency within the project more. Use
tabs.
Change-Id: I22b777489d7281b42d1ab1981b47b2a71d3b639a
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
Going into the header work, we'll need this variable available so
that we can align the header with the personal tools menu.
Per Volker's request we change the value to `px` from `em`s.
Previously it was 5.28333px. It will now be 6px.
Bug: T246170
Change-Id: Ic1514e8592db8ef168fc846b8f8e485fdd465e49
Instead, for the subset of Grade C browsers without SVG support (currently
IE8), we remove the icon and display the label text instead –
in a hacky, but acceptable way.
Bug: T248062
Change-Id: I87660b69fe65b9ec2989ea606e5f76d427c28fee
As described in the readme but not implemented until now, this patch
enables the skin version to be specified as a URL query parameter. This
is useful for testing both skin versions during development and on wiki,
as well as enabling sharing URLs with a specific skin (Vector) and skin
version (1 or 2).
Obtaining the actual skin version requires tying together three input
sources, WebRequest, User, and Config. It seems simple but it'd be easy
to botch. For this reason, a helper class to correctly interrogate them
and tests are provided.
Bug: T244481
Change-Id: I52d80942b4270c008d4e45050589ed9220255a50
Move all the LESS `z-index` settings to variables.less so it's easy to
conceptualize how UI will be layered. jQuery CSS rules are untouched but
documented.
Also, remove the seemingly redundant re-setting of the `mw-searchButton`
`z-index`:
#mw-searchButton
z-index: 1;
}
This rule was added in 0c77e4f.
The sidebar work will require `z-index` properties and this refactor
eases the comprehension of those changes, as well as prevents the
accrual of more `z-index` technical debt.
Bug: T246419
Change-Id: Ic112a0ee3f701f87432838797be45c6069fdb522
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 adds the same end margin as the portal container making the
opt-out-link more visually pleasing if it overflows its container.
Bug: T243281
Change-Id: I42eb3ec4a18ad9e4f6bcdb451593fec7e6e4992a
IE 9-11 cuts values 2 digits after the decimal point leading
to small miscalculations throughout the interface derived from `.mw-body-content`'s `em` value.
With `calc` it's forced to use same parent value for its
rendering calculations.
Bug: T102364
Change-Id: Id4ba39bc90174bab445ae0fb4d039c28a4f0b300
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
Address some feedback from I7a2cdc2dfdf20d78e4548f07cf53994563b234b3:
- Miscellaneous documentation improvements.
- Add a false case test to `DynamicConfigRequirement->isMet()`.
Bug: T244481
Change-Id: Ic5637f42da755f871c5a6d545e14effd3ac8c670
Various skins may extend SkinVector (although none are in production)
(https://github.com/search?q=%22extends+SkinVector%22&type=Code)
This makes it clear we no longer support that behaviour.
Because of the skins that are extending SkinVector currently we have
not resorted to using the final keyword at this time.
Depends-On: Ie3759c2acbf53c628577f6b05cfed17e0998a6bb
Bug: T248399
Change-Id: I2af8b2930c80f888791247bdaa2ae1c80576317e
