user CSS and sitewide CSS are already loaded separately, and already cannot break each other syntactically for the reasons you describe.

"sitewide CSS" refers to pages like MediaWiki:Common.css and MediaWiki:Vector.css, e.g. defined in mediawiki-core: SiteStylesModule.php. It is loaded on all pages of a wiki, for all users (logged-in and logged-out alike). It declares group=GROUP_SITE, which instructs ResourceLoader to bundle it only with modules in that same group (by default, there is nothing else in this group).

"user CSS" refers to pages like User:PrimeHunter/timeless.css, and is defined at mediawiki-core: UserStylesModule.php with group=GROUP_USER.

However, what you might not realize is that pages like MediaWiki:Group-sysop.css and MediaWiki:Group-user.css are considered part of "user CSS" as defined in UserStylesModule.php, not "sitewide CSS". This is because their inclusion and applicability varies for each user separately, i.e. their personal pages, preferences, permissions, and group memberships.

The order in UserStylesModule.php is as follows (introduced by r82285 in 2011, and kept stable across the change 288055 and change 301314 refactors of 2016):

• User:Name/common.css
• User:Name/myskin.css
• foreach user->getEffectiveGroups: MediaWiki:Group-$group.css

This means earlier files enjoy greater protection than later files in the case of syntax errors elsewhere in the bundle. Due to how sensitive CSS ordering is to backward-compatibility, this has been kept stable over the years.

In terms of syntax errors that originate from lack of browser support (i.e. new features that some browsers didn't support yet), these are not affected by ordering since CSS tolerates and recovers automatically from syntax errors. However, syntax errors from authoring mistakes (i.e. unclosed block) are indeed going to break subsequent files in the same bundle.

We could repurpose this bug report as a feature request to introduce some kind of linting/validation for CSS pages. The difficulty with doing so is that the power of personal CSS in MediaWiki comes from being unrestricted. If we start to impose and ignore/correct seemingly "invalid" CSS, this means you'll be limited to syntax that MediaWiki has recognised, and thus may be unable to adopt experimental or modern CSS features that your browser of choice already supports.

As such, I would not recommend that. It would likely also incur non-trivial performance overhead and involve various maintenance costs. I think these kind of flexible and communty-building tools work best when they are not held back and tied to the priorities of WMF or MediaWiki core.

One solution that might work for you is the CodeEditor extension. This is deployed and enabled on all wikis by default, and includes a CSS linter. The linter is not required to pass, so you can always decide to save it anyway if some its warnings or error are not applicable to your situation.

It seems that the CSS linter does not detect your example where the unclosed comment is at the start of the document, rather than with anything in front of it. I've reported this upstream at https://github.com/ajaxorg/ace/issues/5770.

"Ace" is the software used by the MediaWiki CodeEditor extension.

Thanks for the detailed reply.
An unclosed comment doesn't give a CodeEditor warning anywhere as far as I can tell. It just causes the rest of the page (and maybe other pages) to become part of the comment.

The example with a warning at https://github.com/ajaxorg/ace/issues/5770 is

x/* .foo { color: red }

but the warning is about the isolated x and also happens if x is alone on the whole page.

If a CSS page is treated in isolation then there may be no difference between an unclosed comment and closing it at the end of the page. Maybe that's why CSS linting ignores it. But I think it's unfortunate that it can affect other bundled CSS pages. That seems much more likely to cause unwanted and confusing errors than be used deliberately as a feature.

Please note Wikimedia may get rid of CodeEditor/Ace after T373711: Add support for Scribunto, JavaScript, CSS, JSON and Vue to CodeMirror 6 is resolved.