Commit Graph

4 Commits

Author SHA1 Message Date
Nicholas Ray 092a2957af Implement Page, Workspace, Content, and Article Toolbar Containers
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
2020-07-07 18:34:38 -06:00
Volker E d2a0ae588a [less] Merge 'content.less' and 'typography.less'
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
2020-06-25 18:45:19 +00:00
Volker E 35b2f65914 [less] Extract cross-browser normalization rules into new 'normalize.less'
Change-Id: I23da024b47020212173380315acd37210b924327
2020-06-12 20:33:46 +00:00
Volker E 4200a8665c Naming convention using 'skin' as entrance point
Using 'skin' as entrance point files, similar to already existing
convention in MediaWiki land with 'skin.json' or 'SkinVector.php' as
example in Vector skin. Replacing Apache inspired 'index' convention.
Also renaming legacy to 'skin-legacy' to be clear on file base that it's
a modification of 'skin'.

Bug: T249073
Change-Id: Ief1c469724d4ffe238d307407c3ddb46f2e1abfa
2020-05-28 20:58:01 -07:00