When browser preference for reduced motion is enabled:
* Disables bolding of table of contents
* Disables sticky header transition
Bug: T254399
Change-Id: I8ef9e59b258fed977ce370da352b1924832d842b
We have many styles related to the layout and visibility of search that
are only useful in the context of the main header. Since many of these
elements have classes that will also be in the sticky header, we should
scope these rules to the main header so that we avoid an uphill battle
of styles trying to override eachother.
Additional changes:
* We previously had a mix of #p-search and .vector-search-box selectors
for the same element in the CSS. Header.less now only uses
.vector-searchbox to avoid specificity wars.
* Removed nearly all of the #p-search rules previously found on L147 -
L167 in screen.less after observing nothing relatively bad happening
when they were removed.
Bug: T289724
Change-Id: I2e6c269e29717cd20d8acfaddc3631ea1b8fedfa
The sticky header is currently disabled unconditionally
and nothing is wired up, with placeholders for data and
functionality which will be added in future.
Bug: T289716
Change-Id: I16223ce849267e718aad22b8a24b2327332ac8b7
Update/remove config, constants, hooks, templates, styles, logic, tests, stories to check legacy vs modern Vector where applicable instead of the decommissioned user links feature flag.
Bug: T288852
Change-Id: I5c5831091a10711838a8a2877c782df4996d4596
Merge UserMenu into UserLinks for legacy and modern
Add a story for the UserLinks menu
Fixes: rendering of Skin (legacy) personal tools (the user icon
no longer overlaps)
Change-Id: I491ebb3962780bf2cf7f1dfb4dd09d576c294366
Have a single template for the UserLinks component, with a single
element wrapping all its subcomponents as discussed.
Change-Id: I35936a6fa1ba335639ca3f47fd439a3662268fca
Since we have feature flagged the new user menu feature, it is
imperative we load both sets of styles until the feature has
shipped. This allows us to switch seamlessly between the two
without worrying about cached HTML being served with updated CSS.
To do this, we add a new class to both user menu's distinguishing
the legacy version from the modern version. The styles are then
scoped to these new selectors.
This also fixes some regressions with the legacy user menu in
modern Vector when wgVectorConsolidateUserLinks is disabled.
Notes:
* No caching selector is needed for #pt-userpage given it can only
ever be output for logged in users.
* ID selectors in general are bad, so scoping to mw-portlet-personal-user-menu-legacy
isolates the legacy component allowing it to be rendered alongside the modern UserMenu
Bug: T276561
Change-Id: I068c5233bb25a7b141e66a6726b5761841f83eb2
Pull personal menu items except for user page link into a consolidated dropdown menu based on feature flag using Vector hooks. Add consolidate user links feature flag for logged in/out users. Update styles for personal toolbar. Add logic to template to show legacy toolbar or consolidated toolbar based on feature flag variables.
Bug: T276561
Depends-On: If4e143aada711d210ae45d33b97a6be0685b6a41
Change-Id: I1c305d89bece147a6f1b478441119c3169abfbdd
Separating most LESS files into 2 ResourceLoader modules and a common
folder:
- skins.vector.styles
- skins.vector.styles.legacy
- common
This changes aims to clearly separate the old (“legacy”), the new
(“modern”) and the common styles which were previously all placed under
`skins.vector.styles/`.
Inside each directory are separate folders for `layouts` and
`components`.
The entry files, `skin.less` and `skin-legacy.less` are moved into the
specific folders and a third, `common.less` entry file is created that
contains the common imports for both old and new Vector.
Aliases have been added to the Storybook Webpack config to avoid adding
the story file changes to this patch. Images coming from CSS `url()`'s
have also been temporarily disabled in Storybook until Storybook can be
upgraded to use Webpack 5, and use array values for aliases, in a
follow-up patch.
This patch also slightly changes a footer layout specific rule so that
existing `padding` remains unchanged in rendering due to new common and
component structure.
Bug: T264309
Change-Id: I1cd2681a2b61edb7be56c38f9bb3994827d7e322
The sidebar currently uses mw-ui-icon so we continue this
practice, however we provide a general rule to ensure all icons
rendered through it default to 20x20. This didn't impact the side
bar icon as that already specifies a height of 20px.
Bug: T268241
Change-Id: I6f8e8400da048a97cbf59c3e6ad918763fc91041
Creates a new skins.vector.search module that
replaces the searchSuggest module from MediaWiki core.
This module creates a new Vue app using the WVUI
search widget for the new search experience.
The legacy search input form is still retains on pageload,
and the new search kicks on search input focus.
In order to manage that transition, the legacy search
input is styled to resemble the new WVUI input, and the
new input is manually focused after the component mounts.
Vue is also added as a dev-dependency to help with
type-checking.
Other changes:
* the entry in skin.json is reordered alphabetically after
skins.vector.js
Bug: T264355
Change-Id: Ibb9561a77a14734297cb4d0ddcd415fc0750b45d
Provides a loading indicator to show while the new Vue.js based
search widget loads. Given that the new widget will pull down the
entire Vue.js runtime, it's likely that there will be a delay
before the search suggestions appear. This loader is meant to
improve the perceived loading experience of the new widget.
Adds:
- New searchLoader.js file containing loading behaviour.
- This overrides the code searchSuggest loading behaviour.
- New SearchBoxLoader.less file containing the loader styles.
- i18n message: 'vector-search-loader'.
- The Event type to jsdoc.json
Bug: T254695
Change-Id: I6b5f0a60018954e10b9e80792030b67b2ec33e5a
Keep variables concerned with layout in the master file but pull out
the default layout into a separate file.
Change-Id: I4acc2937f8e8a76274a3ffb76e3729dc89ce1ad7
Per discussions, its proposed that the target of all media queries
is defined in the entry points skin and skin-legacy
Please verify with `git diff HEAD^ -w` that no changes to print
styles have occurred
Bug: T253842
Change-Id: Id7d1c806d77ee50335a1c9985acc7e4406e64ccf
This patch closely follows the desired guidelines/desired
styles Alex Hollender has put forth in his prototype, but uses
multiple containers to achieve this look since our DOM order/structure
is different than the DOM structure in the prototype. The following
containers are used, but unlike his prototype, they are sometimes used
more than once:
* Page Container: Contains every other container and limits the overall
max-width of the white part of the page.
* Workspace Container: Contains the sidebar and content container. The
sidebar is displaced ~30 pixels to the start (left) of the workspace
container at all times.
* Content Container: Contains the content. The max-width of this changes
depending on whether you are on a special page/history page vs. other
pages.
* Article Toolbar Container: Contains the article toolbar. The max-width
of this is always the same as the max-width of the article content as we
don't want the toolbar to move when going from the article page to the
history/special page.
Changes to be aware:
* To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is
temporarily feature flagged and defaults to being "off".
* Note that layout-max-width.less is a temporary file made to meet the
feature flag requirement of T246420 (intended to derisk the deployment).
After the deploy, we should merge most if not all of the rules into
layout.less where the max-width design will become the default.
* Per Jon's code review comment, I have relaxed the indenting of
skin.mustache to make the diff easier to reason about. If desired, the
correct indenting can be achieved in a (much less risky) follow-up
commit.
Bug: T246420
Bug: T153043
Change-Id: Ie49f629bc705850c6996164a516957476c034048
This separation introduced in I8dbc29b7a19f7f doesn't work as well
as expected. All but strictly `.mw-jump-link` rule are typographic
rules.
In the current mish-mash of when to apply typographic styles only to
article content (`.mw-body`, `mw-body-content`, `.mw-parser-output`,
`#mw-data-after-content`?) inherited from core, it makes looking up
and finding issues between typographic styles harder, and leads to
unnecessary complexity instead of clean separation of concerns.
This question surfaced in where would link styles belong originated in
T213778.
Change-Id: I521185d505d8688f076dd09acbedb22e801f772e
Using 'skin' as entrance point files, similar to already existing
convention in MediaWiki land with 'skin.json' or 'SkinVector.php' as
example in Vector skin. Replacing Apache inspired 'index' convention.
Also renaming legacy to 'skin-legacy' to be clear on file base that it's
a modification of 'skin'.
Bug: T249073
Change-Id: Ief1c469724d4ffe238d307407c3ddb46f2e1abfa
2020-05-28 20:58:01 -07:00
Renamed from resources/skins.vector.styles/index.less (Browse further)
