HTML formatting of the queue was distributed over several OutputPage methods.
Each method demanding a snippet of HTML by calling makeResourceLoaderLink()
with a limited amount of information. As such, makeResourceLoaderLink() was
unable to provide the client with the proper state information.
Centralising it also allows it to better reduce duplication in HTML output
and maintain a more accurate state.
Problems fixed by centralising:
1. The 'user' module is special (due to per-user 'version' and 'user' params).
It is manually requested via script-src. To avoid a separate (and wrong)
request from something that requires it, we set state=loading directly.
However, because the module is in the bottom, the old HTML formatter could
only put state=loading in the bottom also. This sometimes caused a wrong
request to be fired for modules=user if something in the top queue
triggered a requirement for it.
2. Since a464d1d4 (T87871) we track states of page-style modules, with purpose
of allowing dependencies on style modules without risking duplicate loading
on pages where the styles are loaded already. This didn't work, because the
state information about page-style modules is output near the stylesheet,
which is after the script tag with mw.loader.load(). That runs first, and
mw.loader would still make a duplicate request before it learns the state.
Changes:
* Document reasons for style/script tag order in getHeadHtml (per 09537e83).
* Pass $type from getModuleStyles() to getAllowedModules(). This wasn't needed
before since a duplicate check in makeResourceLoaderLink() verified the
origin a second time.
* Declare explicit position 'top' on 'user.options' and 'user.tokens' module.
Previously, OutputPage hardcoded them in the top. The new formatter doesn't.
* Remove getHeadScripts().
* Remove getInlineHeadScripts().
* Remove getExternalHeadScripts().
* Remove buildCssLinks().
* Remove getScriptsForBottomQueue().
* Change where Skin::setupSkinUserCss() is called. This methods lets the skin
add modules to the queue. Previously it was called from buildCssLinks(),
via headElement(), via prepareQuickTemplate(), via OutputPage::output().
It's now in OutputPage::output() directly (slightly earlier). This is needed
because prepareQuickTemplate() calls bottomScripts() before headElement().
And bottomScript() would lazy-initialise the queue and lock it before
setupSkinUserCss() is called from headElement().
This makes execution order more predictable instead of being dependent on
the arbitrary order of data extraction in prepareQuickTemplate (which varies
from one skin to another).
* Compute isUserModulePreview() and isKnownEmpty() for the 'user' module early
on so. This avoids wrongful loading and fixes problem 1.
Effective changes in output:
* mw.loader.state() is now before mw.loader.load(). This fixes problem 2.
* mw.loader.state() now sets 'user.options' and 'user.tokens' to "loading".
* mw.loader.state() now sets 'user' (as "loading" or "ready"). Fixes problem 1.
* The <script async src> tag for 'startup' changed position (slightly).
Previously it was after all inline scripts and stylesheets. It's still after
all inline scripts and after most stylesheets, but before any user styles.
Since the queue is now formatted outside OutputPage, it can't inject the
meta-ResourceLoaderDynamicStyles tag and user-stylesheet hack in the middle
of existing output. This shouldn't have any noticable impact.
Bug: T87871
Change-Id: I605b8cd1e1fc009b4662a0edbc54d09dd65ee1df
core/docs/kss/styleguide-template/index.html uses {{whenDepth}} and
other functions deprecated in kss 2.0, so set an upper version bound in
package.json
Bug: T91725
Change-Id: I55669f3cc1c34911f717fe5fce3ea6ed00510177
- Updated the list to actually be in alphabetical order
- It wasn't working on MacOS, removed the '<' and it works now
This is a follow up patch to I3d66bcacf99da7eecc91a421c521dc650ed9cf82
Change-Id: Ief0cd90ebaf36b3df6279f4ca39456bbd1bda6b8
Introduced mw-ui-text base class for plain-text, non-interactable elements which require context colors (eg. icons)
Also added mw-ui-anchor for interactable elements (such as anchors)
Note: This is not supported by IE6 at current time.
Bug: 69212
Bug: 70801
Change-Id: I4d017d0a22cb4f3ca52b6228e45c0463c110ae64
Compatible with IE8+ (because of the use of pseudo-elements).
This includes support for icons on the left of the element and
icons which hide the text of the containing element.
I attempted to make an mw-ui-icon-element which didn't use pseudo
elements but the problem with this is how it plays with things such
as mw-ui-button and the gutter. I'd suggest exploring this later as this gets greater
adoption.
In addition to this I have dropped mw-ui-icon-after since I don't see any
clear use cases for this yet and I think it is overengineering the solution.
Bug: 55535
Change-Id: I68a1b207d8a4af57879361921a5f8c3aeda3fd9a
This ensures the rendering matches what would happen if they were
used together with addModuleStyles, which is the way these modules
are generally used.
Change-Id: I1d6f0f41dc9ac4782a4c5891354b0e323a6161b5
The user-agent stylesheet was making the size
of both the h1's and h2's 1.5em as it was inside
<article> and <section>
:-webkit-any(article,aside,nav,section)
h1 - 1.5em user agent stylesheet
~h1 - 2em~ user agent stylesheet
Change-Id: Ied1d03f63c132dc3904d05cd4e55f70aa3f80c3d
Optimise for various screen sizes, defaulting to mobile view
This stops the example from jumping underneath the code
Change-Id: I3b163568f4626f411c88ab4c1133b2ed1bed9cf2
By only requiring the actual kss-node executable, this allows
running "npm install" at a separate time/machine from the actual
build.
For example, this is useful since the machines used to run Tool Labs
grid jobs do not have npm.
Change-Id: I561b365d4aaf44d921fb54a020e9ff6319318063
Move checkbox styling from BetaFeatures extension to core.
Drop vendor prefixed border radius support (http://caniuse.com/border-radius)
Use adjacent selector which is supported IE 7 and greater
Use not selector to filter out IE < 8 which do not support :checked
Change-Id: I6a0db7c8ce33d242120f1cba9222db4e2154696c
Upstream component from Flow
Adds mw-ui-input component
Update existing (and undocumented) usage in core of mw-ui-input to
use Flow focus style
Updated usage of mw-ui-input in Special:Search and Special:Userlogin
Packaged in mediawiki.ui.inputs to allow developers to use inputs
separately to other mediawiki ui components.
Change-Id: Ida765b97e6574bdc8fbba88a08ec98ec12f3dc95
This should explain the conventions of the MediaWiki project.
Wikimedia is a prominent user of MediaWiki, but not the only one.
Other MediaWiki installations do not share all of Wikimedia's
values and mission. However, it is possible to express common values
that should guide this work in core.
Thus, I retained some of the existing text, as well as adding one other
point, accessibility (which we have discussed but was not mentioned
here).
Change-Id: Iafc8641c9b89138b3e4b7f6e274395279ddad43c
