Uses flexbox alignment to resolve an issue where the
clickable area of the notification and alert icons were
overlapping with the links next to them.
Bug: T264339
Change-Id: I2afc12504d7184583fa8331479125474c68017dc
Now the header is no longer absolutely positioned the height is not
fixed and the personal tools can safely spill onto a new line
Bug: T264206
Change-Id: Ib2a3cf1907c7d06c2c92ccbd902a98a3f8242f37
Follow up to 6d967ed4a8c
Add the missing ! to check that the portal is hidden rather
than visible to restore the correct logic.
Bug: T71729
Change-Id: I29f6f5e1e6adf3d6d9795cbdabcc152c5d5ac28f
On the long term we want to provide access to these variables in other
extensions. e.g. VisualEditor
Bug: T259331
Change-Id: Ibbc6f1905ea384a3d159088e3f5eca947eb6ec08
As part of comparing Vue search with legacy search, we need to track how
long it takes to lazy load the wvui library. A similar metric was added
to measuring the mediawiki.searchSuggest module in
I0fa6b8904bd43c87a68e9161f00d686a0e588966.
This commit adds the following metrics which will only be used in our
synthetic tests. We are not doing RUM tests at this time.
To test locally, add the following to your LocalSettings.php and append
the query param `useskinversion=2` e.g.
(http://localhost:8181/wiki/Test?useskinversion=2):
```
$wgVectorUseCoreSearch = false;
```
Marks:
* mwVectorVueSearchLoadStart: Marks the start of loading the search
module.
* mwVectorVueSearchLoadEnd: Marks the end of loading the search
module.
Measures:
* mwVectorVueSearchLoadStartToLoadEnd: Measures the time it takes to
load the search module.
Bug: T251544
Change-Id: I14e44b45a66213821d69cd22395fedbae747da88
Drop support for vectorMenu, vectorTabs and
vectorMenuCheckbox, body, menu selectors in preference
for standard selectors.
This change will impact a large amount of user scripts/styles but should
not impact any gadgets.
These classes were kept around for user scripts and styles however are not
needed internally. As we transition to a more maintainable skin menu
system, it is time to lose these selectors even though this will cause
disruption.
Vector now will use the mw-portlet class rather than the vector-menu
class in its own CSS styling, however it keeps the other classes to
allow differentiation of the different types of menu.
Changes to test: Previously the tests assumed all portlets were empty
when checking the classes. This is very rare, so its better to check
the classes of non-empty portlets, so several tests are updated
accordingly to drop the emptyPortlet class.
Bug: T262092
Change-Id: I1824335eb47d613c2a4804ec1f1106c0f4c16101
Kept as simple as possible for now. The new class is added but no classes
are removed. This will be done in a follow up.
Bug: T256897
Bug: T253938
Change-Id: Ib31a9d8f2ac14e63b63e82abd4a9aa1fcb956f45
* The margin-left should only be auto at small resolutions - otherwise on large
monitors it becomes visually separated from the logo
* the margin left should be larger
* and max width should be smaller.
Bug: T261686
Change-Id: Ia1331f51764a34f113e3336735e6cfd5fde1d49d
Minor visual fix for IE9 for modern mode with search not in header.
i.e. with these settings:
$wgVectorIsSearchInHeader = false;
$wgVectorDefaultSkinVersion = 2;
Slight refactor of CSS. Removes block of styles that "reset" floats.
These were uneccessary because as flex-children, the floats were
ignored on those elements anyway.
Moves flex-wrap on .mw-header from layout-search-header.less
to layout-default.less since that's where display:flex is defined
and the rule is general enough that it should apply for different layouts.
Remove the @supports block with the `float:none;`. That is unnecessary
because flex-children are not affected by floats.
Change-Id: Ida3d2a7bc2b2f70238129df876714228fe5cdf84
This moves the header, navigation, sidebar, and article toolbar to be
before the content in the DOM. As a result, a lot of absolute
positioning logic can be removed and styles can be simplified.
Note that although the sidebar was moved from the header into the
workspace container allowing it to de-absolutely positioned, its
absolute positioning was kept intact as it has a fair amount of
complexity that should be handled in a separate task.
To activate, set `$wgVectorIsSearchInHeader = true;`
Changes that could cause concern:
* The "jump to search" link was removed as the search is now much
earlier in the DOM and I questioned the value of keeping this. However,
it can be added back in if this change is contentious.
* A "jump to content" link was added to account for the new DOM order.
* Because the sidebar was taken out of the header, users will not be
able to tab from the sidebar button into the sidebar without additional
tweaking (e.g. should we add JS to enable this?). It was deemed that
this work can be saved as a follow-up task.
* I applied `overflow-y: auto` to the `mw-page-container` because the
header's top margin was collapsing and caused whitespace to appear
between the viewport and the header. Alternatively, we could apply a top
padding to the page container and remove the header's top margin. I went
for the simplest solution but am open to alternatives.
* I left the footer as-is in this patch to minimize risk. It might be
cleaner later on to move the footer inside the workspace container which
would leave only one workspace container.
Bug: T261802
Change-Id: Ic553fab3bde25769b103d899b92b3b694c00c384
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
The star should spin its current background image when transitioning between different
watch requests.
Bug: T259053
Depends-On: I1e11f0e129c53b405a2ffa8
Change-Id: Id2f9b2e25761c052aeaa410edead65ec298209a2
The width should apply at all resolutions. Note, because of the nature
of flex box and flex-grow the personal tools can grow larger than this
value.
This avoids Alex Hollender (WMF) and similarly long usernames from every
running to the next line before they are allowed to.
Bug: T249363
Change-Id: I4640947aaaf7ab764cb17b911af7085ac291b7d1
Carved out from I8e6e283db5d4034861f8d50d9b3f211df1a78c6c.
It makes sense to have a variable defined for that value.
Change-Id: Iaaca1fd7c15a0c121e60b5ae6debf4bf6920168e
I overlooked the horizontal padding on the page container. This needs to be
included in the decision on whether to make the header 2 lines on 1.
Bug: T249363
Change-Id: I4fabac7d57e37db87d2363073317109f582de883
Following up I6bc4cf541eefd00e2e42 we also need to remove the
linear-gradient hack that only made sense in combination with the
now gone PNG fallback background-image.
Change-Id: I0e7ed0451884a6bd612cb1082555338a26129e2d
These are no longer needed. The classes remain where necessary for
gadgets but the CSS rules no longer need to apply to them.
Change-Id: I18afa15ddab75128463dc83c916e11436db0575a
The calculations were a little incorrect as I failed to consider the
sidebar button correctly and how the search's min width and max width
impact layout.
I also move rules from Sidebar.less regarding the placement of the button
into layout where I believe they belong. We do not have a header component, so the
positioning (margin) of the sidebar button in current form should be here.
This can be revisited if we introduce a header component.
Bug: T249363
Change-Id: I4ff640380eafc8beedb2c3c8fb00a56c71c5cb45
The width comfortable should consider the max-width of the search
not the min-width.
This fixes the bug documented in T249363#6391041
Bug: T249363
Change-Id: I3e216a3705730092f88d1dcbb5193e411945a083
As part of moving search into header work, a min-width (via
@min-width-supported variable) was introduced on the body and takes
effect when the search feature is enabled.
However, given a min-width already exists on the page container from the
max-width work, I'm wondering if it makes sense to replace that one with
the @min-width-supported variable as it seems like we should only have
one min-width vs. having two.
Note: As a bonus, this has the (unintended but helpful) side-effect of
mitigating the sidebar button being blocked by the personal menu at
small viewport widths (T258465).
[1] I7f8059d43eaab49de362405784b34a4fe502c7b0
Bug: T258465
Change-Id: I920cd0e9d1564c82bcdc89b721352620158073c6
* Remove the PNG fallbacks for chevronHorizontal-….svg and menu.svg.
As of T248061, these are no longer needed.
* Added the one line of trivial CSS directly to skins.vector.styles
instead of through its own module.
This helps recovers the module cost of vue module deployed this
week (from Ib6c8f890fb3d6e7), which is currently empty and unused.
With T253582, we'll be able to recover a lot more budget in
this area.
Bug: T258766
Change-Id: I6bc4cf541eefd00e2e428f918664a26da331c1a9
To support roll out and avoid issues with cached HTML the new
styles for the new search feature are restricted to HTML where
the body tag has `skin-vector-search-header` class.
For legacy mode, we introduce a new class
`skin-vector-search-header-legacy` and temporarily use a CSS3 `:not()`
selector to ensure the styles ship during the phase where cached
HTML can be served. While this will create some display issues in
browsers that do not support CSS3 selectors, all grade A browsers in
our compatability matrix support this.
Bug: T249363
Change-Id: I7f8059d43eaab49de362405784b34a4fe502c7b0
