jitendravyas/gist:31195c89da14733dccac2115ac2b3a91

## gistfile1.txt
Anyway, the <button> example @jitendravyas posted earlier (from the Yahoo's site) may be the very best example to explain everything about ACSS.
People new to ACSS will tell you that this is ugly like hell, that changing some styling for that button means to edit the markup which means to go against the Separation of Concern principle, that they do not understand what all these classes mean, how can somebody learn all that, that it is bloating the markup, and did I mention that it is ugly like hell?
Now let's say you are a Yahoo! engineer working working on the "Universal Header (UH for short)" team. You are in charge of making that big ass component that is the UH work across all the many many web sites Yahoo owns. Web sites built on various tech stacks, dealing with different script directions (RTL/LTR), different release cycles, different CSS resets, etc. etc. I have worked with that team and I can tell you they are facing really big challenges (including styles injected to pages by crappy ads)...
Before ACSS, they would ship different CSS assets to cater for those different web sites. On that one they'd need to overwrite the padding of <button>, on that one they'd need to change the color, etc. etc. And if the brand color changed, they'd need to go edit and release the hundred of CSS files they had in their code base. And of course, all that CSS they shipped came on top of what the page itself (the host for the UH) loads. And they were very careful at namespacing everything to prevent styles from bleeding onto those pages and at the same time protect themselves from styles from those pages. And think of new hires required to style something :grinning:
With ACSS, they barely ship any CSS as they do not need to namespace their styling and don't need to worry about styles from host pages using ACSS itself. Engineers can edit the styles of that buttons without wondering how specific their styling needs to be to "stick". And if the brand color change, they don't even have to release anything, because that is not something they own, it can be done with a single config - which once created is available to any ACSS classes using that "variable". To be honest, unless you're working in a very hostile environment like the UH team at Yahoo does, you can't really appreciate all the benefits of ACSS.
I'm sure these FEs would change the narrative to:
It is ugly like hell! So what?
We need to make change to the markup instead of various styles sheets and be careful of not breaking anything? Yes!
We do not understand what all these classes mean! Hu? New hires can guess most of those classes from day one. They are engineers after all, they should be able to easily learn something that simple.
It is bloating the markup! Nope, it is not, to the contrary.
and more...
	Anyway, the <button> example @jitendravyas posted earlier (from the Yahoo's site) may be the very best example to explain everything about ACSS.
	People new to ACSS will tell you that this is ugly like hell, that changing some styling for that button means to edit the markup which means to go against the Separation of Concern principle, that they do not understand what all these classes mean, how can somebody learn all that, that it is bloating the markup, and did I mention that it is ugly like hell?
	Now let's say you are a Yahoo! engineer working working on the "Universal Header (UH for short)" team. You are in charge of making that big ass component that is the UH work across all the many many web sites Yahoo owns. Web sites built on various tech stacks, dealing with different script directions (RTL/LTR), different release cycles, different CSS resets, etc. etc. I have worked with that team and I can tell you they are facing really big challenges (including styles injected to pages by crappy ads)...
	Before ACSS, they would ship different CSS assets to cater for those different web sites. On that one they'd need to overwrite the padding of <button>, on that one they'd need to change the color, etc. etc. And if the brand color changed, they'd need to go edit and release the hundred of CSS files they had in their code base. And of course, all that CSS they shipped came on top of what the page itself (the host for the UH) loads. And they were very careful at namespacing everything to prevent styles from bleeding onto those pages and at the same time protect themselves from styles from those pages. And think of new hires required to style something :grinning:
	With ACSS, they barely ship any CSS as they do not need to namespace their styling and don't need to worry about styles from host pages using ACSS itself. Engineers can edit the styles of that buttons without wondering how specific their styling needs to be to "stick". And if the brand color change, they don't even have to release anything, because that is not something they own, it can be done with a single config - which once created is available to any ACSS classes using that "variable". To be honest, unless you're working in a very hostile environment like the UH team at Yahoo does, you can't really appreciate all the benefits of ACSS.
	I'm sure these FEs would change the narrative to:
	It is ugly like hell! So what?
	We need to make change to the markup instead of various styles sheets and be careful of not breaking anything? Yes!
	We do not understand what all these classes mean! Hu? New hires can guess most of those classes from day one. They are engineers after all, they should be able to easily learn something that simple.
	It is bloating the markup! Nope, it is not, to the contrary.
	and more...