Sorry but NO. There is also Autoprefix in the loop here which this PHP version totally ignores but MOST IMPORTANTLY the PHP compiler is hot garbage, check how many issues are for not being compliant with the language (SASS) that is supposed to compile from.

The solution is not something in the PHP world, the project should embrace WASM and let the compilation happen in the browser (where the proper tools ARE available)

In short, NO

Just for the history here, I had proposed the wasm with a demo code 3 years ago: https://github.com/dgrammatiko/scss-wasm-compile but for some reasons (I can't recall them right now) it was rejected

And how about this one?
https://jonathanharrell.github.io/hiq/
There is a J4 template named 'lightning' by C-Lodder on Github, which makes use of the HiQ system.
https://github.com/C-Lodder/lightning
If I'm not mistaken, it uses nodejs to compile css + js into minized form. On my J4.0.2 test installation it loads approximately 220 kb less than Cassiopeia with identical content.and it comes with very easy to use override options.

@Gitjk what does that template have to do with compiling scss from within the template manager?

@brianteeman - You seem to be everywhere ?

I added the template link only as an example. Just thought the HiQ system which uses PostCSS might be another alternative to improve the usability of the J4 template system for users without programming skills. Of course I might be wrong...

it is completely off the topic of adding a scss compiler to the template manager

Just for the history here, I had proposed the wasm with a demo code 3 years ago: https://github.com/dgrammatiko/scss-wasm-compile but for some reasons (I can't recall them right now) it was rejected

You're sure you actually did an RFC for it? I only found two references in a comment of another issue. But no real discussion around it. First one I found was #31091 (comment)
But maybe I did search wrong. Would be interesting why it was rejected (if it was proposed).

One thing with browser side compiling is for sure that you need to take care of security concerns. And you need to upload the file somehow (as automated as possible - to keep it as simple as possible) and overwrite the existing one.

The PHP approach would make those things much simpler both for code and for usability. Of course only if it is getting reliable results, which it seems to do for Cassiopeia according to Hannes.

I would personally love to see some sort of compiler integrated. I was using the LESS one in J3 for a project and while it had its issues, I could make it work fine for my use case.

Of course only if it is getting reliable results, which it seems to do for Cassiopeia according to Hannes.

Which it doesn't because that thing is not spec compliant.

Anyways the project can't expect to have what the rest of the industry has as the defaults (eg npm packages) somehow rewritten in php. The project has to realize that the web's languages are html/js/css. The reason that sass is part of the project is purely on the wrong decision for bootstrap. You won't fix one mistake by making another mistake.

And lastly nesting (which is the main reason to use sass) is already on stage 4 meaning in few months will be in every browser. And from this perspective adding sass support is not a future proof addition.

I'm short, once again, this is completely wrong...

And how about this one?

@Gitjk that CSS framework was proposed as an alternative to BS back in 2018. There's some history that you've missed. Anyways I personally introduced that in JAB 2018: https://www.youtube.com/watch?v=Hg_ATQEl9_U but that CANNOT replace BS in the J4.0. That decision was to be made 3 years ago and the PHP people decided to go with the BS.

@Hackwar @Bakual Obviously you're also missing one huge thing that is happening at the moment in the Bootstrap repo and that is changing all the scss vars to CSS vars (eg twbs/bootstrap#34622). That was the reason that J4 didn't ship with the latest BS (version 5.1 atm). Also these changes are not B/C for both the Joomla supplied templates. The point is that once they transition all the scss vars to css vars there is no reason to recompile from the source, you just change the css vars (even in the browser) and voila.

To make my point more clear:

By the time Joomla 4.1 will be released, BS will be using CSS Variables and there won't be any need for a SCSS compiler.

You're sure you actually did an RFC for it? I only found two references in a comment of another issue. But no real discussion around it. First one I found was #31091 (comment)

@Bakual You didn't search in the right places. The issue of the SCSS compiler is quite old

Starts here (2016): joomla/40-backend-template#92 and it spans many different repos/communication channels/etc. I really can't be bothered to search all that atm. But for what it is worth the same SCSS compiler was rejected from @wilsonge @mbabker and any other respectable PHP dev/maintainer of this project. I have no clue why this is resurrected and advertised as a viable solution...

By the time Joomla 4.1 will be released, BS will be using CSS Variables and there won't be any need for a SCSS compiler.

but not every template will use bootstrap ;)

but not every template will use bootstrap ;)

sure and as far as I understood the project stance was to not provide any (less/scss/postcss/css in js… the list goes on) compiler and leave that to the theme editors to do whatever they want…

i was making a cheap shot

If we had been at the beginning of 2020, I would agree that the compiler is abandonware and not spec compliant (enough) to be considered. However the developers have been quite active since then and a re-evaluation seems reasonable.

@Hackwar sure the known compliance issues are only 18 (sarcasm): https://github.com/scssphp/scssphp/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22spec+compliance%22

But also you have to consider the performance and all round crap code in that repo...

My question though is different WHY the project should provide a SCSS compiler (php) when:

• The official is the Dart one?
• SCSS has an expire date (and a rather short one): https://drafts.csswg.org/css-nesting-1/ , https://www.bram.us/2019/03/17/the-future-of-css-nesting-selectors/
• Bootstrap shortly will not need recompilation due to CSS vars

I don't share your opinion on these things.

• Yes, the official compiler is the Dart one, but using it in our context will at least generate an enormous amount of overhead.
• I also don't see the expire date for SCSS. I think it does have a usefull purpose for quite a few years to come. At least long enough for us to still adopt it now.
• Bootstrap might not need recompilation, but I see hundreds of templates which want to compile their CSS, regardless of Bootstrap or not and quite simply I want extension developers to be able to provide their CSS as SCSS files and a chance of being able to disable their by default included styles. For that, we have to provide them the right tools.
• Regardless of what future technology might bring us, we do have a very large legacy base. Existing sites and extensions are already using SCSS and would benefit from a better support from us. These wont change their code to the "latest" technology everytime. Besides that, we do have lots of developers who will not use the latest tools available even when writing new stuff.

As I said, there are good reasons for using this. There are also reasons against it, as you yourself listed. Now the question is which ones weigh more. I'm waiting for a decision by the release lead, @bembelimen ?

@Hackwar Do whatever you want, Bye. -

if your proposed tool actually worked you would have a stronger argument.

if your proposed tool actually worked you would have a stronger argument.

Brian you are referring to this php thing right? Because just with this compiler you can’t possibly get the same results even for the basic bootstrap (it needs also postcss with autoprefix and rtlcss plugins). I’m also wondering why people don’t understand that this is NOT possible in plain php world…

I see the benefit to be able to compile scss files on the Joomla server and it would probably be useful atm. On long term Sass will not be needed when (nested CSS)[https://drafts.csswg.org/css-nesting-1] will arrive on browsers. Adding a dependency to core where we see already it will be obsolete on some point should be avoided.
If a template needs such a compiler in PHP then they can ship it by themselves, but not in core.

@dgrammatiko

if your proposed tool actually worked you would have a stronger argument.

Brian you are referring to this php thing right?

Yes I was referring to the tool proposed by hannes. As of right now it is nowhere near usable (based on their published known issues)

SCSS is not just about being able to nest. It has the ability to perform lots of other logic which isn't possible without PostCSS plugins (assuming they exist).
Bootstrap won't be migrating over to PostCSS until v6 or v7, so the idea of this PR is correct, but the implementation isn't.

@dgrammatiko is also correct in the fact it's missing both the autoprefixer. It's also missing the minification step.

If you want a SCSS compiler, it's going to have top be done via Javascript, but properly, as the file will be rather big.

The only other approach I can think of is Joomla spins up an official Node.js server (e.g scss-compile.joomla.org), using the same build scripts as this repo (with an API), which is used to compile SCSS and return the CSS.

It's been 5 months and SCSSPHP has released several new versions. I compiled our frontend templates SCSS with the compiler and except for the autoprefixer and 2 glitches I found, the results are identical. If you can get our SCSS to actually compile the way it is shipped to our users. (#36872)

Yes, this compiler is not perfect, but they are making good progress and with a warning before the compile step that this might not be 100% standards compliant, it would still be a big help for lots of users. So I've rebased the branch against 4.2-dev and I'm asking @roland-d and @fancyFranci if they consider this contribution acceptable.

Can the PT please close this. A PHP SCSS compiler will never work as expected, if you want to compile SCSS then you have to do it in the browser using some WASM (eg https://github.com/dgrammatiko/scss-wasm-compile or https://github.com/dgrammatiko/sass-worker or any other such solution)

@Hackwar Since you asked if this can be included in 4.2.0 I am going to say that this will not be included due to the feedback given here. If you know how to write SCSS you most likely know how to compile it and not need Joomla as a subpar SCSS compiler.

Fair enough. Closing.