5 ms·

At the last slide author says that the goal of that talk was to convince us to drop CSS and use JS. Can't say that those slides were very convincing. Right now

At the last slide author says that the goal of that talk was to convince us to drop CSS and use JS. 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.

bastawhiz 12y ago
I agree. CSS is global, but that doesn't mean that it can't be managed. I think going down the road of having programmatically generated stylesheets is solving a relatively small problem with an extremely over-engineered solution. Soon enough, you can't actually develop without the use of dozens of different tools for generating source maps, transpiling, etc. In all honesty, any presentation that says "If I started with this, you would have written me off as crazy" is probably giving itself too much credit and is in fact based on crazy. 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.
- lobster_johnson 12y ago
  We organize our SASS files very carefully. One file per component, careful naming, strict rules about overriding a component's internal classes (".mycontainer .somecomponent .somecomponent_title" is illegal). It's still painful. 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; } } It's cheating, though; now you have a dependency between the Form and SpecialContainer that really wasn't needed. So when I'm not being lazy, I resort to explicit parameters: .Form { &[data-light-background="true"] { text-shadow: 0 1px 0 #fff; } } Now I have to pass "lightBackground" as a prop to the component have it set the data-light-background attribute. Of course, this only works the component embedding Form actually knows that it has a light background or is embedded in one that has a light background. Not ideal.
Myrth 12y ago
You've missed the "not" word. I had to double take too.
- Ronsenshi 12y ago
  Right. Missed that one, my bad. Nevertheless, that was not the best presentation on some issue and it didn't help to explain that issue any better.

bastawhiz 12y ago

I agree. CSS is global, but that doesn't mean that it can't be managed. I think going down the road of having programmatically generated stylesheets is solving a relatively small problem with an extremely over-engineered solution. Soon enough, you can't actually develop without the use of dozens of different tools for generating source maps, transpiling, etc. In all honesty, any presentation that says "If I started with this, you would have written me off as crazy" is probably giving itself too much credit and is in fact based on crazy. 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.

lobster_johnson 12y ago
We organize our SASS files very carefully. One file per component, careful naming, strict rules about overriding a component's internal classes (".mycontainer .somecomponent .somecomponent_title" is illegal). It's still painful. 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; } } It's cheating, though; now you have a dependency between the Form and SpecialContainer that really wasn't needed. So when I'm not being lazy, I resort to explicit parameters: .Form { &[data-light-background="true"] { text-shadow: 0 1px 0 #fff; } } Now I have to pass "lightBackground" as a prop to the component have it set the data-light-background attribute. Of course, this only works the component embedding Form actually knows that it has a light background or is embedded in one that has a light background. Not ideal.

Myrth 12y ago

You've missed the "not" word. I had to double take too.

Ronsenshi 12y ago
Right. Missed that one, my bad. Nevertheless, that was not the best presentation on some issue and it didn't help to explain that issue any better.