- Removed `#mw-head-base`.
- `#mw-page-base` -> `.mw-header-placeholder`.
- `#mw-head` moved down to `@height-header` to make space for new header.
- Content moved down to `@height-header + @height-tabs`.
Added Less variables:
- @height-header: 69px;
- @height-logo-icon: 50px;
- @height-header--inner: 54px;
- @height-tabs: 2.5em;
Style splits:
- Added Header.less
- @height-header: 2.5em;
Bug: T246170
Change-Id: I07280c4c7a2054439153e76359f712281049df0b
Amending Base10 to slightly darker `#202122` to fulfill WCAG
requirements in connection to Accent50.
Also sligthly adapting hover derivative to `#404244` and amending
corresponding opacity hover value.
Bug: T248393
Change-Id: Id72829d837d9e8d37bbec6092e5055f7c182db7a
Adding `margin-top` property only with sibling selector for now
until cache is cleared.
Also removing already inherited from
`.mw-body-content` properties `position`,
`font-size` and `line-height` of same value.
Bug: T248761
Change-Id: I1ea5e08927a96ac69c1b65f248ae0420968b4d00
Going into the header work, we'll need this variable available so
that we can align the header with the personal tools menu.
Per Volker's request we change the value to `px` from `em`s.
Previously it was 5.28333px. It will now be 6px.
Bug: T246170
Change-Id: Ic1514e8592db8ef168fc846b8f8e485fdd465e49
Move all the LESS `z-index` settings to variables.less so it's easy to
conceptualize how UI will be layered. jQuery CSS rules are untouched but
documented.
Also, remove the seemingly redundant re-setting of the `mw-searchButton`
`z-index`:
#mw-searchButton
z-index: 1;
}
This rule was added in 0c77e4f.
The sidebar work will require `z-index` properties and this refactor
eases the comprehension of those changes, as well as prevents the
accrual of more `z-index` technical debt.
Bug: T246419
Change-Id: Ic112a0ee3f701f87432838797be45c6069fdb522
This adds the same end margin as the portal container making the
opt-out-link more visually pleasing if it overflows its container.
Bug: T243281
Change-Id: I42eb3ec4a18ad9e4f6bcdb451593fec7e6e4992a
This commit is singularly focused on adding a link to the sidebar for
Vector, logged-in users. It does the bare minimum to fulfill the
requirements of T243281.
Additionally, it will help to answer the question "Do we need to use
abstractions (other than maybe different templates) to separate Legacy
Vector from Vector" by intentionally leaving out any abstractions in
order to make it easier to compare with a follow-up patch
(Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions.
It is a good thing to question whether or not we need addtional
abstractions in VectorTemplate and if they will help us as unnecessary
abstractions can have the opposite effect and just lead to further
frustrations down the road.
Therefore, I urge you, the reviewer, to let me know your thoughts! If
abstractions are viewed as not making our lives any easier, the
follow-up patches may be completely discarded and that's totally okay
with me. :) I think it's a good think to talk about now though.
Important changes:
* The VectorTemplate constructor was changed to allow injecting the
config, templateParser, and isLegacy boolean (only the config was
allowed before this commit). According to MediaWiki's Stable Interface
Policy, "Constructor signatures are generally considered unstable unless
explicitly declared stable for calling" [3]. Given that VecorTemplate's
constructor is not marked as stable, it is justified to do this without
warning according to the policy.
* Due to the above, the 'setTemplate' method is no longer needed and was
marked as deprecated.
* VectorTemplateTest was made to adapt to the new VectorTemplate
constructor. Additionally, it now extends from
MediaWikiIntegrationTestCase which my intelliphense server can pick up.
I *think* MediaWikiTestCase is just an alias to
MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed
to MediaWikiIntegrationTestCase in [2], but I'm willing to change it
back if there is pushback to this.
Open questions:
* What are VectorTemplate's responsibilities? To me, it acts right now
as a controller (because it echos the full HTML string from the
template), a model (because SkinTemplate::prepareQuickTemplate sets data
on it which it later retrieves through `$this->get()`), a presenter
(because it adds data tailored for a web-centric view), and a view
(because it renders HTML strings instead of letting the view/template be
solely responsible for that). Arguably, some business logic might be
mixed in there as well (because it checks to see if a User is logged
in/has necessary permissions to show x which my changes here add to).
This might not be a problem if we keep VectorTemplate relatively small,
but will it remain this way as we progress further in Desktop
Improvements?
* How do we write tests for VectorTemplate without exposing unnecessary
public methods? For example, if I want to test the `getSkinData()`
method to see what state will be sent to the template, how should I do
this? One option might be to use `TestingAccessWrapper` to expose these
private methods which is what
`VectorTemplateTest::testbuildViewsProps()` does. Another option is to
accept this method as public. Is there a better way? Keep in mind that
even with access to this method, there might be many things to mock.
[1] 0030cb525b/tests/common/TestsAutoLoader.php (L64)
[2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
[3] https://www.mediawiki.org/wiki/Stable_interface_policy
Bug: T243281
Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
Some LESS parsers will get confused with the lack of file extension.
It's better to be explicit and in alignment with recent change in core
I379334d7729e587a2a00.
It was already weirdly mixed in this repo with some imports featuring
extension and some not.
Change-Id: If5065cf9e30289de9b4fd33315bd65b75959ecb7
Replace raster image gradients (before base64 embedded) for modern
browsers by CSS gradients. Only relying on conventional image URLs
in browsers that don't support linear-gradient.
Also
- adding a darkened border for inactive tabs to harmonize visual
perception of border as one continuous line and
- DRYing tab separator selectors, saving ~8 bytes gzipped.
Bug: T63099
Bug: T121730
Change-Id: I76d32b84ddff06a2c7ef983e6f89ca6e74257a67
Also going with `--modifier` naming scheme when direct pseudo-class
modifying variable. And fixing small typo.
Change-Id: Ife2f9dc9cb57c063a43e4b3dfad3c737aaf3b72b
Navigation is the appropriate, general term – settling on it and
unifying file name and common abbreviation 'nav' for variable names.
Change-Id: I237b56320544de15e3b97c4806f6e2387bc54ca0
Unifying variable naming to property-identifier-modifier scheme and
use already existing variables out of mediawiki.ui variables file,
which gets imported by Vector and its variables (like
`@border-width-base`) are already in use in a few places.
Change-Id: Ic25b1517bf180a9bce437215c1309bb9f4dd15be
Unifying variable naming to property-identifier-modifier scheme.
Also removing `@padding` variable with only one single usage, instead of
extracting it from its place of application enable simpler readability.
Change-Id: I602fe645b233000bcecaeee6cf19d20e49a64c78
Unifying variable naming to property-identifier-modifier scheme.
Settling on non-em-based `line-height` values with one exception
of Vector tabs, where removing `em` would lead to different
calculation.
Also removing unneeded `inherit` assignment on content paragraphs
that has been part since Ic5ba836364.
Bug: T4013
Change-Id: I514467e4065d27de8d0ea82cdd3d23ccef6cffe3
Print-only variables should belong only to print stylesheet.
Also clarifying usage and naming throughout file.
Change-Id: I40dec1baadcf3dbbcf44252a8f577f19017fcbbc
Unifying variable naming to property-identifier-modifier scheme, while
also collecting all non-print values variables in corresponding file.
We will amend the `em` based values to calculations that will enable
rendered full pixel values and also fix some connected
usability issues in the future.
Change-Id: I378e8a2af91fe0790708e6fb2d2e7a5718ce93c5
Reyling only on base font family variables. It's debatable if
something like `@font-family-base` would make sense, but with only
3 variables the abstraction would seem over-engineered for the time being.
Change-Id: I294ef8753dd3c73f4ed3fd89d43978dfaf6e0f06
Merging similar value applications in generalized variables,
and aligning to property-identifier-modifier scheme.
Change-Id: I274ef24140a36e285c67b33a41ab6afe7c98676b
Increasing the distance of the button slightly changes the position
from end, putting the icon in a more appropriate place (harmonized
whitespace of input value and icon).
Also simplifying `font-size` calculations readability and equalling
their values in search input and button.
Bug: T225331
Change-Id: I57f7efc61f3b770d7470d820402e2ea533364238
Put icons on baseline as good as possible cross-browser. It's
complete waste of time trying. And is partly originated
in different internal text node sizing in various browsers,
biggest browser share difference is Chrome/Yandex/Safari 5 on Windows
against all others. Partly it's a result of us relying on `sans-serif`
generic font family instead of `Arial` – it results in different letter
baseline position within font's virtual letter box, which eats my limited
time on Planet Earth uselessly away.
Also adding and renaming LESS variable for proper code style.
Bug: T207075
Change-Id: I92acb9851a3c0acdbc40a4a4528a91c7332c9293
Updating user avatar icon to overhauled standard WikimediaUI icon.
Also:
- change `line-height` of personal menu to `14px` for better positioning
and introducing corresponding LESS variables
- slightly increase user avatar icon to be on par with ULS one
- putting avatar icon within link on active user, an awful user experience
that has long bugged me.
Bug: T123810
Change-Id: Iabde041090a87968b5f82e36fd81419083f80984
Replacing `#4d4d4d` with `#444`, which is `color-base` var modifier.
We're going for a very similar
color for now, instead of `#54595d` as with current background
we want to still ensure WCAG 2.0 level AAA conformance as it's
right now in order to not be disruptive.
Bug: T153043
Change-Id: I4c8caac9d829d8a3a351fc78181279ed35ed15a9
Tones down license information
and makes last updated primary information in
printed view
Additional changes:
* variables now inherits from mediawiki.ui
Bug: T169823
Change-Id: Ie678967a27baec8715cf86b6a0f7e7651f867be1
Additional changes:
* Define variables for fonts and use them
* Group and make clearer where fonts apply
Bug: T169823
Change-Id: I0b7d557048859936f2eb2f646202bc8071bb84ba
This was inherited from Monobook (r2881, b52a2a1567).
The #mw-panel (sidebar) was at `top: 160px`.
The #p-logo was at `top: -160px`.
This looks hacky so I set #mw-panel `top: 0`.
Bug: T170053
Change-Id: Ifb99ff36e3a9c530c944df2ea0a6c75759045c1c
Aligning some text and border colors (all greyscale) to WikimediaUI color
palette and also add toolbar `box-shadow` to “More” menu dropdown
following standard pattern.
Bug: T153043
Change-Id: Ic3247ce29059ea7d7f59a99ca742334600d85ce6
Introducing variable `@content-heading-font-family-generic`, that may be
used to specify an alternate font for `h1` and `h2` for languages which
render poorly using the standard heading font stack.
Set it for now on JA, HE and KO languages, based on reported issues.
Bug: T73240
Change-Id: I5217a7947427055f4cb61185d9d7d79848605dd3
