Is there a direct argument why inline CSS is bad? I keep hearing "it's hard to change" but if you replace style="margin: 25px" with class="margin-20" then changing that everywhere to margin-25 is exactly as hard, and changing margin-20 to mean margin: 25px is much worse.

Every dev knows deep down that their code quality best practices are thumb rules derived in a specific context from some hard to define universal attributes of good code, and at a bit of pressure they are willing to open a discussion about the best practices. The undesirability of inline CSS is one of very few rules that are enshrined as unquestionable, and attempting to discuss them evokes hostility.

well, if you call it "margin-20", then you're just stupid. that's like replacing the number 20 in programming with a `const num20 = 20`.

give it a _meaningful_ name. like "margin-medium".

inline-css is bad for two reasons: one: it forces you to use magic numbers, instead of giving you the option of not being stupid. and two: when you want to change the value, you need to change it in every location, instead of just the definition.

Wait, does anyone care about frontend code quality anyway?

Inline CSS is kinda bad.

Things like tailwind, BEM,... are even worst.

The best? CSS-in-js. Just apply things per components

@antigermanist I have opinions too, so do my coworkers. I was asking for arguments.

@Tounai no such thing as frontend code quality, anyway ;)

@antigermanist i'd argue that no CSS should be applied via a script. that's contrary to how it all should work in the first place. the layout should remain at least semi-functional without any script active

the main argument is maintainability. if you have logical functional css classes, which define the style of a specific class of elements instead of just some specific parameter, then it will be much more maintainable and able to change if needed, instead of hunting each inline style application and changing that

also style consistency is much easier to achieve if you apply the same class to elements instead of ad-hocking every element

@iiii Right, but that's not a direct argument against inline styles, it's a much more advanced strategy that is better than inline styles. Absent such a strategy, I'm still not convinced that inline styles are worse than classes that are either designed to fit a single element or a single style rule, and thus can't be changed without arbitrary breakage (and rendering their name meaningless).

Yeah what @iiii said. It's like asking why you should use variables instead of hardcoded values everywhere

@BordedDev no really, why should I use a variable? Sure it allows me to name the value, but it also forces me to take it out of its context within the expression. Maybe I can't give a value a meaningful name, because it derives its value from other values within the same expression. It's the same reason why lambdas are so popular; sometimes a value has no meaningful name besides what's obvious from its relation to other values in the expression. Often the combined benefit of shorter code and the value being visible in context is more useful than whatever limited benefit a name could provide. Styles are also subject to layout math where the only way to deal with them is to visually verify that the layout is still correct and tweak the numbers as necessary. In these cases having all the numbers at hand exactly where the HTML is can be a huge benefit.

@BordedDev And CSS classes have a lot of additional limitations over variables, for example, they're global and can't compose. Want to change all 20px margins to 25? Turns out grepping for margin-20 is incorrect because whenever it was going to be applied to an element that also had a more specific class, margin: 20px was just added to that class too. So either way the only correct way to enumerate all occurrences of something you want to change is to search for the style command in both CSS and HTML.

CSS is far more limited in terms of organization than TC languages, even C, so extending code quality intuition to it isn't always a good idea. In code it is _usually_ a good idea to define a variable for magic values because then you can use that variable in the definition of other variables that logically depend on that value, and now there's a lot less repetition. You can't do this with CSS classes.

@iiii if you don't need JS you don't need a layout

@antigermanist how are layout and client-side interactivity even remotely connected problems within the realm of web-development?

everybody is insane and if it works then it works

I believe they had a term for it. bike shedding. just shut up and build the thing

that's my opinion. I actually built things and I find such people so annoying -- such people then bitched at me that my time estimates were too low later on 😩, but do you ever get told you were right all along? nope!

and even if it had some merit to it, the ecosystem being full of these opinionated useless ideas does not help anyone figure out what's a myth vs what actually has meaning. so either case I'm left trying it my way and running it and benchmarking it for months. you guys caused this nonsense. just saying

I also hate documentation for the same reason. just read the code. you should be fluent in programming languages

@lorentz if you attach css to components they can be statically rendered if you dont have js.

@lorentz That's incorrect, css doesn't have to be global. @scope exists.

As mentioned, margin-20 is a terrible class because it's the same as calling a variable `pixel20`.

They can compose, what do you mean? margin-big and padding-big can be added to the same element. I'm going to assume you mean someone doing margin-big and margin-small? Well the rule is simple for this, whichever css class is defined last.

And if you want to change the margin on elements that are relevant to a specific section of the page requires a lot of manual tweaking if it's all in the same html (or multiple files!) since you might not want to change the headers margin for example.

Personally I'd never go for a margin-X style class anyway. Describe what the style is used for, e.g. navigation, and nest them as you need them (yes CSS supports nesting)

Not sure where the lambda comparison comes from. There is a large difference between markup and imperative code

@lorentz

In code it is _usually_ a good idea to define a variable for magic values because then you can use that variable in the definition of other variables that logically depend on that value

You can do that with CSS classes using CSS variables, also the math functions

Classes also make it easier for you to do fancy state transitions without having to set a large set of properties through code, e.g. fading an element out, sliding it into view or 3d rotations without making the HTML hard to read/manually setting them through JS

@BordedDev Yeah and those CSS variables can then be used in inline styles. CSS variables have nothing to do with this conversation (just like JS doesn't have anything to do with it). CSS CLASSES can't be composed into higher structures, let alone into more specific classes. They can be combined in use, but all of them have to be listed individually, any kind of structure between them cannot be expressed in the code. Therefore separating styles from the HTML is meaningless unless the specific class that you choose to define represents something more general than both the style(s) it applies and the element(s) it is applied to, and its styles are also never involved in layout math, which is a manually upheld invariant that would be obscured by abstraction.

@lorentz yeah, if a class is just a placeholder to one parameter with a specific value, it's pretty much the same bad thing and is in no way better

@antigermanist wrong. You can have a fully functional html+css page with zero jubascript

@lorentz In what insane world is 1 style 1 class a good idea, it's also one of the reasons I hate tailwind and similar inline style alias frameworks. Use the CSS class to express a concept, just like you'd name a function in normal code

> CLASSES can't be composed into higher structures, let alone into more specific classes

What about nested styles? Pseudo-classes? Sibling selectors? None of those can be expressed using inline styles.

Yes, this is valid.

.nav {

.nav-item {

...

}

}

or you can "compose" your style by doing

.example {

background: green;

}

.error .example {

background: red;

}

Are you upset that the CSS won't ctrl-c ctrl- v the styles to different classes? Something you definitely can't do with inline styles, so that's a big non sequitur... Actually that is what CSS class resolves for you...

@BordedDev Those features are tangential to composition, though I also hate clever selector magic for unrelated reasons. My programming language "ctrl+c,ctrl+v-s" logic when I call a function inside another, properties when I use a struct as a field type, values when I use a variable in an expression. It's normal. It's standard. It has a billion use cases, including less magical and more predictable alternatives to clever selector magic. CSS classes are less for not having this feature.

@BordedDev Tailwind looks silly but it actually fixes this problem by abstracting away CSS classes. You're not generally meant to think about the classes in tailwind, 99% of the logic is done in variables or macros. You only use manually defined classes as the last layer of abstraction, and only these classes have to be maintained by you so only their structure matters. It's also sidestepping the stigma around inline styles, because it's better in exactly the situations where inline styles are better, but it's popular because it doesn't look like inline styles.

@lorentz You just disproved your first response with your second response. How do you think tailwind does "fancy" stuff, it does selector """magic""" and has the exact same issues as inline styles in fact, often it even makes it worse

The main argument should be specificity. Inline CSS overrides everything unless it's boosted using `!important` - unless the inline CSS is already boosted with `!important` as well.

@BordedDev It doesn't though; Tailwind parses everything and generates rules with very simple selectors keyed by the very specific class-names you write. Any magic is either compile time or via CSS variables, and any connections are explicitly referenced on at least one end.

@BordedDev Nobody does anything with selector magic in libraries because it's absurdly sensitive to the infinitely composable element tree of HTML, in addition to being a pain in the ass to read and write on the CSS side. Also all library-provided classes are prefixed with the library name like we're in the 80s to make up for CSS' lack of namespacing.

@lorentz Except it very much does, it's not optional. Have you looked at the hover, focus and other classes?

Also, every library uses selector magic because, again, it's not optional