Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ie195f1614237370a19e91bf4e16f704cee678c0c
The wrapper attribute may contain an extra CSS simple selector to
include when prefixing. For example, including a template as
<templatestyles src="..." wrapper="div.my-template"/> would transform
.foo .bar { color:red; }
into
.mw-parser-output div.my-template .foo .bar{color:red}
This can allow particular templates to opt in to the "styles are scoped
to the template itself" model that was desired by some when
TemplateStyles was being designed; the driving use case in the linked
task is doing so for the benefit of side-by-side comparisons of the
current and sandboxed versions of a template.
Bug: T200441
Change-Id: If49d4c5be31feca95abd21452238fd10ab1916b1
Having a different ParserOptions for each content model isn't feasible
in an MCR world. And the only thing using this was Wikibase, which has
been fixed to do what it needs in a different way.
Bug: T194263
Change-Id: Ia95f3e2c1ea944366ff9a478c3c86f8565023394
Depends-On: I01373b29ee25fa9346c6b0317155be4ccdc8c515
Two tracking categories are added:
* A category to track stylesheets with errors. While it's usually not
possible to save a stylesheet with errors, it can happen if a
server-side change makes formerly-valid CSS become invalid.
* A category to track pages displaying errors from incorrect use of
the <templatestyles/> tag.
Bug: T195676
Change-Id: I123679d4bffe36cb28aca1688c052470027ea2a8
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: Ic9accb2eb34bc32d455f48dfe81a91d23a2d5f5e
* Fix test for TemplateStylesFontFaceAtRuleSanitizer so it's actually run
* Hack up a broken Sanitizer to test a code path in
TemplateStylesContent::sanitize() that handles such things.
* Ignore an InvalidArgumentException in TemplateStylesContent::processError()
that's not worth checking. User input can't hit that, only logic bugs.
* Ignore TemplateStylesHooks::getConfig(), it's tested but gets called
before PHPUnit starts counting.
* Test TemplateStylesHooksTest::onCodeEditorGetPageLanguage()
* Test $wgTemplateStylesDisable
* Test a back-compat code path in TemplateStylesHooks::handleTag().
Change-Id: I7078e5a353a624aa53fe72de7990b93a77b44cf6
