Dark Mode for the Atum template

[nikosdion]

Summary of Changes

• Atum uses CSS variables instead of hardcoded colours all over the place
• Atum allows you to select the colour scheme: Always Light, Browser Decides, Always Dark
• You can override the colour scheme in your user profile: Use Default (whatever the template style says), Always Light, Browser Decides, Always Dark
• TinyMCE can auto-switch its skin to oxide-dark when the template communicates it will be using a dark colour scheme. This can be turned off BOTH at the template style level AND at the editor plugin level.
• TinyMCE can optionally load a minimal CSS to make content editing use a dark colour scheme. This can be turned off in the editor plugin, e.g. if the frontend template's editor.css already does that.
• CodeMirror can auto-switch its theme to an alternate theme when the template communicates it will be using a dark colour scheme. This can be turned off BOTH at the template style level AND at the editor plugin level.
• Atum RTL simply loads the template.min.css / template.css file instead of loading a separate template-rtl.min.css / template-rtl.css which is a byte-to-byte copy of the other CSS file, making it far more efficient switching between languages with different directionality on slower Internet connections.
• Introduced a new editor plugin method public function onTemplateDarkModeSupported(bool $forcedDark) and a matching \Joomla\CMS\Editor\Editor::notifyDarkMode method for templates to notify editors that dark mode is to be applied.

Testing Instructions

Install one of the pre-built packages.

Test 1: Dark mode generally works

Switch your browser to Dark Mode (see How To Test Dark Mode below). The Joomla backend appears with a dark colour scheme.

Use as many core features as you can.

Test 2.A: Test forced light mode at the template style level

Switch your browser to Dark Mode.

Edit the default backend template style. In the Dark Mode tab set the dark mode option to Always Light.

All backend pages, including the login page are using a light colour scheme.

Test 2.B: Test forced dark mode at the template style level

Switch your browser to Light Mode.

Edit the default backend template style. In the Dark Mode tab set the dark mode option to Always Dark.

All backend pages, including the login page are using a dark colour scheme.

Test 3.A: Test forced light mode for a specific user.

Switch your browser to Dark Mode.

Edit the default backend template style. In the Dark Mode tab set the dark mode option to Browser Preference.

Edit your user. Under Basic Settings set the dark mode option to Always Light.

All backend pages, except the login page, are using a light colour scheme when you log into your site with this user account.

Test 3.B: Test forced dark mode for a specific user.

Switch your browser to Light Mode.

Edit the default backend template style. In the Dark Mode tab set the dark mode option to Browser Preference.

Edit your user. Under Basic Settings set the dark mode option to Always Dark.

All backend pages, except the login page, are using a dark colour scheme when you log into your site with this user account.

How to test Dark Mode

On Windows 10, Windows 11, macOS Catalina or later, iOS/iPadOS 13 or later, and GNOME it is generally sufficient to switch your Operating System colour scheme to dark.

All browsers except Safari and on all OS except macOS, iOS, and iPadOS let you choose whether the browser's colour scheme will follow the OS colour scheme or not. For example, Chrome has an option for the theme under settings, appearance. Using an option called Auto, System, or GTK will use the OS colour scheme.

If you are using Linux but NOT GNOME as your desktop environment auto-switch between light and dark mode may not work. Choose one.

If you don't know if your browser auto-switched to dark mode please visit duckduckgo.com or Dionysopoulos.me. If the site appears with a prominently dark background your browser has switched to dark mode.

Link to documentations

Please select:

• Documentation link for docs.joomla.org: See below; cannot do PRs to docs.joomla.org!

• Pull Request link for manual.joomla.org: Joomla Manual PR 66

Documentation for docs.joomla.org

Since it is not possible to make a PR to docs.joomla.org I am putting the documentation in four sections below and I'm waiting for instructions on how and when to proceed.

Docs: New options in Atum

URL: ATUM IS NOT DOCUMENTED(!!!) as per https://docs.joomla.org/JDOC:Joomla_4_Tutorials_Project

The Dark Mode section works similarly to the Colour Settings section. It allows you to set up the colours of the template — but for an optional, dark color scheme.

The Atum backend template lets you display the Joomla administrator backend in a dark colour scheme, suitable for low ambient light conditions and people with photosensitivity. Whether and when to use this color scheme is determined by the Dark Mode support option and can be overridden in the preferences of every user who has backend access. Please note that the setting of the Dark Mode support option in the default backend template style also controls whether the administrator login page will be displayed with a dark color scheme.

It can have one of the following settings:

• Always Light: the dark colour scheme will not be used at all.
• Browser Preference: This is the recommended and default option. The template will hoour the light or dark color scheme preference of the browser. Most browsers mirror the preference set system-side on most modern Operating Systems. Some browsers, especially those running under Linux, may allow the user to set their preferred colour scheme in the browser settings.
• Always Dark: the dark colour scheme will always be applied, regardless of the browser settings.

Atum can also communicate the dark colour scheme configuration to the editor plugins in Joomla, as long as the Dark Mode support in editors option is enabled. Please note that this only sends a signal to the editor plugin, communicating if and when a dark colour scheme needs to be applied. It is up to the editor plugin to act on this signal. The TinyMCE and CodeMirror editor plugins shipped with Joomla support and respect this signal. For third party editor plugins please refer to their documentation as supplied by their developers.

The rest of the options are identical to those found under Colour Settings and have the same meaning, but only apply when the dark colour scheme is in use.

New user options

URL: https://help.joomla.org/proxy?keyref=Help42:Users:_Edit_Profile&lang=en

(Place this under section 4.3 Basic settings, below “Backend Template Style”)

• Administrator Dark Mode: Choose the preferred color scheme of the administrator template. You can choose between a light and a dark colour scheme, or have it automatically follow your browser's preferences. In most cases, the browser preferences are identical to your Operating System's preference for light or dark display. Use Default uses the preference for this option defined in the administrator template style you are using. This option may not work for all administrator site templates.

Docs: Editor - CodeMirror

URL: https://docs.joomla.org/Chunk4x:Extensions_Plugin_Manager_Edit_Editor_Group/en#Editor_-_CodeMirror

Dark Mode.

This tab allows you to choose what happens when your site displays with a dark color scheme. Please note that options in this tab may not work with all front- and backend templates. The settings will only be applied if the template communicates that it's using a dark colour scheme.

• Auto-apply Dark Mode. The editor will use an alternate color theme when your template communicates that it is using a dark colour scheme.
• Dark Theme. The alternate theme to use when your template communicates that it is using a dark colour scheme. Please note that this drop-down list includes all CodeMirror themes. It is ultimately up to you to select a theme which looks dark to you and seems to work best with your site's dark colour scheme.

Docs: Editor - TinyMCE

URL: https://docs.joomla.org/Chunk4x:Extensions_Plugin_Manager_Edit_Editor_Group/en#Editor_-_TinyMCE

Dark Mode.

This tab allows you to choose what happens when your site displays with a dark color scheme. Please note that options in this tab may not work with all front- and backend templates. The settings will only be applied if the template communicates that it's using a dark colour scheme.

• Auto-apply Dark Mode. The editor will use an alternate color theme when your template communicates that it is using a dark colour scheme.
• Load dark color scheme compatibility CSS in the editor. Loads a small CSS file which tries to apply a dark colour scheme on the edited content. You are recommended to disable this option if your frontend template includes support for a dark colour scheme in its editor.css file. If unsure, ask your template developer.

Please note that the “Auto-apply Dark Mode” option only takes effect if you have selected either - Use Default - or oxide in the Plugin tab options “Site Skin” (applies to the site's frontend only) and “Administrator Skin” (applies to the site's backend only). If you have chosen a different skin that skin will be used when your template displays in both light and dark color schemes.

As noted, not all templates communicate their dark color scheme preference to editors — or can be configured not to do that. In this case the options in the Plugin tab apply.

Backwards compatibility notes

The PR is generally backwards compatible i.e. nothing breaks code-wise.

The introduction of the dark mode MAY cause minor display issues in some third party extensions. Extension developers are very strongly encouraged to support dark mode using the developer documentation (see the PR to manual.joomla.org).

Third party editor plugin developers are strongly encouraged to support dark mode using the developer documentation (see the PR to manual.joomla.org).

Translation impact

This PR introduces new language strings. This happens in the alpha stage which gives translation teams adequate time to work through these very few language strings.

Thoughts, questions, various information

There are CSS variables everywhere

Upon consulting with @crystalenka, I was told that the best way to go about implementing Dark Mode is to introduce CSS variables for distinct color patterns everywhere in the backend. Their utility reaches far beyond the implementation of dark mode. They can be used as a starting point for reworking the backend template into reusable components. They can be used to offer a real high contrast mode (instead of the current cop-out of just applying a filter which increases the overall contrast by 25%, with dubious results). In theory, someone could use them to provide an entirely different color scheme without having to override Bootstrap's SCSS defines, e.g. if someone with real commitment to their cause wants to create a child template of Atum.

Why is there extra CSS in TinyMCE?

TinyMCE unfortunately has its own weird way of handling CSS for its themes and it works by applying a CSS file in the IFRAME created in the Shadow DOM when the editor is initialised at runtime. It's not possible to load an additional CSS file after the fact, nor is it possible to load two or more CSS files (skins) at once. This normally limits TinyMCE to either a light (oxide) or dark (oxide-dark) skin.

In order to support dynamic colour scheme switching of the editor's UI following the browser settings (if that's what the user has opted for) I had to create a combined theme which is the oxide skin with the colour settings (and only the colour settings!) of the oxide-dark skin when the browser indicates we need to use a dark scheme. Hence the extra CSS.

Does X happen when Y?

If you have to ask this question it means you didn't test the PR 😉 Why don't you try it out for yourself? Chances are I have already thought of that and implemented it.

Seriously now, please DO NOT ask me questions which are self-evident if you actually test this PR. It will add to my workload and slow down this PR unnecessarily.

I do not see the light / dark mode when my system and browser settings are this and that

Hold up!

Visit the following sites:

• https://webkit.org/blog/8840/dark-mode-support-in-webkit/
• https://dionysopoulos.me/dark-mode-is-the-new-black.html
• https://www.akeeba.com
  All three sites have an automatic Light Mode / Dark Mode switch already implemented. The first one is maintained by Apple, the latter two by yours truly.

If you do NOT see the light/dark color scheme you expected, then the problem is with your setup. Remember that for dark mode to switch automatically you will need one of the following:

• Your Operating System using Dark Mode and your browser using an automatic color scheme. This is NOT the default case in Linux. If you're using anything other than GNOME even if you switch your desktop environment's theme you will be stuck with only light or only dark mode, depending on your browser settings. If you are using GNOME, sometimes you may have to log out and back into GNOME before the browser “takes” the new colour scheme.
• Your browser set to use a specific color scheme. This is typically set up in the browser's options. Safari does NOT have such an option; it always follows the display mode of macOS / iOS / iPadOS.

If you see the correct color scheme you expected in all three sites but not in the site you are testing please make sure that:

• you are NOT using Patch Tester; this PR changes CSS files therefore you'll need to either use the repository sources or one of the pre-built archives.
• you have run npm ci if you are using the repository sources (otherwise the CSS files WILL NOT BE REBUILT).
• cleared your browser's cache.
• set the Dark Mode option in the backend template style you are using.
• set the Dark Mode option in the user profile you are using (the user profile settings OVERRIDE the template style settings).

Remember that the default settings for the backend template is to follow the browser's preference and communicate the dark mode setting to the editor. The default for the user settings is to do whatever the template style says.

The editor is not changing to dark mode when the site is changing to dark mode

Make sure the template style has the Dark Mode support in editors option enabled (that's the default). Make sure that you are using either TinyMCE or CodeMirror supplied with Joomla itself; third party editors cannot possibly implement dark mode support before this PR is merged. Make sure that the editor you are using is set up to support dark mode (default).

Also remember that TinyMCE will only change its skin if you have selected the default skin, oxide. If you have selected oxide-dark, then oxide-dark will always be used and the content will NOT change to dark mode. This is deliberate as we don't want to catch users by surprise if they are using a non-default skin.

Do keep in mind that CodeMirror can be set up to use a non-default theme. It is possible that you've set it up to use a theme which is already dark. It is also possible to select a light-coloured theme for CodeMirror's dark mode as there is no positive indication in the theme names which one is light and which one is dark (at least, it's not consistent, therefore cannot be used).

Why show all CodeMirror themes for its Dark Mode when some are a light colour scheme?

Because the dark colour scheme themes DO NOT follow a consistent naming pattern. For example, Darcula and Dracula are dark colour scheme themes but do not have "dark" in their name.

To paraphrase Steve Jobs: “we have the reasonable expectation that our users are not stupid”.

I have a problem with extension X using Dark Mode

Chances are that it does not support Dark Mode for the simple reason that Dark Mode did not exist before Joomla 4.3, i.e. when this PR will be merged.

It is also likely that my own extensions will need a bit of a reworking to play well on Joomla 4.3 which is to say that I'm not giving myself an unfair advantage here. All of us 3PDs are in the same position.

I am getting some weird colours in Dark Mode

Do you have a 3PD extension implementing its own dark colour scheme, such as my DarkMagic plugin? Disable it!

The colour contrast is not accessible

There's only so much I can do when working with the limited palette of Dark Mode.

HOWEVER! Since we're using CSS variables everywhere I would expect that the fine folks at the Joomla Accessibility Team (most likely the design expert @angieradtke) can come up with a high contrast light and dark colour scheme we can very easily include in Atum. Moreover, if colours do need to be adjusted the JAT can very easily make the changes in the SCSS files as there are only two files (build/media_source/templates/administrator/atum/dark/_variables.scss and _root.scss) which need changing to tweak colours.

The idea here is to provide the groundwork for allowing multiple colour schemes in Joomla templates. We MUST NOT have the expectation that Joomla 4.3 will have a super duper ultra accessible and fully refined dark mode. This is something which will reasonably take the rest of the time to Joomla 4.4 / 5.0 to get there for two very simple reasons:

• You cannot know what you don't know, i.e. how 3PDs will interact with it.
• You cannot go through the entirety of Joomla with manual testing within a reasonable amount of time unless someone is paying you to spend the next several months doing that. Instead, we have to rely on what we bump into and reports we get as we go along after merging this PR.

Also keep in mind that unlike every other decision made in Joomla 4's templates, the decisions here are made in public, in the main repository. Everyone can see why at some point we have to say “that's good enough for version 1 of this feature” instead of making up a story. This is far more helpful in that it communicates the decision context and deadline limits we have to address when making these decisions. When we introduce a massive new feature we aim for a minimum viable product, not absolute perfection. Even multi-trillion dollar companies like Microsoft, Google, and Apple follow this approach; who are we to pretend we can do better with less than a billionth of their budget?

[nikosdion]

@brianteeman Re: RTL. These are out of scope for this PR. Since you've correctly pointed out that PRs should be thematic, not a laundry list of unrelated items I would not do that here.

Re: linting. All of these issues come from the existing 4.2 code. Addressing that would also not be thematically appropriate for this PR. That's a different PR.

Note about the thematic PR concept and this PR. I did follow this, even though you might think I did not. Yes, this PR does add CSS variables and does make changes to two plugins and the Editor class. However, these are prerequisites for the PR's theme (dark mode in Atum) to be at all possible. Otherwise it would be half-done and we know that half-done in Joomla means never done. They are not unrelated, incidental changes. The removal of the useless RTL file was also not unrelated; the way it was coded, SCSS had to build the template TWICE which was slowing down the development of this PR for no valid reason. I removed it permanently, as opposed to temporarily, because it was indeed useless having the exact same file twice under two different names.

Re: everything else. I will take a look and address it.

[brianteeman]

UPDATE: Workiing correctly now that the rtl code has been restored

tinymce editor button

before

after

[brianteeman]

UPDATE: Workiing correctly now that the rtl code has been restored

view=template

Before

After

[nikosdion]

OK, @brianteeman, I will restore the EXACT SAME RTL file you had before, noting that it's completely useless (it loads the same CSS) and I have not touched anything regarding directionality as can be trivially seen in my PR. You can then have fun in a DIFFERENT PULL REQUEST with why RTL is cocked up everywhere in Joomla, okay?

THIS PULL REQUEST IS ABOUT DARK MODE, DAMMIT!

It is not a bloody excuse to have me work my ass off for months to fix everything two dozen people didn't manage to address the past 6 years, FFS!

[brianteeman]

As I have shown it clearly is not the same css currently with ltr and rtl. If it is after you made your changes then clearly I have shown it is wrong

Adding dark mode is great - but that shouldn't break existing stuff - and yes I spent days working on it - thats why I knew the code here was wrong. I am wondering if you even had the latest version #38412

As for the lint. The errors are in the new code in this PR so they need to be addressed before it can be merged. Pretty sure the same rules apply to you as everyone else

[nikosdion]

#39364 (comment) Search tool input boxes background: fixed

#39364 (comment) Tabbed items header: fixed

#39364 (comment) Image selector palceholder image: cannot reproduce. I have also not touched that. Looks like you're missing a file somehow?

#39364 (comment) #39364 (comment) #39364 (comment) LTR reverted to what it was before 🤷🏽

[wilsonge]

If you are using Linux but NOT GNOME as your desktop environment auto-switch between light and dark mode may not work. Choose one.

Funnily enough linux and gnome also doesn't work in chromium based browsers (but does work fine in firefox). 4 year old report here: https://bugs.chromium.org/p/chromium/issues/detail?id=998903 . Been finding this one out the hard way the last few weeks. Doesn't affect this PR but just as an FYI :)

On a more serious note - bootstrap merged in dark mode support in 5.3 alpha last week twbs/bootstrap#35857 - from a maintainers perspective is this going to be painful (or not) to move across to the "official" way whenever that comes out or is this inspired from that? I will try and spend some time reviewing the two over the next few days but if you have time to give me the overview before billions of bug fixes come in would be useful!

[nikosdion]

Okay, sorry for taking up your time. I am closing this PR and not bothering with CSS in Joomla again.

[brianteeman]

On a more serious note - bootstrap merged in dark mode support in 5.3 alpha last week

But we havent even merged in 5.2 yet and last I heard that would not be done until joomla 5

[crystalenka]

Even if we were to move to Bootstrap 5.3, a lot of the work done here would still be necessary because of the current hard coded colors. (And moving to 5.3 is a big if)

[brianteeman]

All the variables stuff is good - and would be needed for 5.2 as well

[nikosdion]

I worked on whatever was on the 4.3-dev branch. Obviously the 4.3-dev branch was extremely outdated —or at the very least not well maintained— as the file on that branch contained all of one line: @import "template"; whereas the same file in 4.2-dev is much different and explains the disparities Brian found: https:/joomla/joomla-cms/blob/4.2-dev/build/media_source/templates/administrator/atum/scss/template-rtl.scss

This is extremely disappointing. It means that I would have to cherry-pick the 4.2-dev branch and go through each SCSS file on the Atum template line by line to see if there are other changes which were not implemented in 4.3-dev.

Unfortunately, I have already spent 60 hours of my life into it. I am too discouraged to spend another God-knows-how-many-more to essentially redo everything.

[brianteeman]

ah - I think I know what may have happened to explain why the rtl was so broken and you didnt notice. when you run npm ci it does not appear to delete the existing css files - it just overwrites them so even after you made your changes the existing rtl.css file was still present.

and/or

Nothing to do with the branch being out of date. What you are seeing regarding RTL differences between 4.2 and 4.3 is the result of the work I did in #38412

That PR added the rtlcss postcss plugin which is what does the magic and creates the rtl css file correctly and does magical things such as changing position: left to position: right

Its all documented in that PR

[wilsonge]

But we havent even merged in 5.2 yet and last I heard that would not be done until joomla 5

News to me - but I'm also not involved in these decisions anymore. @HLeithner can you confirm either way? I wouldn't understand why we couldn't upgrade minor versions within a major version?? Totally understand 5.3 may not ship with core until J4.4 potentially (could understand the logic of only doing the BS minor updates in a J minor version).

I worked on whatever was on the 4.3-dev branch. Obviously the 4.3-dev branch was extremely outdated —or at the very least not well maintained— as the file on that branch contained all of one line: @import "template"; whereas the same file in 4.2-dev is much different and explains the disparities Brian found: https:/joomla/joomla-cms/blob/4.2-dev/build/media_source/templates/administrator/atum/scss/template-rtl.scss

So that's actually "intended" and comes from Brian's PR here #38412

Even if we were to move to Bootstrap 5.3, a lot of the work done here would still be necessary because of the current hard coded colors. (And moving to 5.3 is a big if)

Totally get that. I didn't intend it to be closed. What I wanted to make sure was that we didn't back ourselves into any corners by doing it ourselves when there's something else coming and to not be a million miles away when we come to moving over. And all the pre-req's definitely happy to get in ahead of time.

[nikosdion]

@brianteeman You are wrong. I know that 100% I didn't cock this up myself. I checked my Git history because I started doubting myself. Nope. I did not miss anything, I really did pull 4.3-dev before I started working last week.

BUT! Here's the ridiculousness I see.

4.3-dev has the wrong file right now, as I am typing this: https:/joomla/joomla-cms/blob/4.3-dev/build/media_source/templates/administrator/atum/scss/template-rtl.scss

4.2-dev has the up to date file: https:/joomla/joomla-cms/blob/4.2-dev/build/media_source/templates/administrator/atum/scss/template-rtl.scss

The up-to-date file says it's modified 12 months ago, ostensibly before 4.3-dev was forked off 4.2-dev.

How the heck is that even possible?!!!

There are PRs being merged against 4.3-dev. Is that branch up-to-date? I can see it has MFA, but it does not have the template changes. What else has been left behind?

[brianteeman]

4.3dev is correct as both @wilsonge asnd I have explained

[nikosdion]

In this case Joomla's build system is broken.

You cannot possibly be expected to run npm ci which takes 5' every time you change a single SCSS variable. This would make it impossible to develop a template as the 60 hours I have already spend would balloon to well over 1500 hours!

Either npm run build:css should do whatever it is that needs to be done OR it should refuse to run and tell people that trying to develop a Joomla template is a lost cause.

Moreover, Drone already runs npm ci. If that plugin was running correctly with npm ci then the built packages would be right. You showed yourself that they are wrong. Therefore something is wrong here.

Finally, none of that is documented in the README.md.

As a result, something is broken. Something that's undocumented, completely opaque, and impossible for me to test its results.

Which means that you need to find a developer who speaks Hebrew or Arabic, knows as much as I do about Dark Mode in CSS and how Joomla works on the PHP side, can troubleshoot the undocumented Joomla build system, and has dozens of unpaid hours available to work on this. Good luck finding that person, if it even exists.

[brianteeman]

In this case Joomla's build system is broken.

How is it broken? both npm ci and npm run build:css uses compilecss.js which does the css prefix stuff and now in 4.3 it also does the rtl stuff. And the build packages are correct

[nikosdion]

I did run npm i per your PR and it did sod all. Remember, I have reverted the template-rtl.scss to what is in the 4.3-dev branch.

FWIW, the file in the 4.2-dev branch is different than the file in the 4.3-dev branch. It does reference, though, a vendor/bootstrap/_rtl.scss file which does not exist in the repo. If I change the template-rtl.scss to that file, both npm i and npm ci fail because that file is missing.

So, clearly, there are undocumented bits and pieces in the build system and/or the build system does not work.

[nikosdion]

At the very least, can someone tell me how the hell is it possible that 4.3-dev is up to date with 4.2-dev when the bloody template-rtl.scss file in the two branches IS DIFFERENT?

Obviously, one of the two is wrong. Which one is wrong and why? What is the right way to do things?

If the template-rtl.scss file is needed because some magic action at a distance will work on it when you run npm whatever-the-heck then we MUST document this AT THE TOP OF THE DAMN FILE! Otherwise, the reasonable assumption is that this file does sod all and should not exist — that's what I understand seeing a file having a single SCSS rule which imports another file and that's what anyone else will understand.

If running npm ci does perform some magic action which magically fixes RTL, why did Brian have problems after I restored the file to its previous state?

Looking at a PR which only says "run npm i and magic will happen" is a far cry from being helpful in any shape, form, or fashion. Not to mention that it's impossible to find without being pointed to it to begin with.

Do you people understand what DX means? Developer experience. Your PRs have made DX a nightmare. Developing the core requires MAGIC UNDOCUMENTED KNOWLEDGE. Do you think this is a good thing? In which possible bloody universe?! We want to attract contributors… by keeping it a secret how thing are meant to work? And then point contributors to a PR with absolutely zero useful information and treat them like idiots for not divining whatever is not written there? Screw that noise!

[wilsonge]

Obviously, one of the two is wrong. Which one is wrong and why? What is the right way to do things?

So 4.2 has the original RTL code we used in 4.0. In BS 5.1 they released native functionality to do RTL (using postcss) which we are starting to take advantage of in the 4.3 branch and was implemented in #38412

So both branches are different. what is in 4.3 is the new "strategic" code (or whatever terminology you want to use). But doesn't mean it needs synching into 4.2 either because there is some (although limited) risk for 3PD

[brianteeman]

i give up - it is always someones fault.

If running npm ci does perform some magic action which magically fixes RTL, why did Brian have problems after I restored the file to its previous state?

I didnt - I even updated the error reports above to confirm that I did not

Does the readme say you dont need to write prefixed css? No of course not. If it included everything then it would be 50 pages long and no one would read it. It includes all the instructions required to build the system. George and I botth explained. You refuse to even attempt to listen and instead insist that the build system,s are wrong AND that the prebuilt packages are wrong. Without the courtesy of checking it or checking what George and I wrote. Instead you insisted template.css and template-rtl.css are identical without checking. If you had at a minimum checked you would have seen they were different and I dunno maybe thought to see how and why

Atum RTL simply loads the template.min.css / template.css file instead of loading a separate template-rtl.min.css / template-rtl.css which is a byte-to-byte copy of the other CSS file, making it far more efficient switching between languages with different directionality on slower Internet connections.

. Going to watch the football

[nikosdion]

@brianteeman

Don't you DARE treat me like an idiot! I've had enough with your toxicity!

I know my SCSS. What do you think I've been doing since 2016? That's how my own extensions' CSS is generated and that's how I've written the templates of my own sites.

From an SCSS point of view the template.scss and template-rtl.scss ARE identical.
The latter has exactly one line which includes the former. There is no explanation. The only comment says that it's a placeholder file which implies that it's useless.

Nobody was ever bothered to put a comment on that file that even though it looks useless it actually does something, what that something is, and that it should not be touched. I do not accept that it's my fault that I could not divine its purpose.

I asked you very specific questions:

• Why are the template-rtl.scss files different in 4.2-dev and 4.3-dev.
• What is the magic happening.
• Where is the magic happening.

You replied to exactly ZERO questions and, yes, I did read your replies. All you did was point me to your PR (#38412) which explains absolutely none of that. And no, Brian, I am not going to reverse engineer your PR and try to MAGICALLY guess where PostCSS came from and why it's used, because for all I knew coming here PostCSS is typically used as an alternative to SCSS which I have already used when working with Charlie's Lightning template, upon which my blog's template was based (before moving it to a sub-template of Cassiopeia). Have you ever considered the fact that I actually do work with frontend stuff? I am neither a designer, not a frontend developer, by choice but I still need to build sites and extensions which —imagine that— do have a need to display in something other than plain text. Is that what you think of backend developers? That we are idiots who only know PHP? Wow. Just wow.

In any case, since your link came as an answer to why these files are different, the implied response here is that running npm i (the only thing you say in your PR) should modify the SCSS files which would explain the discrepancy in the two branches. I am sorry that you TOTALLY SUCK at answering questions and explaining things, but that's a you problem, not a me problem. You are at least consistent in being unhelpful.

It was George who replied the first two questions and half of the third question, giving me a thread to start understanding what is going on.

For your information, here is what a helpful reply would have been.

PR #38412 removed the hardcoded RTL from Joomla CSS. RTL support is added automatically to the built CSS files (but not the SCSS) when you compile the SCSS sources through Joomla's build system. The template-rtl.scss file needs to exist because only files with the -rtl suffix in their name get the magic RTL support applied to them. The magic RTL support is implemented with PostCSS and it's implemented in the build/build-modules-js/stylesheets/handle-scss.es6.js file.

Would it be so hard for you to reply in four simple sentences instead of treating me like an idiot and getting angry I cannot magically divine the missing information from your PR which has ZERO useful information in it? Is it too much to ask? If you can't be helpful don't reply.

As for documenting things, when I make a PR I document what I did, why I did it, how it works, the requirements, the gotchas, and how to address the gotchas. You have never done any of that. I don't write all these long PR intro texts just for the fun of it. It's not even for the people who will be reviewing the PR, you know! It's a way to pass along institutional knowledge and answer future contributors' questions months, or years, after my PR is (hopefully) merged. Someone will come across some code which points them to my PR. They will wonder "WTF is going on here?" and read my PR. Then they will know why things are the way they are and find answers to their questions.

Moreover, your reply was worse than useless. Your PR implies that we must run npm i for the unspecified magic to take place using unspecified conditions at unspecified files at an unspecified point in time of the build system. This is worse than useless, it's actively harmful! Running that command takes a very, very long time. I have timed it anywhere from 20 seconds (on my M2 MacBook Pro) to well over 5 minutes (on my small form factor Linux box with a 7th gen i5 mobile processor). This is impractical for doing a template change that is more than 2 lines long. Definitely not suitable for developing something like dark mode which requires thousands of SCSS recompilations. Just running the recompilations with your worse than useless suggestion would have taken me twice as long as it already did. Had you bothered to explain that running npm run build:css ... has the same effect it would have been useful. The way you replied basically told me and other potential contributors that nobody is to develop the core templates in any substantial way unless they have months to waste.

Finally, I already told you I cannot read, let alone speak, Arabic or Hebrew. I cannot use Joomla in either of these two languages. I cannot possibly test RTL. I already explained that. I did not make an assumption, I made an inference based on YOUR feedback which you never bothered clarifying. Once again, you are telling me I am stupid for not divining what you should have told me.

I don't what else to say. You project your inability to explain anything in an even remotely useful way upon other people and then abuse them for asking for clarifications upon your useless blathering. Okay, boomer. I guess I'll have to block you on GitHub so you cannot comment on my PRs.

[nikosdion]

Reopened as #39366