14 ms·

Fix CSS by writing it in JavaScript

38 points by oleg009 12y ago

JelteF 12y ago
Why would you ever use this instead of an easier preprocessor like sass or less?
- LandoCalrissian 12y ago
  I don't know, doesn't make much sense.
- jhpriestley 12y ago
  Javascript has superior facilities for scoping, abstraction, and calculation. Sharing a single scoping system between JS, HTML and CSS removes the need for global symbols (classnames or ids) to link the two together. Abstractions in preprocessors are implemented by means of macros, and can lead to large file sizes.
  - talmand 12y ago
    I'm sorry, but there will always be a need for classnames and ids for multiple reasons. A tool like this doesn't remove them from being used, it just partly removes them from the initial code. Proper usage of CSS preprocessors will result in much the same code that this tool will generate. Because in the end they both generate the same CSS.
    - boucher 12y ago
      That's not really the case. For one, it's incredibly easy to end up with very bloated CSS files if you use something like less/sass. But more importantly, those tools don't give you actual scoping. Although it's not necessarily the main way the author is suggesting interacting with this library, it can be used as a tool to apply inline styles directly to elements, which gives you total control over the scope of your styles.
      - talmand 12y ago
        If not done properly, anything code-related can result in bloated and inefficient code. I fail to see how introducing Javascript code that requires DOM manipulation is more efficient than a properly built style sheet. Injecting styles inline to elements is an even more inefficient way of doing things, you're likely to cause repaints all over the place during initial rendering. As I said elsewhere, if this were a system done on the back-end (or even in something like Grunt) so that it was part of a compiling process then it would have merit. But from what I'm seeing this appears to run only on the client side which I feel is a bad idea.
    - jhpriestley 12y ago
      The site seems to be down, I don't actually know the details about this particular tool. However, you're wrong that classnames and ids are always necessary. You can set the HTML "style" attribute directly when generating the view.
      - talmand 12y ago
        They can be necessary for reasons other than CSS. Trying to do most of them, including CSS, without the usage of classes and ids is just a strange notion. There are several different ways to handle CSS and each has their own pros and cons. But I'm assuming you're talking inline styles on the HTML elements directly? If so, while useful and I do it myself often, it is not optimum. If you're talking about injecting the styles on or before page load for that particular view, of course you can; but that doesn't mean anything different than what I've been saying at all. In the end it is still CSS and if it doesn't done properly in the beginning it will eventually cause problems.
    - malandrew 12y ago
      Not completely. With a virtual DOM based solution (which is where things are trending due to performance), the ids and classnames of HTML become far less relevant.
      - talmand 12y ago
        I agree, but that's tomorrow and in the end that only replaces classnames and ids with something else which will serve pretty much the same purpose. You have to have identifiers of some type, today it is classnames and ids; tomorrow it will be something else.
- wmeredith 12y ago
  I suspect if you're OK at CSS and great at JS, this would have some appeal. Conversely, if you're great with CSS and OK at JS, this will not. It doesn't help that in most of the examples the Javascript implementation is more complex than the css implementation.
  - talmand 12y ago
    If you are bad at CSS and good at JS then this tool will not really help you. In the end it generates CSS, which you have to know to some degree to be able to create the JS version of it. I agree on the complexity issue with the examples, I don't see how the 30% savings claim would hold up.
    - oleg009 12y ago
      saving come from 1. code reuse. less/stylus will generate everything dozens of times 2. vendor prefixes are added effectively at runtime
      - talmand 12y ago
        CSS allows for code reuse, it always has. It's called cascading and classes. Preprocessors will generate bloated CSS if not coded properly, same as it's possible to hand-code bloated CSS. There are libraries that generate vendor prefixes at run time. If prefixes are really a bother (they're not as much anymore) then preprocessors and other compiling tools have solutions for that as well. Which will be more efficient for the browser.
        oleg009 12y ago
        1. Stop assuming I am stupid. 2. I know code reuse technics in css, they are mentioned in the presentation. Cascades do not work for component based development. Adding multiple classes to an element leads to awkward code and also will lead to namespace conflicts if you don't name everything very specifically. 3. Vendor prefixes are there and will be used for new features too. They will not go away. Precompilers can't avoid generating all prefixed variants.
factorialboy 12y ago
Question: Much of the CSS may not be written by programmers. How would we make use of JSS in this case?
- oleg009 12y ago
  jss not harder than less/sass/stylus ... its declarative json syntax most of the time.
jacobr 12y ago
Nice project! The Cascade in CSS can be a real maintenance nightmare, and people seem to have very different ideas on how to handle encapsulation and modularization. After a while with React, I thought it would be nice to define all styles for a component in the same location (inside my Component JavaScript). Setting the `top` property of a popup in JavaScript, but `width` or whatever in a CSS file just feels weird. There's been some discussion about making this easier in React[1], but also resistance, so while waiting I wrote my own little library[2] (not React-specific), but it's not as feature rich as JSS. I think that the fact that many projects[3] like this are popping up is validating the idea. [1] https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/04%20-%20Inline%20Styles.md [2] https://github.com/jacobrask/marcssist [3] https://github.com/js-next/react-style https://github.com/tenphi/jcss https://github.com/chenglou/RCSS
- colinramsay 12y ago
  You can set top in CSS.
  - lhorie 12y ago
    He means "top" as in "top-relative-to-scroll-position-when-the-modal-is-taller-than-the-screen-in-IE8"
    - colinramsay 12y ago
      Ah, well you'd still need something more powerful for that kind of thing to work. A constraints engine for example: http://gridstylesheets.org/ http://gridstylesheets.org/ If you're going to go to the trouble of writing a CSS processor, you could at least add in some really interesting ideas.
- talmand 12y ago
  Why is setting width of a popup in CSS weird?
mrcwinn 12y ago
No.
norcimo5 12y ago
Hell yes!
colinramsay 12y ago
Atwood's Law [1] kicking in here.... "Any application that can be written in JavaScript, will eventually be written in JavaScript". [1] http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/
lhorie 12y ago
vjeux (of React fame) gave a presentation on a similar system they were using at Facebook https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js "This-is-not-what-I-am-used-to" objections notwithstanding, it's certainly an interesting approach to solve some CSS issues.
talmand 12y ago
I'm sorry but I totally fail to see the problem that this is supposedly trying to fix. In the example provided, the problem is presented as a failure of cascading in CSS. But the problem as I see it, is in the structure of the HTML. The example is a component with a button inside a component with a button. Then global selectors are used which creates a result we don't want. Slide 11 states global selectors are a problem. Which they can be, if used improperly just like every other tool we have access to. So, the solution is to write Javascript that results in using classes. Which is what should have been done in the first place. So, instead of creating a proper class structure in the HTML it is suggested to use Javascript to create classes, inject style sheets into the dom, and inject classes into the HTML elements on page load? All to avoid using CSS properly? I'm sure this is a wonderfully coded project, has interesting ideas, and may be useful to some, but as a front-end developer I seriously doubt I would ever use this nor recommend it. I would suggest just learning CSS, it's not that hard. I would say that this type of project would be far more suited for a back-end library that generates stylesheets on the fly in an effort to maintain code efficiency. But doing all this in Javascript just seems to be about addressing people's attitude towards CSS and not about actual problems in CSS.
- spion 12y ago
  How does one properly use classes without making them global? Its either global or tied to your document hierarchy. And tied to a hierarchy is worse because it makes it harder to reuse a class outside that particular hierarchy without modifying the original selector...
  - talmand 12y ago
    You don't. That's the whole point. The reason for classes is to reuse CSS properties for efficiency. If you are making classes that are strictly tied to your hierarchy in a way that prevents proper reuse, then it's being coded the wrong way. Using a tool to fix the improper usage of another tool is not the solution. If this tool is the solution, that the CSS it generates is the best way to do things, then why not code the CSS that way in the first place? EDIT: As I'm seeing elsewhere in this thread; why exactly is globals bad in CSS?
_lce0 12y ago
Now this is an interesting approach! Are there anyone using it in the wild?
imanaccount247 12y ago
"Fix toothpaste by making it out of feces"
zajd 12y ago
Pretty sure LESS/SASS already "fixed" CSS.
deleted 12y ago
[deleted]
semasad 12y ago
Ok, he can be talking seriously. The problem he try to fix is easily fixed with ANY CSS preprocessor, Stylus, Less, Sass...
ArtDev 12y ago
Use Javascript for CSS.. to process it out of LESS. LESS is Javascript but with certain limitations. If you don't like it, write your own. Or better yet, contribute.
ArtDev 12y ago
I only got a few slides in before it became obvious that he doesn't know CSS.
ttty 12y ago
This reminds me of https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS . It can be used with react.js and it just works ok.
chenglou 12y ago
The few past submissions on writing CSS in JS didn't seem to have picked up discussions. I'm glad this one at least does. I'm gonna go ahead and avoid repeating what's already mentioned in vjeux's presentation (https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js). Instead I'll focus on defending against the common "shortfalls" people tend to immediately point out with this approach. Designers will be uncomfortable with learning this: React's JSX has shown that (surprise surprise) designers can bear modifying markup with a little bit of code mingled in it. In this case, JS objects in their simplest form map very well to css declarations. I don't believe designers will be scared away by this at all. "Atwood's law", "we already have CSS", "stop reinventing CSS": no one's reinventing the idea of CSS; we're reinventing the implementation of it. Declaratively specify your layout is really nice, but you do want the backing of a real language to do so. Merging two styles is just a `merge()`, Overriding a style is just `bla.color = newColor` (assuming you don't mind the mutation; otherwise clone it or use persistent collections), and (!) reusing, importing, exporting styles is already solved with commonJS since you're working with normal js objects. We already have preprocessors: except preprocessors are there to solve the exact problem "CSS in JS" is solving. The difference is that the latter, again, uses a real, familiar language instead of inventing an ad-hoc new syntax like we've done countless times with HTML templates. And since preprocessors need to generate the final CSS beforehand, this limits lots of potentials such as looping more than, like, ten times. On this last point, I hope that none of the critics here used React's virtual DOM before; If you did, and are still complaining about writing CSS in JS, then you should go back and re-learn why the virtual DOM came to be. CSS in JS is the "virtual styling" equivalent for CSS. The potentials are huge (runtime feature detection for example). And this new layer allows us to map the neat, declarative style to something else than CSS: say, webGL. This is platform-independent; if anything, it's a nice conceptual model. (Disclaimer: I made https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS)
- oleg009 12y ago
  Thanks Cheng, you nailed it. Jss was actually inspired by your RCSS idea, I just wanted a different implementation. So thank you again. Some people here assume that I am stupid and didn't learn the css basics. This is just funny.
ttty 12y ago
Amazing (: I like the '&:hover': { part. Take a look at rcss https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS Your lib would be amazing to work with react.js. You would need to create the class names based on the contents instead of incrementing an id to make server side rendering faster. Take a look at rcss on how they do it.
rquantz 12y ago
You know what I've never thought? "The problem with CSS is that it is not imperative enough."

38 points by oleg009 12y ago

JelteF 12y ago

Why would you ever use this instead of an easier preprocessor like sass or less?

LandoCalrissian 12y ago
I don't know, doesn't make much sense.
jhpriestley 12y ago
Javascript has superior facilities for scoping, abstraction, and calculation. Sharing a single scoping system between JS, HTML and CSS removes the need for global symbols (classnames or ids) to link the two together. Abstractions in preprocessors are implemented by means of macros, and can lead to large file sizes.
- talmand 12y ago
  I'm sorry, but there will always be a need for classnames and ids for multiple reasons. A tool like this doesn't remove them from being used, it just partly removes them from the initial code. Proper usage of CSS preprocessors will result in much the same code that this tool will generate. Because in the end they both generate the same CSS.
  - boucher 12y ago
    That's not really the case. For one, it's incredibly easy to end up with very bloated CSS files if you use something like less/sass. But more importantly, those tools don't give you actual scoping. Although it's not necessarily the main way the author is suggesting interacting with this library, it can be used as a tool to apply inline styles directly to elements, which gives you total control over the scope of your styles.
    - talmand 12y ago
      If not done properly, anything code-related can result in bloated and inefficient code. I fail to see how introducing Javascript code that requires DOM manipulation is more efficient than a properly built style sheet. Injecting styles inline to elements is an even more inefficient way of doing things, you're likely to cause repaints all over the place during initial rendering. As I said elsewhere, if this were a system done on the back-end (or even in something like Grunt) so that it was part of a compiling process then it would have merit. But from what I'm seeing this appears to run only on the client side which I feel is a bad idea.
  - jhpriestley 12y ago
    The site seems to be down, I don't actually know the details about this particular tool. However, you're wrong that classnames and ids are always necessary. You can set the HTML "style" attribute directly when generating the view.
    - talmand 12y ago
      They can be necessary for reasons other than CSS. Trying to do most of them, including CSS, without the usage of classes and ids is just a strange notion. There are several different ways to handle CSS and each has their own pros and cons. But I'm assuming you're talking inline styles on the HTML elements directly? If so, while useful and I do it myself often, it is not optimum. If you're talking about injecting the styles on or before page load for that particular view, of course you can; but that doesn't mean anything different than what I've been saying at all. In the end it is still CSS and if it doesn't done properly in the beginning it will eventually cause problems.
  - malandrew 12y ago
    Not completely. With a virtual DOM based solution (which is where things are trending due to performance), the ids and classnames of HTML become far less relevant.
    - talmand 12y ago
      I agree, but that's tomorrow and in the end that only replaces classnames and ids with something else which will serve pretty much the same purpose. You have to have identifiers of some type, today it is classnames and ids; tomorrow it will be something else.
wmeredith 12y ago
I suspect if you're OK at CSS and great at JS, this would have some appeal. Conversely, if you're great with CSS and OK at JS, this will not. It doesn't help that in most of the examples the Javascript implementation is more complex than the css implementation.
- talmand 12y ago
  If you are bad at CSS and good at JS then this tool will not really help you. In the end it generates CSS, which you have to know to some degree to be able to create the JS version of it. I agree on the complexity issue with the examples, I don't see how the 30% savings claim would hold up.
  - oleg009 12y ago
    saving come from 1. code reuse. less/stylus will generate everything dozens of times 2. vendor prefixes are added effectively at runtime
    - talmand 12y ago
      CSS allows for code reuse, it always has. It's called cascading and classes. Preprocessors will generate bloated CSS if not coded properly, same as it's possible to hand-code bloated CSS. There are libraries that generate vendor prefixes at run time. If prefixes are really a bother (they're not as much anymore) then preprocessors and other compiling tools have solutions for that as well. Which will be more efficient for the browser.
      - oleg009 12y ago
        1. Stop assuming I am stupid. 2. I know code reuse technics in css, they are mentioned in the presentation. Cascades do not work for component based development. Adding multiple classes to an element leads to awkward code and also will lead to namespace conflicts if you don't name everything very specifically. 3. Vendor prefixes are there and will be used for new features too. They will not go away. Precompilers can't avoid generating all prefixed variants.

factorialboy 12y ago

Question: Much of the CSS may not be written by programmers. How would we make use of JSS in this case?

oleg009 12y ago
jss not harder than less/sass/stylus ... its declarative json syntax most of the time.

jacobr 12y ago

Nice project! The Cascade in CSS can be a real maintenance nightmare, and people seem to have very different ideas on how to handle encapsulation and modularization. After a while with React, I thought it would be nice to define all styles for a component in the same location (inside my Component JavaScript). Setting the `top` property of a popup in JavaScript, but `width` or whatever in a CSS file just feels weird. There's been some discussion about making this easier in React[1], but also resistance, so while waiting I wrote my own little library[2] (not React-specific), but it's not as feature rich as JSS. I think that the fact that many projects[3] like this are popping up is validating the idea. [1] https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/04%20-%20Inline%20Styles.md [2] https://github.com/jacobrask/marcssist [3] https://github.com/js-next/react-style https://github.com/tenphi/jcss https://github.com/chenglou/RCSS

colinramsay 12y ago
You can set top in CSS.
- lhorie 12y ago
  He means "top" as in "top-relative-to-scroll-position-when-the-modal-is-taller-than-the-screen-in-IE8"
  - colinramsay 12y ago
    Ah, well you'd still need something more powerful for that kind of thing to work. A constraints engine for example: http://gridstylesheets.org/ http://gridstylesheets.org/ If you're going to go to the trouble of writing a CSS processor, you could at least add in some really interesting ideas.
talmand 12y ago
Why is setting width of a popup in CSS weird?

mrcwinn 12y ago

No.

norcimo5 12y ago

Hell yes!

colinramsay 12y ago

Atwood's Law [1] kicking in here.... "Any application that can be written in JavaScript, will eventually be written in JavaScript". [1] http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/

lhorie 12y ago

vjeux (of React fame) gave a presentation on a similar system they were using at Facebook https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js "This-is-not-what-I-am-used-to" objections notwithstanding, it's certainly an interesting approach to solve some CSS issues.

talmand 12y ago

I'm sorry but I totally fail to see the problem that this is supposedly trying to fix. In the example provided, the problem is presented as a failure of cascading in CSS. But the problem as I see it, is in the structure of the HTML. The example is a component with a button inside a component with a button. Then global selectors are used which creates a result we don't want. Slide 11 states global selectors are a problem. Which they can be, if used improperly just like every other tool we have access to. So, the solution is to write Javascript that results in using classes. Which is what should have been done in the first place. So, instead of creating a proper class structure in the HTML it is suggested to use Javascript to create classes, inject style sheets into the dom, and inject classes into the HTML elements on page load? All to avoid using CSS properly? I'm sure this is a wonderfully coded project, has interesting ideas, and may be useful to some, but as a front-end developer I seriously doubt I would ever use this nor recommend it. I would suggest just learning CSS, it's not that hard. I would say that this type of project would be far more suited for a back-end library that generates stylesheets on the fly in an effort to maintain code efficiency. But doing all this in Javascript just seems to be about addressing people's attitude towards CSS and not about actual problems in CSS.

spion 12y ago
How does one properly use classes without making them global? Its either global or tied to your document hierarchy. And tied to a hierarchy is worse because it makes it harder to reuse a class outside that particular hierarchy without modifying the original selector...
- talmand 12y ago
  You don't. That's the whole point. The reason for classes is to reuse CSS properties for efficiency. If you are making classes that are strictly tied to your hierarchy in a way that prevents proper reuse, then it's being coded the wrong way. Using a tool to fix the improper usage of another tool is not the solution. If this tool is the solution, that the CSS it generates is the best way to do things, then why not code the CSS that way in the first place? EDIT: As I'm seeing elsewhere in this thread; why exactly is globals bad in CSS?

_lce0 12y ago

Now this is an interesting approach! Are there anyone using it in the wild?

imanaccount247 12y ago

"Fix toothpaste by making it out of feces"

zajd 12y ago

Pretty sure LESS/SASS already "fixed" CSS.

deleted 12y ago

[deleted]

semasad 12y ago

Ok, he can be talking seriously. The problem he try to fix is easily fixed with ANY CSS preprocessor, Stylus, Less, Sass...

ArtDev 12y ago

Use Javascript for CSS.. to process it out of LESS. LESS is Javascript but with certain limitations. If you don't like it, write your own. Or better yet, contribute.

ArtDev 12y ago

I only got a few slides in before it became obvious that he doesn't know CSS.

ttty 12y ago

This reminds me of https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS . It can be used with react.js and it just works ok.

chenglou 12y ago

The few past submissions on writing CSS in JS didn't seem to have picked up discussions. I'm glad this one at least does. I'm gonna go ahead and avoid repeating what's already mentioned in vjeux's presentation (https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js). Instead I'll focus on defending against the common "shortfalls" people tend to immediately point out with this approach. Designers will be uncomfortable with learning this: React's JSX has shown that (surprise surprise) designers can bear modifying markup with a little bit of code mingled in it. In this case, JS objects in their simplest form map very well to css declarations. I don't believe designers will be scared away by this at all. "Atwood's law", "we already have CSS", "stop reinventing CSS": no one's reinventing the idea of CSS; we're reinventing the implementation of it. Declaratively specify your layout is really nice, but you do want the backing of a real language to do so. Merging two styles is just a `merge()`, Overriding a style is just `bla.color = newColor` (assuming you don't mind the mutation; otherwise clone it or use persistent collections), and (!) reusing, importing, exporting styles is already solved with commonJS since you're working with normal js objects. We already have preprocessors: except preprocessors are there to solve the exact problem "CSS in JS" is solving. The difference is that the latter, again, uses a real, familiar language instead of inventing an ad-hoc new syntax like we've done countless times with HTML templates. And since preprocessors need to generate the final CSS beforehand, this limits lots of potentials such as looping more than, like, ten times. On this last point, I hope that none of the critics here used React's virtual DOM before; If you did, and are still complaining about writing CSS in JS, then you should go back and re-learn why the virtual DOM came to be. CSS in JS is the "virtual styling" equivalent for CSS. The potentials are huge (runtime feature detection for example). And this new layer allows us to map the neat, declarative style to something else than CSS: say, webGL. This is platform-independent; if anything, it's a nice conceptual model. (Disclaimer: I made https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS)

oleg009 12y ago
Thanks Cheng, you nailed it. Jss was actually inspired by your RCSS idea, I just wanted a different implementation. So thank you again. Some people here assume that I am stupid and didn't learn the css basics. This is just funny.

ttty 12y ago

Amazing (: I like the '&:hover': { part. Take a look at rcss https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS Your lib would be amazing to work with react.js. You would need to create the class names based on the contents instead of incrementing an id to make server side rendering faster. Take a look at rcss on how they do it.

rquantz 12y ago

You know what I've never thought? "The problem with CSS is that it is not imperative enough."