Instead of aligning the dropdown list to the starting edge of the
"more" button, this aligns the dropdown list to the end of the
"more" button, preventing any potential horizontal scrolling.
The containing list box is right-aligned, but this does not affect
the text alignment.
Bug: T267325
Change-Id: I8b889f8314519b8c6a74c661aca773b9b546657b
This allows better compatibility with FeatureManager (e.g. can use
requirements such as REQUIREMENT_LATEST_SKIN_VERSION). It will become
especially useful in I70277c1082a504fbd5f6023e9873e8071de7e35d and when
A/B testing search.
Bug: T270202
Change-Id: I3a063e0b085765ea1db3c4478fb30c11b0942b75
A new config flag wgVectorLanguageInHeader is added to allow
us to render languages in sidebar or outside sidebar, in the
header.
it defaults to false to allow for further development and to
not disrupt the status quo.
To accomodate the new menu, a new header is added based on the design
in Minerva to contain the heading and language button. The language
button is floated to the right.
The new menu is not styled. That exercise is left for the follow up
task T268241
No caching implications of this change, as legacy and modern
experiences remain touched without changing the default value of the
new config flag
Bug: T260738
Change-Id: I5af1522cac3831c1c833388461fe254c03191f65
`.mw-page-container` currently has an intentional non-zero vertical
padding that was being overriden by tablet media query styles. Instead,
only override horizontal padding on tablet.
[1] d525e564db/resources/skins.vector.styles/layout-default.less (L169)
Bug: T271868
Bug: T270146
Change-Id: I736805c9febeb333ea682ba0c70b2ff4768ae397
Overriding weird UA styles to ensure maximum click interaction area on
search button in no-JS and JS environment.
Bug: T272089
Change-Id: I8600402e022c041da29b31bf828198843c2ad7c6
Follow up from Ibab9992a6aa3a60f83324b40017b53fb061991d7 (please refer
to that commit message), but using `pointer-events: none` to remove all
submit button behavior (submit behavior, cursor change, and tooltip).
Bug: T270202
Change-Id: I2bd8e88f1f497cc3b2d88c7fdad33c812d13a40a
T270202 shows the correct dimensions of the search component having a
max-width of 500px and min-width of 350px but since we set the font size
of `#p-search` to `@font-size-base` [1], I suspect the search related
variables need to account for this factor as well.
This increases the max-width of search to 500px per the spec.
[1] 30eb683a70/resources/skins.vector.styles/VueEnhancedSearchBox.less (L23)
Bug: T270202
Change-Id: I13ad550734e8a5347ed70e4b3c33102b4a13bde7
Before WVUI loads, we show a magnifying glass at the start of the input
that visually mimics the magnifying glass start icon in WVUI's typeahead
search component. Unfortunately, this element is a submit button in
Vector instead of the inert span element used in WVUI.
Although the submit button is useful for no-js users, it might be
confusing for js users. Ideally, an inert element like a span would be
used instead, but that deserves its own ticket. As a temporary easy
stopgap, changing the cursor to be an arrow instead of the pointer might
make this less confusing and discourage clicks to it.
Bug: T270202
Change-Id: Ibab9992a6aa3a60f83324b40017b53fb061991d7
* Lower the min-width from Vector to 500px
At lower resolution per mock:
* Tabs converge into single grouping
* Search input is 150px
* Sidebar rushes content below
Drop rule for mw-content-container for special pages and history as it is already
accounted for in .mw-checkbox-hack-checkbox:checked ~ .mw-workspace-container .mw-content-container
rule.
Bug: T264218
Change-Id: I14ee75bd173fb2de1e33067f95ce09deba5bf27a
These buttons are already absolutely positioned with their `top` and
`bottom` styles set. More importantly, the min-height style is causing
the buttons to not be vertically centered in Safari.
Bug: T270202
Change-Id: I21b88af4313249d8b2b775c32d12aa1f65c2d0c2
* In Iecc3eebf0dce495400ba3d644dce39186f4fa395, a border was applied to
`.wvui-typeahead-search` to make it appear like the input box contains
the search submit button. Because of this change, we can't apply a
max-width to #searchForm when WVUI loads as it will cause the border to
extend farther than it should. Instead, we apply the max-width/other
styles to `.wvui-typeahead-search` (WVUI search's root container) and
`#p-search`'s direct child after WVUI loads.
* In I0ec3dcedaea90b01fe94e3416ee68ea33b782b4b, the start icon was moved
1 pixel to account for the input's border. These changes sync with the
changes to WVUI.
Depends-On: I0ec3dcedaea90b01fe94e3416ee68ea33b782b4b
Bug: T270202
Change-Id: I0ffd0a9225a5a9b935e09748d78ac45b17623790
SkinMustache in core provides most of what is required for Vector to
generate its menus. In the interest of having a canonical source of
truth for menus across all skins, Vector should use this data.
To ensure the HTML generated is (mostly) the same after this patch to
prior, a few modifications are necessary:
* The data from core is decorated so that Vector can continue having its
own custom class names on menus. This is done using the
decoratePortletClass method.
* There is no support for a menu having a header representing the
selected menu item, as is currently the case with variants. This is
achieved via an extension to getPortletData. It's assumed that later
when variants are merged with languages, this can be removed.
* Menus are agnostic to how they are displayed, so we must continue to
add the is-dropdown template variable to drop down menus. In future we
may want to rethink our Menu partial to make this unnecessary in PHP.
* The portal-first class is redundant in the modern Vector as we can
use the first-child selector. Previously we introduced a class to
service the legacy skin where this rule doesn't apply as #p-logo is
the first child. However, the legacy skin can do this using a special
next sibling selector instead.
Bug: T268157
Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
`#mw-searchButton` is apparently used with no-js clients or if the
js-search is broken [1]. Its position and dimensions should be kept in
sync with #searchButton.
This commit:
* Ensures that the same styles, including position, applied to #searchButton
are applied to "#mw-searchButton" so the dimensions are identical. This
should also address a critique in T270202 by removing the "invisible
button".
* Applies a `client-js` selector to ensure these buttons are
only positioned to the left of the search input if js is enabled. If js
is not enabled, having these positioned to the left is confusing as the
input has no obvious "submit" button.
* Syncs the input's end padding to match WVUI's input's end padding if
JS is enabled.
[1] 465e9492bb/includes/templates/SearchBox.mustache (L12-L21)
Bug: T270202
Change-Id: Ie1bb8c68b713b3a18f90ee11b44c78b436a6d0ba
Per T270202, there should be no underline on hover. The underline is
coming from a style in core.
There should also be no bottom margin on the suggestion li elements. The
bottom margin is also coming from a style in core.
Bug: T270202
Change-Id: I215a41aa328366aee2bb552d5d49c95905fd37f2
Following Design Style Guide components sizing and Alex' feedback
on task. Changing applied styles scope to non Vue.js enhanced,
modern-only style of search component as well, in order to have
clean appearance and transforming disruption free.
Also changing em static values to LESS calculations for more developer
friendliness and change background-size to be `em` as well for
user-set typographic zoom preference ability.
Bug: T269959
Change-Id: I157712721621344171a32a8887a5e20cc16cae0d
`@margin-horizontal-search` is used for margin of search component
and for personal tools, but they are also floated right so one only
gets a clearer picture of this change when the canvas is exactly at
one specific size.
Additionally it's used for a media query, so the min-width is slightly
reduced (by 32px equivalent) as well. That's advantageous too.
At some point we're going to change this to `rem` unit, that's why I've
taken distance from changing it to a `px` value for now although devised
differently before.
Bug: T269959
Change-Id: I21cac3f049eed64520dd229ef80d10f9be853e0e
Modifies and annotates the CSS required to make the server-rendered
version of the new search form look like the WVUI version of the
search form.
Bug: T264355
Change-Id: I989860cfbb755ecbb706b79bd807e9d0013bc4e5
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
Updating 'search' icon to latest WVUI/OOUI optimized, reduced path. Also
- amending size of search input and position of icon in input slightly to
align it closer to standard text inputs
- simplify CSS by getting rid of selector which is targeting both, input and
button and applying rules only where needed
- fixing code comments
- increasing icon size to `16px` equivalent `em` to enable user text zooming
preference applied to search icon as well. `16px` is a compromise towards the
old look and feel of the previous icon bringing it closer to standard icon size in
legacy Vector.
This change affects both modern and legacy versions of Vector.
Bug: T266166
Change-Id: Ib4c0c74d3cac30e1893f4c76e56e1197652d41ba
Replaces vector search icon with an update version that is
copied from the OOUI icon set and used in WVUI search.
This update will help us unify the visual appearance of the
existing search input with the one in WVUI.
Bug: T264355
Change-Id: I34792ee80e711b10b441668cc4ae18cc0cc9daa6
There are popovers such as the discussion tools "Add a link" popover
that need to stack on top of the footer. This replaces the
mw-footer-container's `relative` positioning with `static` positioning
which is one possible solution to this problem.
Alternatively, the popover could be appended to the end of the body
after the footer and positioned absolutely.
Bug: T264679
Change-Id: I34168c181a1e05c33cd42f664fcccb25abd4519b
An only-child will match first- and last-child selectors
so this additional selector is not required.
Change-Id: I17d468ba2bda37edc4e54f42f42d50e4b8831b46
Following-up Iecb0d6c4c80cee1d1684597a6dedf7323e2ec54d.
It isn't set anywhere inherited, hence we don't need to set it here.
Change-Id: Ife24aa95e6d1830b8d50001976277dbb2535c47f
Dropped all usages of the no longer applicable `skin-vector-search-header-legacy`
class.
Bug: T258116
Change-Id: I16a5cf8dda2ab84ff4b505d5a368587190c409cd
Unifying blockquote spacing and border style with Design Style Guide.
Also ensuring that blockquote children don't apply inherited whitespace.
Bug: T265947
Change-Id: I43a6951c17376fe3fdd4d24966ec4661c18ffd87
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
On the long term we want to provide access to these variables in other
extensions. e.g. VisualEditor
Bug: T259331
Change-Id: Ibbc6f1905ea384a3d159088e3f5eca947eb6ec08
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
Keep variables concerned with layout in the master file but pull out
the default layout into a separate file.
Change-Id: I4acc2937f8e8a76274a3ffb76e3729dc89ce1ad7
`padding: 0` was either a rule targeting very early Operas or
Netscape/Firefox or came out of Eric Meyer's reset.css as
misappropriation.
normalize.css haven't had it in v1.0.0, only relied on `margin: 0`
normalization for IE 6 & 7.
Change-Id: I3d2894a1e68414b64751bd6ebe7e1af77d260ee7
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
All those have been lingering while not being used for a while.
- arrow* files are part of core 'mediawiki.icon' module
- 'link-icon.png' is without any reference nor clear original usage
- 'magnify-clip.png' is part of core 'mediawiki.skinning' module
- 'search-fade.png' was used in #simpleSearch before it got unified with
Design Style Guide components
Change-Id: I985d3ec25b26eea359ce3dbf5abbe4647bc37ab4
Use normal `background-image` properties with SVGs only now
that IE 8 and Android 2.1 is removed from Grade C.
Also removing all PNG fallback images.
Bug: T248062
Change-Id: Ib91cd0514d331ab6a0f8b668aef6991cf3267fe2
In future we will be displaying the header and logo in the print
display - to avoid adding unnecessary borders scope this rule.
Bug: T253842
Change-Id: I123b73fcaa09c0213914ca6fd8074a1305814529
This will help mitigate the sidebar overflowing the page container
(related to T257518). Note that this does not prevent the overflow from
happening as the sidebar can still be longer than the viewport, but it
should reduce the number of times it can happen.
Bug: T257518
Change-Id: Id7138b4d4459242772bee8e11dc7edeaf76b3ca0
Follow up to I340b9e7e91960713c0ebb4d3d26e2ae2d5628f37
The layout styles reference internal CSS classes within
Vector components that may change at any time.
For legacy layout, I leave the styles the same (they have a FIXME)
As Aron noted on code review the impact such a change
could have on user styles. For modern however I simplify the styles
as follows:
* The top margin on the form is promoted to the main element - this has
the same end result.
* Likewise the width dimensions are moved from child elements to
the parent
Bug: T249363
Change-Id: If923a5dddaac6217462e75d476e07d923ee1743f
No changes made to the CSS rules.
* 'SearchBox.less' is the common part that won't change in modern.
* layout styles copied to both 'layout.less'
Bug: T249363
Change-Id: I340b9e7e91960713c0ebb4d3d26e2ae2d5628f37
* `mw-content-container` now wraps the footer (as well as the content)
because we want the footer to match the content width at all times and
to expand with the content when the sidebar is closed (at small viewport
widths or when on history/special pages)
* `mw-footer-container` margins were replaced with padding to avoid
issues with margin collapsing.
* Applied a white background to sidebar to handle the case of the
sidebar overflowing the `mw-page-container`. When that happens, we at
least want the text in the sidebar to be legible.
* Closely related, `mw-page-container`'s `overflow: hidden` style was
removed to prevent `mw-page-container` from cutting off the sidebar. The
purpose of this style was make it appear as if the sidebar was being
hidden by `mw-page-container`, but tweaking the sidebar's translation
animation to achieves this effect as well.
Bug: T257518
Change-Id: I89edf89b2ac4abe2053f0c9b366f143133ff420f
