Importing them without using (reference) causes comments from the Codex
file to be output (but only if they're /* comments */, not // comments),
which will break these tests when we upgrade to Codex 1.5.0.
Bug: T363712
Change-Id: Idb5b70e342d3f08edcabda2e8477ec2d259846cb
Less.php no longer requires mapping color names (9bdb3fda04/lib/Less/Colors.php (L9))
to their respective hex values, see: I0e6fa0fa88b4ab8dc41c55524661
(T352866).
If the color name is valid CSS, the color keyword (e.g. "green" is
preseved by the less compiler).
Change-Id: Ic91c9bb1d7b931f389cfaf3457d2fee845b9c3f0
In preparation for Codex's upcoming 1.0 release, this patch makes
some additional changes in how the library is vendored into MW.
* foreign-resources.yml: codex-search is removed as a stand-alone
package (the upstream NPM package has also been deprecated).
The search-specific build of Codex now lives in the main "codex"
package. The foreign-resources.yml file has been updated to pull
in the codex-search scripts and styles from this new location.
* resources.php: The resource module definitions for codex-search
and codex-search-styles have been updated to use the relocated
CSS/JS files.
* UMD bundles: Upstream, Codex now designates the CJS bundle as the
primary entry point. A UMD bundle of the main Codex library is still
produced but this is intended mainly for usage through CDNs or basic
script-tag inclusion; in the future the codex.umd.js bundle may be
removed from MediaWiki and users should not rely on it. The
codex-search.umd.js bundle has been removed.
* MJS bundles: Codex also produces .mjs (ESM) bundles upstream;
for users outside of MediaWiki these are the recommended bundles
to use. However, within MediaWiki only the CommonJS build should be
used, as ResourceLoader does not support delivery of ESM scripts at
present. The codex.mjs and codex-search.mjs bundles have been removed
from MediaWiki with this patch.
Bug: T335324
Bug: T340020
Bug: T340119
Bug: T344848
Bug: T345281
Bug: T345688
Bug: T346099
Bug: T346435
Bug: T346988
Change-Id: I84b26ddf5f9a0a98faf0df8c7acaa5f678032786
Importing Less files from @wikimedia/codex-design-tokens/ doesn't work,
on purpose. Instead of letting these imports fail with a nondescript
"file not found" error that doesn't help the developer understand why it
didn't work, provide a descriptive error message that points them in the
right direction.
Bug: T328602
Change-Id: I992ccde79a59ad51c7ebfe3ac7548a6e531f4a59
This makes all Codex mixins available anywhere that the skin variables
are imported, so MediaWiki code doesn't need to import these mixins
separately. This also ensures that the tokens are present when the
mixins are used.
Bug: T328602
Change-Id: If2b4073115d9082829e4917c87c167d18f5431d9
This replaces the hacky wrapper files in
resources/src/mediawiki.less/mediawiki.skin.codex-design-tokens/ and
resources/src/medawiki.less/@wikimedia/codex-icons/dist/ with real
import path aliasing/remapping.
Bug: T328602
Change-Id: I2df266cde90d1b8dad8d1d1367b67001e2b2984d
The message cache is originally meant for mw.messages in JS,
which expects non-existent messages to be cleanly omitted.
There is minimal server-side and client-side handling in place for this.
For LESS, however, we were assuming that the blob is complete,
thus not feeding anything to the LESS compiler, thus leading to
a run-time failure where the LESS file can't be parsed at all
due to an undeclared variable.
This could happen sometimes during development or after upgrading
a wiki with a stale LocalisationCache that is still being updated
at that time.
Bug: T267785
Change-Id: I60ff4eb7dce1fee56470acc177afd29ee14b764f
Add the SkinLessImportPaths attribute for skin-specific LESS import
paths, which skins can use to override the mediawiki.skin.variables.less
file.
As a starting point, add the following 5 variables:
* device widths (3x)
To help phase out 'mediawiki.ui/variables'. These are
commonly used by MobileFrontend.
* @font-family-sans
Recommended by Volker. Used by multiple skins.
* @border-radius-base
Recommended by Volker as example of something that we currently
hardcode in MediaWiki core for Vector and OOUI/WikimediaUI
in 'mediawiki.widgets.datetime' but should instead be allowed
to vary by skin and OOUI theme.
Remove the hardcoded value for '@border-radius-base' in
various places in favour of importing from mediawiki.skin.
The default is a bare default of 0 (as border-radius is off
by default in the browser).
The value for Vector is restored there by I47da304667811.
The value for MonoBook is improved by I000f319ab31b.
Bug: T112747
Change-Id: Icf86c930a3b5524254bb549624737d3b9dccb032
This was previously covered implicitly by an unrelated test.
Change that test (dependency.less) to use ../ to access the file
directly so that that test case is only about tracking dependencies
and testing the parser.
Then, add a second case that tests the use of import dirs.
Bug: T140807
Change-Id: Ie85abffe313922c03b3e146422f36b1d6a79743d
Deprecated in 1.24, for reasons explained in a0c41ae39d. I don't see any
usage in core or extensions.
Change-Id: I46f9e04ae633e7ff1ee112b652e1865731172f1f
This reverts most of commit 2d842f1425,
leaving only the test added in it, and reimplements the same
functionality better.
Instead of stripping /*@noflip*/ annotations in CSSJanus, which is
incompatible with other implementations that preserve it, extend
CSSMin to allow other CSS comments to be present before the
rule-global @embed annotation. (This required making the regex logic
in it even worse than it was, but it's actually slightly less terrible
than I expected it would be. Good thing we have tests!)
Bug: 69698
Change-Id: I58603ef64f7d7cdc6461b34721a4d6b15f15ad79
To do it, just remove /*@noflip*/ annotations in CSSJanus after
we're done processing. They are not needed anymore and some obscure
interactions with CSSMin logic for preserving comments caused
`/*@noflip*/ /*@embed*/ background-image: url(…)` not to work
correctly (it would not be embedded).
This also requires us to always do CSSJanus processing, even when we
don't need flipping, to consistently handle the annotations.
I'm not entirely sure if this is worth it, but I still greatly prefer
doing it to documenting this stupid limitation. :)
Bug: 69698
Change-Id: I311b12b08b2dff9d45efb584db08cf4a11318f59
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
