4 ms·

Creating a more verbose and complicated tool won't solve the problems you describe, they are still there but only masked until it becomes an even bigger problem

by talmand 12y ago

Creating a more verbose and complicated tool won't solve the problems you describe, they are still there but only masked until it becomes an even bigger problem. I would be the first to agree that there are problems with CSS, I use it nearly every day and I run into these problems quite a lot. But moving to the JS to attempt to solve these problems is taking several steps backwards to me. All the problems you list in your example I would say exist as potential problems in any other aspect of a large-scale project. In most of the examples I've seen the problem seems to be giving developers who don't know CSS access to CSS and then wonder why it eventually falls apart.

teleclimber 12y ago
I agree that solving these problems at a higher level would work better than this. Scoped CSS[1] would have been a good start, but unfortunately it looks to be in trouble (removed from Chrome).[2] [1] https://html.spec.whatwg.org/multipage/semantics.html#attr-style-scoped https://html.spec.whatwg.org/multipage/semantics.html#attr-s... [2] https://www.chromestatus.com/features/5374137958662144 https://www.chromestatus.com/features/5374137958662144
ttty 12y ago
Please admit that css is a mess. You can't have proper modules that you just plugin in. I want a button styled a way... it will mix with some other default button. I have to create many button classes.
- talmand 12y ago
  I admit CSS is a mess, I've never denied it. I simply disagree that a system similar to this approach actually solves anything in the long run. But you can have proper modules that you just plugin. If you plop in your button and it conflicts with someone else's button; then one of you did it wrong. The solution is to create multiple button classes as you say, but this Javascript solution does the exact same thing.
  - ttty 12y ago
    >but this Javascript solution does the exact same thing. But with this lib I don't care about classes. I just put thing in, and I have 0 conflicts. I can do whatever I want and no conflicts. Try that in css. Also take a look at react.js this lib is perfect fit for that.
    - malandrew 12y ago
      Yup. Pretty much any virtual-dom approach benefits from this type of solution. Furthermore, if you adopt any sort of system on top of the v-dom approach that does layout management with CSS 3D matrices like famo.us does, you end up greatly benefiting from a solution like this as well. Cascading doesn't work really that well if you don't have explicit and persistent semantic nesting all the way down the tree of elements in a window.
    - talmand 12y ago
      The code you write doesn't care about classes, but the CSS that is generated does. Why not do it the CSS way from the beginning and take JS out of the equation altogether so that everything is more efficient? The most common answer I've seen is "because I don't want to learn CSS", which I don't feel is a good enough answer. I can write CSS all day using classes that do not conflict in the manner described.
      - spion 12y ago
        There is another answer pointed out multiple times throughout this thread which is "because name clashes happen if we want to write components in isolation from other teams". Its just that the "writing separate components" part never happens exactly because the infrastructure doesn't support it (except in situations of dire need like fontawesome), so there are "no problems" :)
lhorie 12y ago
I'm not claiming this or the vjeux's system (from the presentation link in my other post) are silver bullets, just that they are attempts to solve this specific problem. I'd argue that the reasons presented in vjeux's presentation are not of the clueless-developers-writing-crappy-css variety, although I do concede Facebook-scale problems are not common in the industry. Personally, I agree that deviating from CSS syntax is not a viable solution for a large number of cases, and neither of those solutions is perfect. I just think it's cool that people are experimenting with different ways of creating collision-resistant styling tools, rather than sticking w/ the status quo.
- talmand 12y ago
  I think they are interesting as well, but if I see a problem being created in an attempt to address a problem then I say so. I'm sure many of the thoughts and ideas of such projects can be integrated into CSS to make it better, but they will be integrated into CSS. I would propose the author take this system and roll it into Grunt, or similar, where it would be much more useful as opposed to client side. You should see from my other comments on this topic that the majority of my objection is that it is a client-side solution which I think is the wrong approach.

by talmand 12y ago

teleclimber 12y ago

I agree that solving these problems at a higher level would work better than this. Scoped CSS[1] would have been a good start, but unfortunately it looks to be in trouble (removed from Chrome).[2] [1] https://html.spec.whatwg.org/multipage/semantics.html#attr-style-scoped https://html.spec.whatwg.org/multipage/semantics.html#attr-s... [2] https://www.chromestatus.com/features/5374137958662144 https://www.chromestatus.com/features/5374137958662144

ttty 12y ago

Please admit that css is a mess. You can't have proper modules that you just plugin in. I want a button styled a way... it will mix with some other default button. I have to create many button classes.

talmand 12y ago
I admit CSS is a mess, I've never denied it. I simply disagree that a system similar to this approach actually solves anything in the long run. But you can have proper modules that you just plugin. If you plop in your button and it conflicts with someone else's button; then one of you did it wrong. The solution is to create multiple button classes as you say, but this Javascript solution does the exact same thing.
- ttty 12y ago
  >but this Javascript solution does the exact same thing. But with this lib I don't care about classes. I just put thing in, and I have 0 conflicts. I can do whatever I want and no conflicts. Try that in css. Also take a look at react.js this lib is perfect fit for that.
  - malandrew 12y ago
    Yup. Pretty much any virtual-dom approach benefits from this type of solution. Furthermore, if you adopt any sort of system on top of the v-dom approach that does layout management with CSS 3D matrices like famo.us does, you end up greatly benefiting from a solution like this as well. Cascading doesn't work really that well if you don't have explicit and persistent semantic nesting all the way down the tree of elements in a window.
  - talmand 12y ago
    The code you write doesn't care about classes, but the CSS that is generated does. Why not do it the CSS way from the beginning and take JS out of the equation altogether so that everything is more efficient? The most common answer I've seen is "because I don't want to learn CSS", which I don't feel is a good enough answer. I can write CSS all day using classes that do not conflict in the manner described.
    - spion 12y ago
      There is another answer pointed out multiple times throughout this thread which is "because name clashes happen if we want to write components in isolation from other teams". Its just that the "writing separate components" part never happens exactly because the infrastructure doesn't support it (except in situations of dire need like fontawesome), so there are "no problems" :)

lhorie 12y ago

I'm not claiming this or the vjeux's system (from the presentation link in my other post) are silver bullets, just that they are attempts to solve this specific problem. I'd argue that the reasons presented in vjeux's presentation are not of the clueless-developers-writing-crappy-css variety, although I do concede Facebook-scale problems are not common in the industry. Personally, I agree that deviating from CSS syntax is not a viable solution for a large number of cases, and neither of those solutions is perfect. I just think it's cool that people are experimenting with different ways of creating collision-resistant styling tools, rather than sticking w/ the status quo.

talmand 12y ago
I think they are interesting as well, but if I see a problem being created in an attempt to address a problem then I say so. I'm sure many of the thoughts and ideas of such projects can be integrated into CSS to make it better, but they will be integrated into CSS. I would propose the author take this system and roll it into Grunt, or similar, where it would be much more useful as opposed to client side. You should see from my other comments on this topic that the majority of my objection is that it is a client-side solution which I think is the wrong approach.