Skip to content

Instantly share code, notes, and snippets.

@OZZlE
Last active January 15, 2021 18:20
Show Gist options
  • Save OZZlE/f635bbff3ab15b4d433c9c0310956957 to your computer and use it in GitHub Desktop.
Save OZZlE/f635bbff3ab15b4d433c9c0310956957 to your computer and use it in GitHub Desktop.
PHP equivalent of "modern" sass/less
<?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';
}
}
@OZZlE
Copy link
Author

OZZlE commented Oct 27, 2020

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...

@matthew-dean
Copy link

🤔

@OZZlE
Copy link
Author

OZZlE commented Jan 15, 2021

🤔

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;
}

@matthew-dean
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment