Maintainability is the big reason not to inline CSS. Inline CSS is the most specific CSS you can write and cannot be overruled by other styling from within a CSS file, unless specified by !important (IIRC that is).

That and the fact that inline CSS isn't cached, like a regular CSS file is :)

I wonder why people suddenly think that inlining CSS is a good idea. I find it really confusing to be honest.

p.s. Don't forget about progressive enhancement... ;)

1 - It mixes functionality. CSS is for styling. HTML is for markup. Javascript is for functionality. This whole conversation regards separation of concerns. By inlining CSS or using React or whatever, you've now broken that way of thinking. Now, if theres a problem, theres not 1 files to look at for problems (the css file) but possibly many. It's a time suck.

2 - How do you deal with hover? or nth? or mobile / responsiveness? or a thousand other things CSS can do very well that'll take Javascript lots of code to accomplish? Sure - you can use JS to bind mouseover to a href and change it; but CSS does it so gracefully. These frameworks rely on JS so much to build the page; now it has to rely on JS to style the page also? Because CSS is old and inlining style is new and fancy? Inlining style has been around since the inception of html. This is not a new idea; it's an old idea that was thrown out for efficiency.

Inlining CSS is good for 2 possible scenarios IMO - Emails - which you really have no choice but to inline style - there are so many browsers / email clients / online email clients and so many of them don't support CSS, inlining the style is the only way and the preferred way to style an email. The 2nd scenario being an absolute quick hack. We've all done it - something is broken, doesn't look right, the boss is pissed and wants something changed; etc... do a quick inline style to fix it and deal with it later. But to build an entire website with inline style; I'd vomit in my mouth.

The article in question I feel is almost completely related to the fact that React inlines HTML / markup so the train of thought is - well, we're doing it to the html, why not do it to the style also? That's a very bad way of thinking about it IMO. Fix the reason why React needs inline html / style - don't through out the baby with the water.

Inlining, back to the roots. It was the only way to style elements. And it will be the next big thing, again.

Google calls it AMP https://www.ampproject.org/ In React.js ecosystem tonnes of libraries exist to help to inline CSS. All it takes to generate such results are the right tools.

Our development tools are just not good enough to handle inlining well without losing all the comfort we gained over the last couple of years.

And again, separation of concerns has nothing to do with separation of technologies. But people like to organise files and content based on technologies and love to call that thing separation of concerns. meh :F

Word of warning, if you're one of these thin skinned wussies who can't handle a little harsh language, just do us all a favor and sod off. Read no further, I'm going to be BRUTALLY frank in my assessment of this topic without sugar coating it or blowing smoke up anyone's arse!

Like many such thoughts this topic begs a much bigger question: WHAT ARE YOU BUILDING?

If you're making a crApplication with web technologies, most of the bloat issues can be swept under the rug on performance, most of the concerns about the how/what/why of using HTML, CSS and JavaScript properly simply don't play into it as mostly web applications flip the middle finger at users with accessibility needs, flat out ignore good development practices because like MOST applications, you can be pretty sure your target audience is on a screen media device with a fairly standard/normal interface.

Probably why I'm not a big fan of web crapplets -- they're bloated, slow, and even with my not having any real disabilities they end up little more than the developers of such systems saying they could give a flying * about users like myself.

But if you are making a WEBSITE? Whole different ballgame! Accessibility is job one, particularly with many nations -- the UK leading the charge -- implementing laws and fines if certain types of websites fail to meet accessibility norms. You fail to meet WCAG guidelines, you fail to use HTML properly, you fail to maintain separation of presentation from content.... well, you just built a steaming pile of epic fail!

It's why progressive enhancement isn't just a catchphrase, and the "content FIRST" approach to development is important if you care even the slightest about VISITORS using your site getting to what they came to the site FOR -- THE CONTENT.

You write up in a flat text editor as if HTML didn't even exist your content or a reasonable facsimile of future content in an order that makes sense. You then enhance that content (real or placeholder) with semantic markup saying what things ARE, and NOT what they look like!!! That's what semantics means!!!

.. Well, to be honest "semantic markup" is sick euphemism for "using HTML properly" that we use so as not to offend the mouth-breathing halfwits who still vomit up HTML 3.2 and the vendor proprietary crap, completely missing the point of HTML and then slapping either 4 tranny on it or 5 lip-service around it... all so they can pat themselves on the back over how "modern" their bleeding edge of 1990's development practices is.

SINCE that stage is about semantics, DIV and SPAN have no place in it. They are "semantically neutral" and the most meaning they imply is "this MAY receive some sort of style or be grouped for styling or scripting".

Also since H1...H6 and HR indicate the start of subsections, there is NO legitimate reason for SECTION (flat out redundant), ARTICLE (likely redundant to h2 or h3), NAV (redundant to the first H2 or HR), FOOTER (redundant to the last HR or last HR before a sibling level heading), HEADER (duh), ASIDE (which is either so restricted in meaning as to be useless or so presentational it has about as much business being used as CENTER), or most of the rest of the allegedly semantic rubbish 5 went and crapped on the web with.

Then and ONLY then do you think about the first of your MANY layouts, both in terms of responsive (media queries) AND media targets (screen, print, braille, aural). That's when you can add DIV and SPAN but only AS NEEDED once you've expended what you can do with the existing markup.

CONTENT dictates markup, CONTENT plus MARKUP dictates layout.

Anything else is fat bloated arsty fartsy BS sleazed together by scripttards and PSD jockeys who are more interested in stroking their ego than they are in making successful sites. (I said ego to be polite, I meant something else).

But really this idiocy of bloated re-re rubbish like react.js is only the last in a long line of progressively worse developer ignorance, ineptitude and stupidity. Bootcrap, jQuery, YUI, Blueprint, Grids -- it's all a bunch of nonsense used by people who don't seem to know enough HTML, CSS or JavaScript to be creating a blasted thing in the first place -- which is why we're ending up with hordes of ineptly developed multi-megabyte monstrosities to deliver 2k of plaintext and a half dozen CONTENT images that optimized wouldn't even break half a meg!|

THEN these twits go and claim their bloated framework BS made it "easier"? I still fail to see how writing more markup, that depends on bloated libraries, that still makes you write your own CSS unless you want to cookie-cutter out crap, is "easier" for anyone qualified to even be writing HTML, CSS or JS in the first damned place! At BEST it's marketing placebo BS, at worst it's a bit like what Patton said about fixed fortifications; a monument to the stupidity of man.

I said twits above, I mean a similar word with a different vowel

It is with disgust to the point of nausea I look at the type of halfwit rubbish you find at the various nube predating whorehouses like themeforest or templatemonster... and ignorant garbage like "let's put the style back in the markup" is as much as fault as the broken practice of dicking around in a paint program and calling it design, or the endless pointless rubbish practices like OOCSS or the time wasting trash that are pre-processors.

I swear it makes me think there's something in the water.

Bottom line, if you are making a website and you use the style="" attribute, unless that value is conveying meaning or content -- like width on a percentage graph or size on a tag cloud -- you are PROBABLY doing something wrong... If you are using the <style></style> tag, you ARE doing something wrong, and for the love of Christmas do the world a favor, back the ** away from the keyboard and take up something a bit less detail oriented like macramé.

Same goes for if you actually think there's nothing wrong with having a dozen or more presentational classes on the body tag alone, much less crapping all over the menu like most turdpress, bootcrap, OOCSS, LESS, SASS and other such halfwit fools do.

There's a reason more than 80% of websites out there need the Ellen Ripley approach; nuke the site from orbit -- it's the only way to be sure! Generally speaking the people who advocate the use of crap like react.js simply lack enough knowledge about ANY web technology to even be flapping their gums on the topic, and are MORE than willing to tell large swaths of potential users to go take a flying leap.

But Joe forbid anyone respond in kind with a bit of harsh language.