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
$.collapsibleTabs.getSettings can return undefined so the code
should take this into account
Bug: T177108
Change-Id: I2630a2ba2884542869748047ab84752543072647
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
- Creates a new user-preference called 'VectorSidebarVisible'
which stores the sidebar hidden/collapsed state for logged-in
users.
- Updates that user-preference on the client whenever the sidebar
is expanded or collapsed.
- Refactors the sidebar related javascript into a separate file.
Bug: T255727
Change-Id: Ib1ce934f3646cd8feebf0d3b15c38b5b969ec957
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 explains a few issues that were occuring in the storybook
relating to modern/legacy.
Follow up to 5195f5fd6 which doesn't reference why.
Components should not import styles relating to one of the Vector
versions. They should all be self contained.
Change-Id: I6f9ef974be97f8be593cd2b79ce37c3e517d549f
Removing presentational `<div class="visualClear"></div>` in process.
Only leaving in for legacy/layout.less and adding comment for future
evaluation if clearfix is continuously needed. In modern we've
got all parts of Vector in our awareness without featuring `float`s.
Bug: T254195
Depends-On: Iddf8f1dffc2d30299b89b3f4966b7fe8ee63090b
Change-Id: I673c28c2d7da4f96c31121d9aec6558e390de24e
Currently, the `aria-expanded` attribute is placed on the checkbox
element. However, since Ife287fc8c6e0d2aee5facf42d5d4308dea918ee3, the
checkbox is excluded from the accessibility tree, and this attribute
should be placed on the label button instead.
This commit prepares for future changes [1] to the checkbox hack interface
in a backwards compatible way:
* Passes button to `updateAriaExpanded` function
* Passes button to `bindUpdateAriaExpandedOnInput` function
[1] Ia2755e189babbd70945b66a1a812fc3ece40b577
Change-Id: Icc6ba994d57ea1f8050aa408aebc8c81f03d8783
* Moves the sidebar into the header so that user can tab directly from
the sidebar button into the sidebar (when open).
* Because the sidebar is absolutely positioned inside the header and the
header applies a top-margin, we need to adjust the top position
calculation for the sidebar.
* Removes the checkbox from the accessibility tree through CSS `display:
none;` instead of HTML attributes.
* Given that the checkbox is not able to receive focus, the
`#mw-sidebar-checkbox:focus ~ .mw-header .mw-checkbox-hack-button` CSS
rule is obsolete and moved instead to the label button. An additional
outline: 0 rule was added to remove the dotted outline that Firefox
applies.
* Makes the "Skip to navigation" jump link point to the sidebar now.
After the sidebar has been tabbed through, the rest of the navigation
can be tabbed to.
Bug: T246420
Change-Id: I981da3650854568bb9cfbf3c6c59e7625e7d094c
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
Fixup for I8669d402b6b757cd5bf59a5e0df377b6023b0700:
Applied `.vector-tabs` selector instead of `.vector-menu-tabs`
Class `vector-menu-tabs` is added by VectorTemplate.php#383
Bug: T255574
Change-Id: Iae8176221662aa47dcd69123e9dd6a9d6693cd42
Both properties are needed for normalizing different browsers (`padding`
infamous on older Operas) and are only needed on `body`.
Change-Id: I661869ed43491824cbfe86dc36e39f97e29ccf8a
Replace former non-base variables color with one from the standard
variables files in preparation for iit's usage in core and Vector.
Color is still confirming to WCAG level AA contrast ratio.
Bug: T254474
Change-Id: I06d981f05554b6429d11f19b8f5848ba5a7441a0
Normalizing focus styles in Blink based browsers and aligning to
Design Style Guide components.
Bug: T245887
Change-Id: I4d571dcbbada5edffbfee631c8b438cf7c8d273a
Following-up I00b4d2fd795195cd9c8add650a3b3cafdced5465
it's now time to settle on `.vector-menu*` classes.
Change-Id: I8669d402b6b757cd5bf59a5e0df377b6023b0700
There's a longstanding Chrome bug that causes CSS transitions to show in
their terminal states. This patch works around the issue by limiting
transitions to JavaScript users only via the `client-js` class which is
added to the root `html` Node some time after page content loads. The
effect is a better overall experience for everyone but transitions
unfortunately no longer appear for no-JS devices.
I am unable to reproduce this issue in Vector's configuration. This
patch should only be merged as a last resort.
Bug: T246419
Bug: T234570
Change-Id: Ifcb2bf1fddb85113a4858b7a210ded3954952e6e
By using `rgba()` instead of `transparent` the color gradient
calculation works as expected in Safari as it does in all
other browsers.
Also using same distance 33%/66% for gradient start and end.
Bug: T254489
Change-Id: I64ec6aa51a9ea931a2351c9c7a9ffaf28c8d130b
Fix the icon button directionality in right-to-left languages.
Previously, the button was hardcoded to support left-to-right only.
- Replace the skin.vector.icons' `.mw-ui-icon-wikimedia-{name}:before`
`selector` in skin.json with a placeholder, `{name}`. I don't think
this selector should be needed but it seems to be erroneous not have
one. I believe this issue of wanting a null selector was encountered
in Minerva or MobileFrontend but am unable to locate the past
discourse.
- Add check and unchecked menu button selectors to skin.json that set
the appropriate background image. This shards some of the styles out
of Less and into ResourceLoader-land but it's worthwhile.
- Revise the name of horizontal collapse icon to describe its form not
function, "collapseHorizontal" to "chevronHorizontal". This has been
an established convention that was missed a couple patches back.
- Add a flipped chevronHorizontal for RTL. I used Inkscape to do the
flip and tried to match the style of the original by hand. Feel free
to edit further.
- Drop the now unnecessary icon flipping JavaScript and initial Mustache
class. This enables a real CSS-only solution for the icons.
Bug: T246419
Change-Id: I60f65b3c595bf18d309b667d9a0b066691b90c97
It's advisable to rely on default icon color and set it's color
by opacity. With that we've got a better playing field to respond
to user interaction with icon color changes, not relying on
several icons at once for different states and also being
backwards-compatible for a variety of browsers.
Change-Id: Iaff869774007ed962104d704103f0392a3516f4f
Bug: T246419
