Others answers are really good, putting words on the method/sense I learned after years of trying and failings. I have tried so many tools but one that helped me a lot was colors.co . Really great to practice and understand HSL (hue - saturation - lightness), which is for me the easiest way of making palettes. Also, in most cases in web design, a good group of light colors or dark colors is one of the most important thing. So there's one things I like to do: take one primary color (main - bright) and learn to "derive" or to create shades of light colors from that main color. Ex: one bright blue and 3 light grays with a tiny bit of blue in them.

I developed a component framework agnostic and the sumfony bundle that goes with it for proper theming in symfony by subdomain. It handles twigs, images, css, JavaScript, 404... each theme has configuration too, to extend the app or services, liip filters... I would love to open source it but that’s an ongoing debate at my work ahah.

How come 90% of the poll is for Laravel and all the replies/comments advocate for Symfony ? 👹 What kills it for me about Laravel is some design choices such as static and tight coupling which makes it way harder to work with. Twig over Blade too, for the community/spread. One possible reason maybe: Laravel is very popular in the US (which seems to be the major audience of hash node) but from what I’ve seen has less traction in Europe and especially France 🇫🇷.

Amen on all that: static context and tight coupling would have made my work wayyy harder if not impossible... replacing many implementations of core service with my own (theming aware) ones.

I assume your talking about spacing within a component, eg. the space between a title and a text, etc. I had the same dilemma. // Sizing. @mixin card-sizing($card-spacer-x, $card-spacer-y) { .card-title, .card-separator, .card-subtitle, .card-text, .card-element { margin-top: 0 ; margin-bottom: $card-spacer-y; } .card-subtitle { margin-top: -($card-spacer-y / 2 ); } .card-block { // I feel like this should not be there. padding: $card-spacer-y $card-spacer-x; } } .card { @ include card-huer($card-background, $card-text-color, ...); } // Default sizing. @ include card-sizing($card-spacer-x, $card-spacer-y); I designed this card components a while ago as a "one purpose - one look" component.. which was a mistake. I have a lot of themes to support with very different styles and each of them have their own requirements and look and feel. At first, it bothered me a lot. Another mistake that I've done was trying to handle every possibility in the whole universe , even the most crazy one with the same monolithic stack of lines... It's good to think and anticipate some needs but I spent wayyy too much time doing that. I ended up creating variants, with --modifier ; kind of BEM-style. .card--vstream { @ include card-huer($card-vstream-background, $card-vstream-color...); @ include card-sizing($card-vstream-spacer-x, $card-vstream-spacer-y); } .card--event { @ include card-huer($card-event-background, $card-event-color...); @ include card-sizing($card-event-spacer-x, $card-event-spacer-y); } // etc. I try to follow the ITCSS rules so I have: tools/cards.scss with the mixins settings/cards.scss with the (too?) many variables that you'll end up with 🙃 components/cards/cards.scss with the component itself and the default variant. components/cards/variants.scss with well, all the variants (and I've got a lot, so this one will probably will be split in many files. Outer-space now! To handle space between my cards, I don't style them directly but embed them in another component named .gallery which can be a list, a grid, a scrolling list, etc. This component sole purpose is to handle scaffolding and spacing, not the card itself. < div class = "gallery gallery--vstream" > < div class = "gallery-item" > < div class = "card card--vstream" > <!-- and so on --> </ div > </ div > </ div > Does anyone have another way to deal with it? 🤐

I've tested it for half a day and it triggered me so much I had to stopped... I really wanted to like it. Get away a bit from Google, promote the open-source and all. Maybe next time. My local project takes 900ms (with all dev profiling included on Chrome) but loads in not less than 4.5s on Firefox 57. Additionally, I get 137% of CPU usage with 3 tabs. Just unusable for working. 😔 I hope it's just a bug that will be fixed. I'll try again in a few weeks. 🙌

The folks at symfony have built some wrapper/builder for webpack that I find really cool for starting with it. It abstracts a lot of the fuss of webpack that can be scaring at first. https://symfony.com/doc/current/frontend/encore/simple-example.html And you still can add your things if the wrapper is not enough! const Encore = require ( '@symfony/webpack-encore' ); Encore .setOutputPath( 'web/dist/' ) // ... ; var config = Encore.getWebpackConfig(); // Do more stuff. module .exports = config;

Thanks for the detailed input ! Yup, the performance side-note was, well, just a side note. No need to be triggered by that 😬. My point was semantic vs. style. I think I wasn't clear: it's okay to use attributes as part of styling (data-* attributes or type attributes for form fields for example), what's weird is to use data attributes for the sole purpose of styling a component. That's what classes are the best. Like you said, classes have advantages such as having multiple classes (useful for states) and cascading. You just seem to be 100% for using data-attributes, so go for it! ☺️ I don't get the whole BEM argument. I'm not a fan either but was the question only about it and I missed the whole point?

I like to listen to the weekly Danger Mouse playlist; Danger Mouse Jukebox

Based on the name of the thing "data attributes", I'm not sure it's good idea to use data to style things. Those html5 data-* attributes are semantic attributes that meant to describe your data within the html and designed to be read and written by javascript (mainly). Note that they are also much slower to be accessed using css selectors than ids or classes. Although, if it implies a modification on too much places (if you're maintaining 50 themes), the solution to use a data attribute could be ok as a quick fix . I'll still try to find a parent html element with any class / id and match that instead: #parent form {} .parent-div form {} All that to give you time to add a class on your form in all the places it appears without pressure.