Causes 20 visual progressions regardless of visual next flag, the ToC moves 1px when in the sidebar
Follow up to If3aed0ac401b0abc80c3ad52806eb85b33d43f06
Bug: T321504
Change-Id: I4b3ec90d8e79791a1bf17ba02c9f9d722499bec8
- Table of contents arrows are now aligned with sticky header search/hamburger
- The user menu dropdown now aligns with more and languages button
Bug: T321504
Change-Id: If3aed0ac401b0abc80c3ad52806eb85b33d43f06
Restricted to the feature flag (?vectorvisualenhancementnext=1)
for now to allow us to not worry about caching.
mw-ui-icon-flush-left and mw-ui-icon-flush-right have been in core
for some time and using them means we don't have to manage hardcoded
values for these.
We'll need to think of .mixin-vector-flush-left-left
and .mixin-vector-flush-right-margin-left separately - I wonder
if these could be revised to use these 2 standard classes.
Additional changes:
- Drop unused mixin-vector-flush-right-margin-left mixin
Bug: T321504
Bug: T317583
Change-Id: I51f8e31be6771a3fb32fb07dc22d0c2872b5706d
Rename template and CSS files to match updated naming conventions, replaces instances of "sidebar" with "main menu"
Bug: T316570
Bug: T317437
Change-Id: Ib4050768f20b1734d356104f18aa539f657099d8
Visual changes:
- Footer text and border is aligned with header icons
- Main page content has no padding, slightly wider on certain pages/viewports
Bug: T317573
Change-Id: Id0c4343b8bc4c16006c0b9abd914213ca2f307ca
This code is not resilient to changes in the mw-ui-icon definition
In preparation for changing touch areas we need an easy way to
flush these correctly based on feature flag.
No expected visual changes.
Bug: T314323
Change-Id: Ia10a7c696c690887a37851684215e515474fbd90
Technical changes:
- Increase @padding-horizontal-content to align content
- Rename @padding-horizontal-page-container and @padding-horizontal-page-container-wide to @padding-horizontal-page-container-desktop and @padding-horizontal-page-container-desktop-wide respectively
- Replace "gutter" grid area with column-gap
- Clean up TOC styles
Visual changes:
- Below 1000px the header icons spacing is updated
- Above 1000px the page titlebar and articlebar right space is updated
Bug: T315261
Change-Id: I7f51ab3b9613c359db62e918051e942c5c6c878b
- Removes grid row gap in favor of margins
- Add container div around site notice to allow margin collapsing
Bug: T315595
Change-Id: I39959f43f20880e83bef945a7535d58cfe0b6412
This reverts commit b63244f367.
Reason for revert: Per standup this morning we'll revert this so
that we are back to a known state, and try this again in a second
attempt.
Change-Id: Ie1349fecbab6c49ce63d328aba08162d74145cb9
IE9 is out of basic supported browsers, so removing this fallback.
Also using “Flexbox” as standard term in comment.
Bug: T306486
Bug: T308344
Change-Id: I6fcb0c4b54fea3d05593ae294c05e046131c93d2
[Visual changes]
This should result in 9 visual regression failures relating to
increased height of search results and loading bar
[More details about change]
- Migrate search app from Vue 2 to Vue 3; update tests
accordingly
- Remove dependence on WVUI and use Codex instead, via the special
`@wikimedia/codex-search` package
- Update search app to use CdxTypeaheadSearch, which no longer
takes in props related to the search client or fetch start/end
instrumentation. Instead, directly use the restSearchClient
and call fetch start/end events in the search app.
- Handle hideDirection in the search app/API response formatting
code, not within the TypeaheadSearch component
- Handle showing/hiding the search button in the app
- Move the WVUI URL generator into Vector
- Update server-rendered search box styles to match design updates
included with CdxTypeaheadSearch
- Replace references to WVUI with references to Codex
- Update values of various LESS variables to match Codex, and update
searchBox styling to prevent jankiness when the searchBox is replaced
with the Codex TypeaheadSearch component
The VectorWvuiSearchOptions config variable has been maintained and
will be updated to a code-agnostic name in a future patch.
Bug: T300573
Bug: T302137
Bug: T303558
Bug: T309722
Bug: T310525
Co-Authored-By: Anne Tomasevich <atomasevich@wikimedia.org>
Change-Id: I59fa3a006d988b14ebd8020cbd58e8d7bedbfe01
Restore header margin between search and user links, as its
still needed for grid (Fixes F35282398)
Bug: T303484
Change-Id: Ie8cf4adcadff430ebfc675029635e6c22061b238
Pixel shows 15 regressions, these are expected changes that are
fixing issues on specific viewports that fixes the following:
[At exactly the tablet breakpoint]
* the more menu dropdown was being
shown at the same time as the other menu items, resulting in duplicates
(see https://phabricator.wikimedia.org/F35285379)
[At exactly the desktop breakpoint]
* The table of contents AND the
table of contents toggle button to the left of the title were showing
(see https://phabricator.wikimedia.org/F35285392)
* The sticky header was not showing
* The fly out table of contents was showing instead of the sidebar
table of contents on scroll
* The top of the sidebar is brought into alignment with the tabs
(see https://phabricator.wikimedia.org/F35285408)
Bug: T310536
Change-Id: I6e870a032c8ba4ec003d00ff3f91732aaa2f38b0
This will also apply to the grid layout so this seems a more
appropriate place, given the class relates to search.
Bug: T303484
Change-Id: Ib5b57fd948ecb5eefbf1d66e0e71045aed6e3102
Having a clean slate to work from will help with the development of
introducing the grid
Bug: T303484
Change-Id: I8fb9a9d958e4e73e8bfbf4b797cee1353c915db5
Given that these styles deal with the layout of the sidebar button in
the main header and don't make sense in any other context (at least
currently), I think they belong in Header.less.
Change-Id: I191b9a404c82c5a1a80f97d98fa54535fdd53944
Before Vue/WVUI lazy loads, we have intermediate search components that
are rendered on the server and that need to be styled based on the
`autoExpandWidth` prop passed to the search component. This commit
refactors VueEnhancedSearchBox to use this class if present.
Additionaly:
* Cleanup fixmes from Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
* Replace `vector-search-box-show-thumbnail` class with
`.vector-search-box-auto-expand-width` class in Header.less now that
the class has been cached in the HTML.
Depends-On: Ic914ecaee591008f987bd6d754fda8628125de7b
Bug: T297531
Change-Id: Ia6b7afa990fa4b04578740b483ba21dbef45a016
In preparation for I30c670e3f195f77a27715c6b494a3088b7a55712, refactor
the search component expand behavior so that it can accomodate the new
changes in WVUI while maintaining backwards compatibility with the
status quo.
Additionally, pass/enable the `auto-expand-width` prop to the main
header's search. This will be inert until the new changes in WVUI have
landed.
Bug: T297531
Change-Id: Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
Styling should not depend on IDs to allow us to have multiple
searches in the page.
Precursor for wiring up search in the sticky header.
This also tweaks performance metrics to track separate metrics
for the sticky header search
Change-Id: I5b4192a8f5a9f95af26c1faf904f7cc994323518
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
