This article interviews Thierry Kobleentz, creator of Atomic CSS, to gain an in-depth look at the history and context behind this popular CSS framework. Thierry is now retired and has extensive experience in writing large CSSs, and has worked as a front-end engineer at Yahoo.
Thierry is widely regarded as bringing the concept of Atomic CSS to the mainstream for his classic 2013 article “Challenging CSS Best Practices” on Smashing Magazine. This article paves the way for many popular CSS libraries over the years. In this interview, Thierry reviews the history of Atomic CSS and reflects on its ongoing impact.
Thierry Kobletz: After moving to the United States in 1997, I taught myself HTML, CSS and JavaScript as hobbies.
At the time, I was using FrontPage and relied heavily on newsgroups for guidance. I quickly became a regular customer of Macromedia newsgroups and CSS-Discuss. Early on, I supported the Web standard project philosophy and developed a strong interest in accessibility. For years, the front end has been just a hobby for me (my real job is an antique dealer). I would create a website occasionally, but I am mainly writing and publishing (many) articles sharing techniques I have learned or “discovered”.
This paid off for Yahoo's call in 2007, asking me if I could help fix and build the stylesheet for the Yahoo! Website Solution (YSS) website builder template. Job Description: No HTML, no JavaScript, only CSS! And many!
TK: My role at Yahoo has changed a lot over the years.
My first job was to create a stylesheet for a YSS template (similar to CSS Zen Garden). Then, before YSS was “delivered” to Bangalore (India), I rewritten the markings and styles of the YSS website – where my colleagues and I were sent for “knowledge transfer”.
By the way, it is the challenge of replacing stylesheets to create different designs for YSS that force us to find a lightweight (non-js) solution to resize videos on the fly; that's how I came up with "creating intrinsic scales for videos".
After YSS, I had the opportunity to only participate in projects starting from scratch (rewrite or otherwise), and I'm increasingly involved in Yahoo front-end work. I edit and create many internal documents (i.e. CSS coding standards); participate in the recruitment process (like others on my team); lead code review meetings; hold CSS courses and workshops; speak at FED London; help other teams deal with HTML/CSS/accessibility issues; participate in decision-making in technology adoption (such as Bootstrap or non-Bootstrap); create libraries; review internal papers; write proposals; and more.
Another additional note that in my eight years at Yahoo, I probably didn't have 100 lines of JavaScript code. If I didn't quit or got fired, it's thanks to Lingyan Zhu and Renato Iwashima; they tirelessly helped me in setting up my environment or handling the command line (because I'm still terrible to this day).
TK: In the early days, there were neither libraries nor published methods; that was the wild west, everything could be: "non-semantic" classes, IDs, CSS hacks, conditional annotations, frameworks, CSS expressions, "JS probing", mainly designed for Internet Explorer, and so on. On my old site, I even had a comment like this:
<code></code>
Everything is fair competition, everything is abused because we only have a very limited set of tools and have to do a lot of things.
But when I joined Yahoo, things changed dramatically. Developers from the UK are staunch supporters of Web standards and I thank them for their great influence on how Yahoo’s HTML and CSS are written. Semantic tagging is a reality, and CSS is a "T" written in accordance with the principle of separation of concerns (SoC) (although sometimes too keen for me).
YUI has CSS components, but does not have a CSS framework yet. There is an internal CSS library (called Lego) but I have never used it. OOCSS, SMACSS, ECSS (Salute to Ben), BEM, Bootstrap, Pure and other methods and libraries will appear soon.
TK: Before YSS moved to India, my manager Michael Montesano asked if there was a way to get the team in Bangalore to avoid editing style sheets, thereby reducing the risk of damage . I think the experience of YSS templates (paid customers complain about the page being damaged) makes him very paranoid when making any changes to the stylesheet.
So, in the spirit of my ez-css library, I created a "utilitary table" - a table designed to allow developers to implement their styles without editing or adding rules to the stylesheet .
A few years later, Michael, then-director of engineering, asked me if I could redesign Yahoo’s homepage using the utility class only because he knew that again we wouldn’t be responsible for website maintenance. We discussed prioritizing utility classes over semantic classes, and I don't think that at that level thing did not exist at the time. This is a very bold move.
This massive exercise quickly became a proof of concept, showing many of the benefits of styling with tags . It checked so many boxes that we decided to redesign Yahoo! My Home Products using that "static" stylesheet (called Stencil).
TK: Our Stencil library is static, and it's a great tool to enforce design styles – we think Yahoo is about to adopt this style in all its properties. We quickly realized that this would not happen. Each Yahoo design team has its own opinions on perfect font sizes, perfect margins, etc. We keep receiving requests to add very specific styles to the library.
This situation is unmaintainable, so we decided to develop a tool that allows developers to create their own styles on the fly while respecting the atomic nature of the creative method. This is how Atomizer was born. We stopped adding styles—CSS declarations—and instead focused on creating rich vocabulary that provides developers with a wide range of styles such as media queries, descendant selectors, pseudo-classes, and more.
With ACSS, developers are free to use whatever they want; therefore, the team is able to adopt different design styles and style guides while using the exact same library. And there are some new direct benefits for the styles that developers have used to. They no longer need to worry about their styles breaking the page, nor do they need to worry about writing selectors to style their components.
ACSS was originally built to solve Yahoo’s problems and work in Yahoo’s environment.
People involved in the Atomic CSS include Renato Iwashima, Steve Carlson and myself. Renato and Steve created the Atomizer.
TK: When I joined Yahoo in 2007, I quickly learned how huge the code base might be. There are teams across many locations/time zones; countless products; hundreds of shared components; third-party code; A/B testing strategies; as a requirement extension; different scripting directions; localization and internationalization; various release cycles; complex deployment mechanisms; a large number of metrics; various legacies; strict coding standards; construction processes; politics; and more politics; and so on.
Most of this is brand new to me and I have to learn whether and how it affects the way I write CSS. I started to revisit and challenge all my beliefs because many techniques or methods that are common practices for me don't seem to fit, or at least counterproductive to complex applications.
A "reality check" is related to style abstraction. We've all read the article saying that mapping M-10 classes to margin: 10px is not a good idea, as it means editing both HTML and CSS to change the style. Unfortunately, this is what happens in large/complex projects:
To predict such a problem, it is necessary to understand the intent of the designer behind their request: is the style chosen because of its abstraction, such as the color primary, or because of its specific value, such as the 15-pixel margin in our M-3x case? If there are style guides to enforce design principles, classes like M-3x may be fine, but if the design team can request any style they want, it is better to avoid naming conventions that will lead to blurred styles. In my experience, any ambiguity can lead to damage.
Relying on the structure of a document or component for style setting—through a combiner such as > or—sounds like a neat way to write a style sheet, but it ignores the fact that in complex environments, it cannot be assumed that any particular tag or structure is immutable.
Do you think z-index is complicated? Think about it again when you don't even have the stack range where your components are located. This is one of the most complex issues to be solved in large projects where the team is responsible for different parts of the page. I once wrote a proposal on this.
Qualified selectors—such as input.required and .input.required—looks nice and semantic, but it creates unnecessary levels of specificity—such as 0.1.1 and 0.2.0—and prevents tag changes; it's easy to avoid both by ensuring that you don't limit the selector.
Relying on wildcard selector* to set global scope styles? In a very large project, this may mean that you are styling other people's components. Don't make style decisions for others unless you understand their needs.
I believe you read the ID is bad, the specificity is bad, but. In fact. High specificity is not as problematic as the number of specificity levels created by your rules. It is much easier to style in an environment where there are only two or three levels of existence—for example, 1.1.0, 0.1.0, 0.2.0—rather than in an environment with rather low specificity but following a "free competition" approach—for example, 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, etc.—this usually occurs as a defense mechanism in large projects as a means of "sandbox" styles.
Blindly following the CSS community’s advice can lead to unpleasant surprises. Never adopt new technologies that have not yet been tested in practice. Remember will-change? And always know what each style you use or what may trigger it. For example, position can create a stacking context and a containing block, while overflow can create a block formatting context.
In my experience, deep understanding of CSS is not enough for large organizations to write CSS efficiently. During my time at Yahoo, I often found myself in conflict with people who used to be with me a few years ago. The environment is very cruel and requires very pragmatic to avoid many pitfalls. Next time you look at the source code of a large project and see something that doesn't make sense to you, remember this tweet from Nicholas Zakas:
Don't assume that people are stupid, ignorant, make mistakes, assume that they are smart, do their best, and you lack the background.
— Nicholas C. Zakas (@slicknet) February 10, 2013
TK: Our My Homepage Team accepted ACSS well, but it wasn't going well outside. Our first interaction was with the sports team located in Santa Monica. Steve and I tried to convince developers on a conference call that not following the principle of separation of concerns is the right thing to do and that it does not cause confusion.
We pointed out to them a recent article by Nicolas Gallagher that it would be helpful from “outsiders”, but not! Things are not going well and there are a lot of friction. The main problem is that the library is composed of utility classes, but its syntax does not help ease the conversation.
I remember meeting with the email team, who didn't object to the idea of Atomic CSS, but wanted to come up with their own JavaScript method to use "normal" CSS declarations - because they couldn't stand ACSS syntax. Regardless, the data supporting the library (about 36% reduction in CSS and HTML) says it all by itself, so ACSS is the end. Today, more than seven years later, Yahoo Homepage, Yahoo Sports, Yahoo News, Yahoo Finance and other Yahoo products are still using ACSS.
To better understand how approaches like ACSS benefit projects where component reusability is critical, copy the markup of the component from Yahoo Finance and paste it into Yahoo News. The component should look like it belongs to a part of the page. This is because ACSS makes these components independent of the page.
TK: We have identified two sets of "candidates" used as attribute value separators through multiple iterations: parentheses() and square brackets[].
Renato recalls that we chose brackets over square brackets because we were familiar with functions in JavaScript, even at the expense of additional Shift keystrokes. ACSS syntax is intended to:
It looks like this:
<code>[<context> [:<pseudo-class> ]<combinator> ][(<value> ,<value> ?,...)][][:<pseudo-class> ][::<pseudo-element> ][--<breakpoint_identifier> ]</breakpoint_identifier></pseudo-element></pseudo-class></value></value></combinator></pseudo-class></context></code>
Developers build their classes according to the above structure. The core syntax is based on the popular toolkit Emmet. We use the Emmet method to reduce features, because the core class is an explicit property/value pair, not an arbitrary string.
We have also created more than a dozen auxiliary classes. These apply multiple style declarations and are either shortcuts, such as content hiding the visually impaired user, or hacks, such as clearfix using .Cf. We also provide developers with more freedom by using configuration files where they can create variables—such as .PrimaryColor—breakpoints and more.
People who have never used ACSS will tell you that the syntax is too weird (at best), but people who are familiar with it will tell you that it is clever in many ways.
TK: I have written a lot in various online publications before, so it is natural to write an article about this “challenging” approach.
Yahoo sponsored a front-end conference in October 2013, where Renato arranged a speech to introduce our solution, and I tried to publish this article before that. I chose not to post it on the Yahoo! Developer Network because the site does not provide a comment section. A List Apart couldn’t publish it in time, but Smashing Magazine has accelerated its review process to be able to publish the article by the end of October.
My approach to choosing a publisher with a comment section paid off because the post received over 200 comments, which was very time-consuming and frustrating for me – and I had to respond to those comments.
TK: When the article was published, I told Vitaly [Friedman, co-founder of Smashing Magazine] that note sounded like some kind of disclaimer; it affected the way people read the article. But I didn't really refute it because I understood Vitaly's idea. I do find this note still interesting, and this approach has become mainstream now.
TK: There is always room for improvement, especially after you pioneered this solution. You can't look at what others have done to learn about their mistakes or shortcomings. You have no improved materials. So if we think we succeeded the first time, it would be conceited.
We have extensive experience with Atomic CSS because we have used "static" style sheets in large projects for over a year. But in terms of dynamics – tools – we don’t seem to find much inspiration. Remember, it took six years for the other libraries to follow suit.
In French we say: essuyer les plâtres . (Wipe dust)
One mistake we made was to use "Atomic CSS" as the title of acss.io because, as John Polacek pointed out, this created some confusion. Since then, we have changed the title.
The only thing I regret is how the community has treated Atomic CSS/ACSS over the years, which recently led to a strange exchange where someone explained to me what “Atomic CSS” means:
The Atomic CSS library [ACSS] uses this name, but I think it's misleading because the functionality you're talking about is dynamic style generation. "Atomic CSS" is a common term that specifies small selectors as atoms, but they are static.
Talk about being erased. ;)
Thank you very much for Thierry for participating in this interview and allowing us to post it to the community.
The above is the detailed content of The Making of Atomic CSS: An Interview With Thierry Koblentz. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
