PHP equivalent of "modern" sass/less

sass-less.php

<?php 
// index.php
/* We assume that a designer will ask us one day to increase/decrease all body texts
    this website was made in 2010 and we're changing platform now but "sure" this is
    going to happen soon :D "In the next project" :-d
   Also Search & replace '1em' is very trixy, cannot be done reaaallly! IMPOSSIBLE!
*/
$GLOBALS['fontSizeDefault'] = '1em';
class MixinC { // ... }
class MixinB extends MixinC { // ... }
class MixinA extends MixinB { // ... }

// controller/routeX.php
$GLOBALS['fontSizeDefaultCurrent'] = $GLOBALS['fontSizeDefault'];

// Component.php
$GLOBALS['fontSizeDefaultCurrentPage'] = $GLOBALS['fontSizeDefaultCurrent'];

class Component extends MixinA
{
    public $fontSize = $GLOBALS['fontSizeDefaultCurrentPage'];
    
    public __construct() {
        // damn... designer wanted different for this component
        // lets undo all these cool useful mixins and variables
        $this->fontSize = '1.2em'; 
    }
}

Code may not compile but that is not the point here, it's to display how crazy most sass/lessCsss setups are in most projects these days. It would never be written like this in BE but we do it for FE development...

🤔

🤔

I am not against SASS+LessCSS per se it's just that it opens up for the possibility of making a really terrible styling structure which would be impossible to make using just regular CSS.

Examples:

Magento 2's theming:

All BE+FE functionalities are broken down into php/magento modules responsible for their own styling. Almost each css attribute comes from either a variable and/or mixing
Some modules override other modules variables
Then comes the theme module which has first defaults values that override the module variable values and then the theme components which can override the them defaults and so on..
Mixins that take defaults from other mixins

It boils down to finding where 1 css property came from initially you might have to open 20 different files and do an "investigation" to work out which variable you are supposed to change in your custom theme "to do it the proper magento way".

When M2 came out and the company I worked at that time switched to it, we almost went out of business because we were dead set on "doing it the proper magento way" and all FE devs were just spending all their days to finding the correct variables to set in a huge file tree.

"Misstaken incredible nesting"

Below "looks" fine maybe to an untrained eye. But the actual generated CSS?? You might have more stuff inside all the parent selectors also. It grows exponentially with the parent selectors. The child selectors might be a mixin also so it's even less visible in the SCSS code!

.component-abc,
.component-y1x,
.component-y1,
.component-x2,
.component-x1,
.component-x,
.component-y,
.component-z {
    .div {
        form {
            h1 {
                font-size: 20px
            }
            h2 {
                font-size: 20px
            }                
            input {
                font-size: 12px;
            }
            .hr {
                border-bottom: 1px solid;
            }
            .button {
                font-size: 12px;
                
                span {
                    font-size: 10px;
                }
            }
        }
    }
}

Look at the size of this generated CSS:

.component-abc .div form h1,
.component-y1x .div form h1,
.component-y1 .div form h1,
.component-x2 .div form h1,
.component-x1 .div form h1,
.component-x .div form h1,
.component-y .div form h1,
.component-z .div form h1 {
    font-size: 20px;
}
.component-abc .div form h2,
.component-y1x .div form h2,
.component-y1 .div form h2,
.component-x2 .div form h2,
.component-x1 .div form h2,
.component-x .div form h2,
.component-y .div form h2,
.component-z .div form h2 {
    font-size: 20px;
}
.component-abc .div form input,
.component-y1x .div form input,
.component-y1 .div form input,
.component-x2 .div form input,
.component-x1 .div form input,
.component-x .div form input,
.component-y .div form input,
.component-z .div form input {
    font-size: 12px;
}
.component-abc .div form .hr,
.component-y1x .div form .hr,
.component-y1 .div form .hr,
.component-x2 .div form .hr,
.component-x1 .div form .hr,
.component-x .div form .hr,
.component-y .div form .hr,
.component-z .div form .hr {
    border-bottom: 1px solid;
}
.component-abc .div form .button,
.component-y1x .div form .button,
.component-y1 .div form .button,
.component-x2 .div form .button,
.component-x1 .div form .button,
.component-x .div form .button,
.component-y .div form .button,
.component-z .div form .button {
    font-size: 12px;
}
.component-abc .div form .button span,
.component-y1x .div form .button span,
.component-y1 .div form .button span,
.component-x2 .div form .button span,
.component-x1 .div form .button span,
.component-x .div form .button span,
.component-y .div form .button span,
.component-z .div form .button span {
    font-size: 10px;
}

Yes, one should never do that. But you can produce bad code with any language. I think both Sass and Less warn in documentation to be careful with deep nesting (or they should).