Extensions can register additional namespaces by setting the
"TemplateStylesNamespaces" attribte in their extension.json. This change is
analogous to Ia5d34cb78fa6af.
There isn't really a simpler way to do this here, as the config setting uses
namespaces as keys, while the attribute is using them as values. Furthermore,
keys with falsey values are ignored in the config setting, and attributes can't
use the same setting architecture, as array_merge_recursive doesn't maintain
numeric keys.
Bug: T200914
Depends-On: I9e62a02ed2044c847e9ab2dcdfab094001f88986
Change-Id: I2fa9b822ee39bcc5f95a293c8c4aad4d53ede30a
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
Use the facility added in core change I055abdf4d to deduplicate the
embedded style rules.
Bug: T168333
Change-Id: I98c6d5ca4b474de8826b19355f15a5230aef5650
Depends-On: I055abdf4d73ec65771eaa4fe0999ec907c831568
* 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
This just hides the error if something's broken with extension
registration because skipped tests don't result in a failed suite.
Instead, explode in everybody's eyes to make it clear there's a
problem.
Change-Id: I2f1e80a1fa4b99d857671c9d1061d34449764f01
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.FunctionComment.Missing.Protected
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: Ic998e3f2a791bf987f826d6dd0e92a8de24be5b7
Also fold a unit test into the normal function since we don't have to
have two valid responses based on css-sanitizer version.
Change-Id: I107c8b911781924ce9cc0730257243b9cb1592a6
wikimedia/css-sanitizer provides a real CSS parser, which should be
safer than poking at things with regular expressions.
Instead of the strange hybrid model that tried to both process inline
CSS and save CSS when the template is saved, it now looks for
<templatestyles src="Title" /> during the parse to do all the
transclusion of styles.
The output method is "<style> tags in the body", pending someone
implementing T160563.
It now also registers a "sanitized-css" content model, which should pick
up the CSS syntax highlighting and will validate the submitted CSS on
submit and prevent a save if it's not valid.
This patch also takes advantage of LGPL-2.x § 3 to relicense the
extension as GPL-2.0+, although at this point none of the LGPL code
remains anyway.
Bug: T133408
Bug: T136054
Bug: T135788
Bug: T135789
Change-Id: I993e6f18d32a43aac8398743133d227b05133bbd
Depends-On: If4eb5bf71f94fa366ec4eddb6964e8f4df6b824a
* Add phpdoc comments
* Rename some variables to be a bit more clear for new readers
* Break up render() to make things more readable and reduce cyclomatic
complexity
Change-Id: Iceeb1f6eb09b61efe6b81f359d28741f54fe88ad
Properties listed in $wgTemplateStylesPropertyBlacklist, or
those that contain function-like values not listed in
$wgTemplateStylesFunctionWhitelist cause the containing
declaration to be omitted from rendering entirely.
Additionally, rule selectors are unconditionally prepended
with '#mw-content-text' so that they cannot be applied to
UI elements outside the actual page content.
Change-Id: Id3d7dff465363d0163e4a5a1f31e770b4b0a67e2
Add some comments and tweak the formatting of the test suite. Some
things that were hardcoded can now be tweaked by the
parse->render->verify tests if desired.
Change-Id: I36abc9fa2b9971d6b92d5714c4583dea6ad26b88
Test the roundtrip on a collection of correct and pathological
stylesheets to ascertain whether the parse is behaving as
expected.
Bug: T483
Change-Id: I484cc856b5696c1fa6265769320f79853365e1d6
