-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
I know efforts are already set in motion to make the Magento 2 frontend sass compatible, but wanted to mention this. Hope it doesn't turn out to be just less2sass _variables.less _variables.scss.
After the browser implementation of CSS3 in browsers the css-preprocessors started to arise Less, Sass, Stylus and what have you. The preprocessors serve a great purpose to extend the css language to support more features, but now the W3C is starting to catch up to make standards for the most commonly used features in the css preprocessors.
CSSNext implements a lot of these features so they can already be used today. in combination with autoprefixer CSSNext can decide whether to rewrite features for specific browsers. For example, you don't have to compile the css variables on Google Chrome latest during development, making the compilation process very fast.
Even besides this, the whole postcss is gaining traction. A lot of plugins are available which make the whole development experience a 1000 times better. For example: The grid system in Magento 2 is limited and custom implemented, doesn't support complex grids and aren't easy to use. A postcss implementation for this is https://github.com/peterramsing/lost which is better in every way.
But in general this means Magento 2 has to abandon some things.
- PHP-compilation of the source files has to go.
- Browser-compilation of the source files has to go.
- Grunt needed to go 3 years ago, do we even need to discuss this? 😉
-
var\view_preprocessedneeds to go, all.less(or other uncompiled files) need to go under the static folder. A better solution would be:- a. Generate of a file that
@importall.lessfiles all over the system. It has never been an obstacle to have a path like../../bootstrap/default/less/lib/popup.lessin a specific theme. - b. I even believe specific plugins for sass/less/postcss can be written to solve the import path resolution problem
- a. Generate of a file that
- Stop using words like
lib-,_extends, no sh*t something is a library or we need to extend something. -
.lib-css.. Needs to go asap.autoprefixeris here for you. It isn't 2012 anymore that we want to have vendor prefixes in our frontend files 😉 - Non semantic color variables.. We don't need 45 different variables for the color gray. Just use the color if you want a certain color. Shades of colors need to be implemented as that, not as a fixed color variable. it is fine to have variables like
@color__hotpink-shinybut you can never use them directly in components, they have to be assigned to their sempantic elements@link__color: @color__hotpink-shiny - Variables files do not cascade. We are buiding our own library which defines some more sensisble default in the
_variables.lessfiles, but right now I can't easily implement the parent_variables.lessfile. - Not everything needs to be a variable.. Introducing 3 variables instead of
border: 1px solid hotpinkis an anti-pattern. If people want to implement a theme they are free to do so, but it shouldn't clutter the library. Bootstrap got around this problem by introducing atheme.lesswhich introduced a lot of gradients etc (now out of fashion style wise, but they had the right idea). - @media-common and @media-target are used in combination with some guard expressions, but it seems to me that it would be easier to implement a
_module.lessand_module_lg.less - The theme doesn't use
box-sizing: border-box(ref)[http://www.paulirish.com/2012/box-sizing-border-box-ftw/] - Each mixin (lib folder) should be in their separate file if we want to extend the working of the mixins