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
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
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
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
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
* `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
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
