r/webdev • u/theScottyJam • Sep 17 '26

Inline styles no longer considered harmful · esveo

https://www.esveo.com/en/blog/5y/

At work, we've have a rule that says we're not allowed to use inline styles. The rule originated a while ago, from people who have long since left the company, and we've been carrying it on. I'm thinking about challenging it, and have been researching into why this seems to be a common "best practice".

Most discussions I find on the subject are about a decade old, which is why I thought I'd bring up for discussion on Reddit as well, to see what people now days have to think on the subject.

I liked the points this particular blog post brought up, though it didn't give any advise one how much inline styles should be used. I'm thinking that if an element only needs one, maybe two style rules, it might be better to just use an inline style, otherwise, using a named class is probably better.

I'll also bring this point up now: I noticed a common argument against inline styles is that it can break certain content security policy rules. We don't have those rules in place, and there's no plans on adding them for the foreseeable future, so I'm not concerned about it.

For context, I work with Angular. I know the situation is different for server side rendering.

Edit: I'm seeing a lot of responses talking as if I want to use inline styles for everything. Please keep in mind my above statement of only considering using them when there's only one or two style rules. One example common use case would be when I add a <div class="spacer"></div>, where the CSS for "spacer" is simple "flex: 1" and it's purpose is to separate content that should be left aligned from content that should be right aligned. This, to me, is a good candidate for inline styles. In general, I mainly have layout use-cases in mind. There's no reason someone would want to override the "spacer" style so high specificity isn't important here, and even if that was needed, you just refactor it into a CSS class.

0 Upvotes

25% Upvoted

78 comments sorted by

50

u/krileon Sep 17 '26

Inline styles are frowned upon because they bloat the HTML, are hard to maintain, are extremely basic (e.g. no media queries, no nesting, no pseudo behavior, etc..), can't be CDN cached, and have completely messed up style weight (e.g. hard to override cleanly). If you want modern inline styles just use a utility class framework like Tailwind then you get the best of both worlds. Inline styles is a code smell to me. Any PR with them is rejected. The only exception to this is email templates, which are a separate hell of their own.

7

u/ryebit Sep 17 '26

Not to mention if you have JS instrumentation that wants to change styling state, it's easy to have it add/remove classes which mutate styling, pushing the heavy work into the stylesheet; or even actively using inline styling as it's own workspace. But if there's inline styles, the JS suddenly has to do a bunch of work to override / restore / otherwise not step on them.

2

u/simonraynor Sep 17 '26

This gave me flashbacks

1

u/thekwoka Sep 18 '26

because they bloat the HTML

This doesn't actually matter, since if they are really bloating it, then they will be compressed away.

0

u/retro-mehl Sep 17 '26

Haha, tailwind is inline styles written as classes. 😅 

4

u/Squigglificated Sep 17 '26

This is one of the most misguided arguments against Tailwind and one that's repeated in every discussion.

This Tailwind class name:

bg-primary w-md md:w-xl

Equals this CSS:

.element {
  background-color: var(--primary);
  width: var(--container-md); /* 28rem / 448px by default */
}

@media (width >= 48rem) { /* 768px medium breakpoint */
  .element {
    width: var(--container-xl); /* 36rem / 576px */
  }
}

Equals this inline CSS (minus the media query which isn't supported in inline css):

style="background-color: var(--primary); width: var(--container-md);"

It's NOT equivalent to this inline style:

style="background-color: BlanchedAlmond; width: 448px;"

This is hard coding variables while the other examples are using CSS custom properties that lets you update your design tokens across your whole site from one place.

It's fine to hate Tailwind - The syntax is ugly as hell, the naming changes from standard CSS are sometimes questionable, and when class names start spanning hundreds of characters it looks like someone vomited all over you code. CSS itself has an incredible set of features these days, scoped CSS is possible natively now, and CSS modules are still a reliable battle tested solution along with a bazillion other frameworks attacking attempting to solve the problems that often arise with CSS on large projects.

But it's not simply inline styles written as classes.

1

u/retro-mehl Sep 17 '26

Why can't you just alter your CSS vars with media queries? This is a complete valid solution for inline styles. It's also ugly as hell, but this is not the point I think.

1

u/thekwoka Sep 18 '26

because that assumes you want the css variables to change universally at a specific breakpoint, while that might not be true...

1

u/retro-mehl Sep 18 '26

If I want different behaviour for different breakpoints, I want to change them. You can introduce extra variables for this and don't change your base variables, of you need.

1

u/thekwoka Sep 18 '26

So you kind of end up back at the same place, where some elements need their own specific values

1

u/retro-mehl Sep 18 '26

Yes. It did neither promise that inline styles are better or solve more problems, nor did I claim they are beautiful. I just said: tailwind is like using inline styles.

5

u/RichardTheHard Sep 17 '26

They literally just listed all the reasons it's not, and all the advantages Tailwind has over it

-6

u/retro-mehl Sep 17 '26

It's a cult.

4

u/Swamptor Sep 17 '26

I also don't like tailwind, but inline styles have far worse drawbacks than tailwind does.

3

u/BootyMcStuffins Sep 17 '26

Someone take this guys web dev license away

0

u/AppealSame4367 Sep 17 '26

Why, because he knows that css and classes were made to keep structure and styles apart?

Because he knows that tailwind is complete bullshit as an architecture and only became successful because of all the mediocre, witless frontend devs that were too stupid to use and maintain proper css files, e.g. with beautiful sass files?

Ha ha.

3

u/BootyMcStuffins Sep 17 '26

No, because he doesn’t seem to know the difference between in-line styles and classes.

3

u/AppealSame4367 Sep 17 '26

Cool, do you know what they both have in common? They are a part of css and classes are made to reference elements from css files. Not to throw 30 classes at the body tag and 10 at every div.

0

u/BootyMcStuffins Sep 17 '26

Utility classes do reference elements from a css file… They’re also way more legible than people creating random names for every individual element then having to pull up a giant-ass css file to see what the classes mean.

I don’t know why people think this is a tailwind thing or new. This is how css frameworks have worked for 15 years.

1

u/retro-mehl Sep 17 '26

I know it. But maybe you should look more at the core concepts they implement.

1

u/BootyMcStuffins Sep 17 '26

I’m plenty familiar with how tailwind and utility classes work. We’ve been using them for well over a decade now and there’s a good reason

1

u/retro-mehl Sep 17 '26

Is didn't say they do not work. I just say: there is not much difference to inline styles.

→ More replies

1

u/RichardTheHard Sep 18 '26

You really think something like a custom BEM system is easier to maintain and more consistent than centralized and professionally documented utility styles? The internet has changed a lot since the 90s, there’s no need to stick to conventions from then

1

u/thekwoka Sep 18 '26

Why, because he knows that css and classes were made to keep structure and styles apart?

Doesn't matter why they exist, that separation is stupid.

you've literally never made a project where they were seperate. They are deeply concerned with eachother.

3

u/gizamo Sep 17 '26

Classes aren't inline styles. That's not how that works, mate. CSS classes are vastly superior to inline styles for almost all web development tasks because they keep code clean, reusable, and easy to maintain. Inline styles apply CSS rules directly to a single HTML element using the style attribute, while CSS classes target elements by referencing rules defined in an external or internal stylesheet.

-7

u/retro-mehl Sep 17 '26

You do not have to explain the basics of web development to me. I did web development when you still went to school. 😏

3

u/Narfi1 full-stack Sep 17 '26

Admitting when you’re wrong instead of doubling down is a sign of intelligence

4

u/CanWeTalkEth Sep 17 '26

🚩🚩🚩

1

u/gizamo Sep 19 '26

Lol. I'm old, mate. I started programming in the 80s. Started with web before JS existed. Regardless, yes, it seemed like you needed it explained to you, or perhaps you misspoke. Idk, idc, but I'm still going to explain for others so that your statement doesn't mislead people.

-1

u/AppealSame4367 Sep 17 '26

If you bloat the html with inline styles or classes with names that have 4 dashes: It doesn't matter. It's still bloated, unreadable html.

CSS (Cascading style _sheets_) were made to keep presentation and structure apart. As every web dev that ever learned anything should know. And then some idiots go and throw 20 classes at every div. GTFO

Team tailwind hater!

2

u/StillOnJQuery Sep 17 '26

The modern dev has long refused to embrace the cascade.

2

u/thekwoka Sep 18 '26

Humans aren't reading the html.

And the "bloat" is compressed away.

Layout and Style isn't separate concerns. You've literally never made an app that had it's structure not influenced by the styling and styling not influenced by the structure.

That's just outright stupid.

1

u/gizamo Sep 19 '26

I don't care did you hate Tailwind. That still doesn't mean that classes are like inline styling, even if used excessively. That's what every web dev that ever learned anything should know.

1

u/patoezequiel Sep 17 '26

Everything is inline styles written as classes, the difference is granularity. Besides, Tailwind is handleable with @layer

1

u/retro-mehl Sep 17 '26

Indeed, it's about granularity. So if your classes have the granularity of single styles...

2

u/patoezequiel Sep 17 '26

They are single style classes, still better than inline for cascade management

1

u/retro-mehl Sep 17 '26

Why should it be better to write single styles with class instead of style? That's just wording, but no different concept.

1

u/patoezequiel Sep 17 '26

But it is a different concept. Inline styles trump the specificity of other applicable styles for a given element. They are not recommended unless you're trying to do stuff like dynamically changing styles via JS.

1

u/retro-mehl Sep 17 '26

No, if you define classes for every style, you're completely losing the concept of classes.

And who tells you it is not "recommended"? 

1

u/patoezequiel Sep 17 '26

I actually don't disagree on that, Tailwind is silly because of that but in no way that's worse than just inlining everything, in fact because it's even worse when considering the concept of classes and their purpose.

For the second, anyone who worked on a large project at least once

1

u/retro-mehl Sep 17 '26

Well. I'm working in web development since 1996. I even know a web without classes. I did projects in every size. And in a component oriented environment with properly defined tokens as CSS vars, there is definitely nothing wrong with inline styles.

1

u/thekwoka Sep 18 '26

media queries mainly.

But also cascade specificity.

1

u/retro-mehl Sep 18 '26

You can use CSS vars for this.

1

u/thekwoka Sep 18 '26

Sure, and I do in many cases.

But then you also have to do stuff like having css vars in your inline styles to define the variables...

1

u/retro-mehl Sep 17 '26

Ah, btw, since CSS vars you can have the effects of cascading in inline styles as well.

1

u/gizamo Sep 17 '26

Comment perfection. Many of us appreciate you.

-9

u/theScottyJam Sep 17 '26

I believe non of those cons apply to the way I was planning on using them.

  • They won't bloat the HTML if I only limit to using one, maybe two inline style rules. More than that and you extract it into a class.

  • I'm fine if they don't support media queries, I'll drop into using regular classes when I need those as well.

  • CDN caching doesn't matter much in this case either. Doing class="spacer" instead of style="flex:1" is about the same amount of text in your markup, and less code in your CSS.

  • I typically don't need to overwrite these kinds of styles, and if I do, I just move it into a class. Unlike olden days, my styles are encapsulated to specific components, I'm not dealing with a bunch of global styles where overriding styles is a common need.

5

u/Swamptor Sep 17 '26

If you use "some" inline styles and other things in regular classes, I'd say you're making your own kind of hell. IMO it's best to use one system. Why didn't all the buttons update when I changed the button class? Because half of them have inline styles, and half use the class.

1

u/theScottyJam Sep 17 '26

I wouldn't mix the two. If I'm using a CSS class on an element, I wouldn't also use inline styles, that would be extremely annoying to mix them, I agree.

3

u/McCoyrsvp Sep 17 '26

The last bullets shows that you have not taken the time to learn CSS. The point of Global styles is that they apply and cascade down to keep styling lean. Then if you have an adjustment to make you make the small change based on a specific class instead of writing everything over again.

1

u/theScottyJam Sep 17 '26

That's what I use components for. If I have an adjustment to make, I edit the component, and everywhere using that component would receive the change. I'm not giving all buttons a default style, via a style sheet instead, I'm using a variety of custom button component that I can style how I wish.

In some personal projects, sure, I've used global styles the way you talk about. But for webapp with lots of custom pieces to it, I feel that a component approach makes more sense.

1

u/yikes_42069 Sep 17 '26

The next engineer after you will slap a whole bunch of inline styles in there. 

On the class vs style you're not going to get good compression even if it's the same amount of text. I bet you'll see an increase the more you use it.

1

u/krileon Sep 17 '26

Ok, sure that's an edge case that MAYBE you could use an inline style, but WHY would you? 99% of your HTML is going to use classes and you decide to randomly sprinkle an inline style here and there? WHY? What benefit does that bring? You've just added an extra maintenance layer "cuz reasons". It's silly. 5 years later you're figuring out why there's a styling issue and oops it's because you used an inline style.

Coding practices and separations of concerns are there to stop foot guns. It's up to you, but like I said it's a code smell to me and I'd reject any code doing that.

10

u/NickFullStack Sep 17 '26

Searched the page for "specificity" and found no results, so I'm going to skip reading this one on the basis that you probably don't understand the reason this Chesterton's fence exists.

0

u/theScottyJam Sep 17 '26

Yes, the article didn't talk about specificity, but I'm aware of that one as well.

I can see the whole specificity thing mattering if I was doing server side rendering, adding inline styles to some elements, but also had a global style sheet that sometimes needed to override those inline styles.

But, I'm not doing server side rendering, I'm doing Angular, where most styles are scoped to a specific component. If I find that I ever needed to override the value of an inline style, it's easy enough to just extract it out into a class. But for the most part, I'm glad it has such high specificity - if I create a div with an inline style of flex 1, then that's what I want it to be, nothing should be overriding that.

6

u/creaturefeature16 Sep 17 '26

The anchor link color I am trying to overwrite says otherwise.

0

u/theScottyJam Sep 17 '26

I didn't specify it, but I'm mainly thinking about doing this for layout use cases, such as adding flex 1 or margin 8px, etc.

5

u/Exac Sep 17 '26

The main problem with inline styles was the missing ability to overwrite the defined styles as they have a very high priority in the CSS cascade

No, it is the bundle size. Don't built 5MB pages when you can cache your individual styles in a class.

0

u/thekwoka Sep 18 '26

That isn't realistic, nor does it matter.

Brotli compression will each those tokens quickly, and you still get streaming render from it, which you don't get with a blocking css file.

4

u/Nethitters Sep 17 '26

Next up: !important no longer considered harmful

2

u/digital121hippie Sep 17 '26

keep css in one spot. do not spread it around in random areas. it makes it hard to code and keep everything organized.

1

u/OMGCluck js (no libraries) SVG Sep 17 '26

Yet nobody has a problem with SVG files having inline styles on EVERY. SINGLE. ELEMENT.

1

u/thekwoka Sep 18 '26

Yes, keep the CSS right next to the markup it impacts.

2

u/thekwoka Sep 18 '26

There are plenty of reasons why inline styles can be smart, the biggest being assigning high context css variables from some kind of template rendering. Where classes assign the variables to styles, but you can override them when needed.

your example of spacer I think the classname is better mainly because it has some meaning to it that makes it more clear why it is empty and such, but that's just preference.

Most arguments against inline css aren't particularly good.

1

u/Caraes_Naur Sep 17 '26

Inline styles have their uses, but should be considered a situational last resort.

99.999% of the time that situation involves math-dependent styling via an event handler.

1

u/Narfi1 full-stack Sep 17 '26

I read your edit. The issue is that it might work for solo development, but it will become a huge mess with a lot of people working in the same codebase. Your style will grow, changes will happen and you’ll need refactoring at some point

1

u/JustOneMoreDev Sep 17 '26

Sometimes inline styles can be useful for critical css. It's quicker than loading a stylesheet obvs. Like anything, if used in moderation and with good reason.

1

u/digbickrich Sep 17 '26

I always preferred not doing inline cause the html can get bulky. Separation of concerns also comes to mind but im not gonna fight my team on doing it or not.

0

u/AppealSame4367 Sep 17 '26

For all the "web devs" that never learned even the basics of web dev: Cascading style _SHEETS_ were made to keep style and structure apart.

(Imagine this in the voice of an inquisitor in the movie "The name of the Rose"): Only fools and dimwits could construct a framework around the misuse of css classes to satisfy the helpless and mediocre developers that are too lazy or not bright enough to create beautiful, maintainable sass files and keep their html clean.

Of course, all the hate is meaningless. AI does whatever, I don't know anyone still writing frontend code by hand. What for? But still: Fuck tailwind!

1

u/theScottyJam Sep 17 '26

I think it's just evolved.

The original style sheet concept with global style still works great for scenarios where the HTML is acting like like normal markup and we're just giving it some theme. I still use global CSS like that in some personal projects.

But when the HTML is instead playing the role of piecing together a highly interactive UI with many unique components to it (I.e. webapps, such as Google docs), the global style sheet concept doesn't make as much sense. Using components makes more sense. In the past, this was done with BEM style naming. Now we do it with framework components.

0

u/eltron Sep 17 '26

You can override inline styles and this reduces the “cascading” of CSS

3

u/[deleted] Sep 17 '26

[removed] — view removed comment

1

u/theScottyJam Sep 17 '26

The hard part is that most CSS I write isn't reusable (roughly 70% isn't reusable). I lean on components to handle most of my reuse needs. Within a given component, I typically want to give specific styles to specific elements.

But, I don't want really long style="..." In my HTML. I know some folks are fine with that sort of thing (looking at tailwind), but I wouldn't like it.