User tests: Successful: Unsuccessful:
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.editor.css
already does that.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.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.Install one of the pre-built packages.
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.
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.
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.
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.
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.
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.
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
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.
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:
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.
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”)
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.
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.
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.
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).
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.
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.
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.
If you have to ask this question it means you didn't test the PR
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.
Hold up!
Visit the following sites:
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:
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:
npm ci
if you are using the repository sources (otherwise the CSS files WILL NOT BE REBUILT).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.
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).
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”.
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.
Do you have a 3PD extension implementing its own dark colour scheme, such as my DarkMagic plugin? Disable it!
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:
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?
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_users Language & Strings Templates (admin) Repository NPM Change |
Labels |
Added:
Language Change
NPM Resource Changed
PR-4.3-dev
|
@brianteeman They were. The RTL file just included the LTR file! My guesstimation for the reasoning is that in Bootstrap 5 they no longer use left and right, they use start and end for all the CSS properties.
I agree about the CSS variables. That's what prompted this PR, to be honest. I was complaining about how it's all hardcoded colours to Crystal and how using variables would make dark mode easy to implement. Well, foot meet mouth. Next thing I know, I spent a week working on this PR
I would like to be clear that I did not put you up to this though :p Just maybe encouraged the idea when you brought it up....
@crystalenka It's true. I don't need help putting my foot into my mouth. You just let me talk and then I reach the conclusion that I have to do it if I want to see it done. Story of my (Joomla!) life.
@brianteeman They were. The RTL file just included the LTR file! My guesstimation for the reasoning is that in Bootstrap 5 they no longer use left and right, they use start and end for all the CSS properties.
actually if you look back then you will see I did the pr to change our templates to use logical properties. bs5 was such a late addition to J4 that our css was not updated to logical properties
however there are definitely areas in atum where the logical property is not used deliberately - mainly for inputs which have be forced to be ltr for example. these need reviewing
@brianteeman We could totally work together to do that once this PR is merged. My biggest roadblock is that I can read neither Arabic nor Hebrew. I did test glyph-by-glyph when I wrote my Fediverse Tools extension but I'm not doing that again
My 2c is that even if with this PR they are byte for byte identical we should still have seperate files generated because they really shouldnt be. For example font-sizes in arabic are typically different to latin and you couldt easily address that in a single css file OR a single user.css. That (and other things) I would like to address moving forward. So even if they are identical can you please put the code back that generates and uses the rtl versions
I dont know why drone is not pcking up on it but can you please run npm run lint:css
locally and fix the issues it raises
@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.
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!
Labels |
Added:
a11y
|
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
#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 ??
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!
Okay, sorry for taking up your time. I am closing this PR and not bothering with CSS in Joomla again.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-12-06 14:36:36 |
Closed_By | ⇒ | nikosdion |
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
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)
All the variables stuff is good - and would be needed for 5.2 as well
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://github.com/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.
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
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://github.com/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.
@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://github.com/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://github.com/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?
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.
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
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.
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!
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
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
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:
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 thebuild/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.
I am suprised that the rtl and ltr are identical - will need to check that. I am sure there were parts I was unable to use logical properties for.
But overall these changes are great - the better use of css variables will make life so much easier