Can't say that those slides were very convincing. Right now it looks way too overengineered.
I'm not a fan of muddying JS with bits of HTML in general, and now CSS in JS?
Yes, that may work for Facebook. They've been inventing their own way of doing things for a while now, but I very much hope that won't go beyond Facebook.
The whole "button in an overlay" section of the presentation shows just how mind-bending this becomes. In a sane universe, one simply needs to write `.overlay .button`. But of course, you can't do that with CSS that's referenceable from a single name (or where you're statically applying styles to an element rather than letting the CSS...well...cascade). I could see if the solution presented made me say "Oh, this is a much more intuitive way of styling a web application." It didn't. Instead, I read, "We have this crazy proprietary namespaced CSS system that has limitations that we can't work around without building an even crazier system on top of it," and thought to myself, "Well don't do that then."
So now you're at a point where everything is an inline style. Your browser's devtools are essentially useless because you can't see how the CSS cascades. What overrode what? God only knows, go look at the JavaScript.
Of the seven problems outlined at the beginning, I think few of them were really a problem to begin with. A codebase that 1. properly organizes its CSS into files with descriptive names and a sane directory structure 2. uses OOCSS or other best practices 3. is mindful of style bloat 4. has a sane DOM structure and 5. uses a preprocessor of some variety for variables does not suffer greatly from any one of those issues. I work on a codebase of >10^5 lines of CSS that minify+gzip down to 30kb. That's a single small JPEG worth of code.
I would be interested to see some of the alternative solutions that Facebook explored that don't dive straight into the Twilight Zone.
One reason is cascading. The way CSS applies to trees means that every component has to be aware of what properties it could accidentally inherit. So to code defensively, you override things like colors and fonts. Using SASS mixins helps.
But sometimes you do want contextual modifiers, for example styling all components differently when they're in a certain type of container. For example, if the container's background is light grey, we'll want all nested text to have a subtle bevel (ie., white text-shadow).
It's tempting to use cascading for this, but that breaks — by definition! — separation of concerns. In one way it's better to actually have each component be container-aware; for example, given that Form and SpecialContainer are both components you can do this in form.scss:
.SpecialContainer {
background: #f0f0f0;
}
.Form {
.SpecialContainer & {
text-shadow: 0 1px 0 #fff;
}
}
.Form {
&[data-light-background="true"] {
text-shadow: 0 1px 0 #fff;
}
}
Nevertheless, that was not the best presentation on some issue and it didn't help to explain that issue any better.