I’ve been opposed to our team using any kind of build system for our #Wordpress theme work. Wherever possible, we write code and that code “ships” as written. My one exception is WP SCSS, a Wordpress plugin for compiling SCSS to #CSS on the server side. It has options for compression level and mapping, etc. and even conditional compiles to only regenerate styles when the #SCSS directory has been modified.
Extremely unimpressed with the ways in which Sass integrations seem like a complete afterthought in 2024. Sass is a beautiful, powerful language, made and maintained by smart, caring people. It’s really sad to see it done dirty like this. #Sass#SCSS#WebDevelopment
Post >> Variations on styling variables in SSGs • The CSS-or-Sass question about styling variables is a lot simpler to answer when you’re building your site the right way.
Dans les sujets dont je devrais logiquement pas mal parler par ici, il y'a le #développement#informatique. C'est une passion pour moi depuis l'enfance, et j'ai la chance de pouvoir enfin l'exercer professionnellement depuis un peu plus d'un an, dans le service public (à l'Insee pour être précis). Côté technos, je bosse en full stack sur une appli web avec #Java et #Spring côté back, #SCSS, #VanillaJS et #React côté front. Sur mes projets persos et dans les cours que je donne, c'est #Python 🤓
It's been on my mind that with all the new features of #CSS it might be time to migrate away from #SCSS.
Problem is I'd like to implement the changes as I go. Historically CSS has worked as a subset but with nesting those rules are broken – https://sass-lang.com/blog/sass-and-native-nesting/ – which means migrating away from SCSS is now an all-or-nothing proposition.
Has enyone else done this? What are some solutions? I've been looking at https://lightningcss.dev/ as a potential build replacement
We've had an internal linter for years, which is built on a PHP #symphony framework.
You run the linter you want and append --fix if you want it to resolve issues (if it can)
It lints things like #JS, #SCSS as well as #PHP (via #Rector and #phpstan), #Composer files and even #TYPO3 TypoScript files - all by using the open source libraries available.
It means all our developers can adhere to central linting conventions without having to update local config files.
i'm updating a #drupal 8 site to 10 and tumbling through some of the changes in #css#scss#sass class conventions, maybe due to the outdated #radix theme? where underscores are now hyphens and various <div> have appeared and disappeared 😬
is there a standard/programmatic way to update the classes at least? 🤔
Is there a support group for folks that say they will separate and structure their SASS/SCSS properly, but then just end up writing it all into one file?
I'm trying to once again meaningfully unify how I abstract code in #SCSS and Cascade Layers in #css
Consider a scss library that has lots of folders and barrel files, components/_index.scss. Each component may be its own (nested) layer, but I cannot export them into a single, unified components layer, because I cannot put @layer before @forward/@use.
I could have something like $layer1: 'components' !default; $layer2: 'button' !default and then @forward with(...) it, but that's nasty