4 ms·

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 hi

by 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?

spion 12y ago
Globals make it impossible to reason about separate components in isolation. What classname can I use for this button? Can I use '.button'? What if someone else already uses '.button'? Who knows...
- nawitus 12y ago
  You can namespace all CSS rules. It's annoying in CSS, but really easy in LESS and SASS. e.g. my-namespace { .button { color: red; } .another-button { color: blue; } } The namespace can be a custom element name, a class or an ID. The problem with this approach is that you need to declare the namespace in DOM somehow, and depending on the project that can either be easy or rather difficult. I used this technique when I ported a stand-alone application with classes just like ".button" to be a single page in a larger application, and it worked fine. Anyway, I do think that CSS should have a proper solution to modularization. EDIT: Now that I could open the link (it didn't open for me previously), I now see that this approach doesn't solve the problem with the article, since it doesn't support nested namespaces. (Although a hacky solution would be a 'reset all rules' helper in the inner namespace).
  - talmand 12y ago
    I have a project now, with multiple developers, that uses this system; we've never had any conflicts in our CSS and I seriously doubt we ever will. It's mostly component driven with the occasional global selector. As for your example not working with the approach, that's one of the problems as I see it with these solutions. The fancy, complicated approach apparently doesn't support one of the basics of CSS which would go a long way to fixing the problem as they see it.
  - ttty 12y ago
    What if component A and component B need that button? You will comp-a,comp-b{.button{}}? Will you save in comp-a-and-comp-b.scss? What if you need in comp-c and comp-d? As you can see your button is not tight to that comp. I prefer to have a button class, for example in react that when instanced renders all the time the same. It boundles it's css within, just like this lib.
    - nawitus 12y ago
      You could use the namespace feature of Less for that: http://lesscss.org/features/#features-overview-feature-namespaces-and-accessors http://lesscss.org/features/#features-overview-feature-names... I haven't personally used it, though. Another solution would be have a "button.less" like this: comp-a, comp-b, comp-c { .button { } }
    - talmand 12y ago
      There's nothing stopping you from doing any of that with CSS today, especially if you use SASS or LESS.
      - Offler 12y ago
        SASS and LESS are CSS DSLs, you are doing limited programming with CSS, at that stage you may as well do programming in a Turing complete language like JS and reduce the number of tools in your tool chain.
dugmartin 12y ago
As spion says with web components on the horizon, and with current frameworks like React, having classnames live in the global namespace makes creating reusable components that don't clash with other components impossible. I have a hunch some consensus will evolve that will use Java/AS3 namespace prefixes to enable sharing, so instead of .button you'll have something like .com-github-dougmartin-button.
- talmand 12y ago
  Or even better, namespace the classes with nesting; which you can today with or without a prepocessor. Such verbose classnames is not necessary.
  - spion 12y ago
    Yes, namespacing is the best currently available option. Unfortunately its only an approximation of lexical scope, as the example in the presentation shows (the one with the two red buttons). True, this is not something that happens often, and we can mostly get away with namespaces. But that's not the point. The point is that lexical scope is a tried and proven (by years of research, in multiple languages) solution to this problem which doesn't have any of these quirks. And JS has lexical scope.
    - talmand 12y ago
      The example with the two buttons is inherently flawed and is a bad example. It specifically creates an easily preventable problem in an effort to show a solution to that problem. There is nothing that this library can do that I cannot hand-code in CSS myself. Because it has to generate the CSS that the browser expects to get, which is not hard to do.
  - spion 12y ago
    Yes, namespacing is the best currently available option. Unfortunately its only an approximation of lexical scope, as the example in the presentation shows (the one with the two red buttons). True, this is not something that happens often, and we can mostly get away with namespaces. But that's not the point. The point is that lexical scope is a tried and proven (by years of research, in multiple languages) solution to this problem which doesn't have any of these quirks. And JS has lexical scope.

by talmand 12y ago

spion 12y ago

Globals make it impossible to reason about separate components in isolation. What classname can I use for this button? Can I use '.button'? What if someone else already uses '.button'? Who knows...

nawitus 12y ago
You can namespace all CSS rules. It's annoying in CSS, but really easy in LESS and SASS. e.g. my-namespace { .button { color: red; } .another-button { color: blue; } } The namespace can be a custom element name, a class or an ID. The problem with this approach is that you need to declare the namespace in DOM somehow, and depending on the project that can either be easy or rather difficult. I used this technique when I ported a stand-alone application with classes just like ".button" to be a single page in a larger application, and it worked fine. Anyway, I do think that CSS should have a proper solution to modularization. EDIT: Now that I could open the link (it didn't open for me previously), I now see that this approach doesn't solve the problem with the article, since it doesn't support nested namespaces. (Although a hacky solution would be a 'reset all rules' helper in the inner namespace).
- talmand 12y ago
  I have a project now, with multiple developers, that uses this system; we've never had any conflicts in our CSS and I seriously doubt we ever will. It's mostly component driven with the occasional global selector. As for your example not working with the approach, that's one of the problems as I see it with these solutions. The fancy, complicated approach apparently doesn't support one of the basics of CSS which would go a long way to fixing the problem as they see it.
- ttty 12y ago
  What if component A and component B need that button? You will comp-a,comp-b{.button{}}? Will you save in comp-a-and-comp-b.scss? What if you need in comp-c and comp-d? As you can see your button is not tight to that comp. I prefer to have a button class, for example in react that when instanced renders all the time the same. It boundles it's css within, just like this lib.
  - nawitus 12y ago
    You could use the namespace feature of Less for that: http://lesscss.org/features/#features-overview-feature-namespaces-and-accessors http://lesscss.org/features/#features-overview-feature-names... I haven't personally used it, though. Another solution would be have a "button.less" like this: comp-a, comp-b, comp-c { .button { } }
  - talmand 12y ago
    There's nothing stopping you from doing any of that with CSS today, especially if you use SASS or LESS.
    - Offler 12y ago
      SASS and LESS are CSS DSLs, you are doing limited programming with CSS, at that stage you may as well do programming in a Turing complete language like JS and reduce the number of tools in your tool chain.

dugmartin 12y ago

As spion says with web components on the horizon, and with current frameworks like React, having classnames live in the global namespace makes creating reusable components that don't clash with other components impossible. I have a hunch some consensus will evolve that will use Java/AS3 namespace prefixes to enable sharing, so instead of .button you'll have something like .com-github-dougmartin-button.

talmand 12y ago
Or even better, namespace the classes with nesting; which you can today with or without a prepocessor. Such verbose classnames is not necessary.
- spion 12y ago
  Yes, namespacing is the best currently available option. Unfortunately its only an approximation of lexical scope, as the example in the presentation shows (the one with the two red buttons). True, this is not something that happens often, and we can mostly get away with namespaces. But that's not the point. The point is that lexical scope is a tried and proven (by years of research, in multiple languages) solution to this problem which doesn't have any of these quirks. And JS has lexical scope.
  - talmand 12y ago
    The example with the two buttons is inherently flawed and is a bad example. It specifically creates an easily preventable problem in an effort to show a solution to that problem. There is nothing that this library can do that I cannot hand-code in CSS myself. Because it has to generate the CSS that the browser expects to get, which is not hard to do.
- spion 12y ago
  Yes, namespacing is the best currently available option. Unfortunately its only an approximation of lexical scope, as the example in the presentation shows (the one with the two red buttons). True, this is not something that happens often, and we can mostly get away with namespaces. But that's not the point. The point is that lexical scope is a tried and proven (by years of research, in multiple languages) solution to this problem which doesn't have any of these quirks. And JS has lexical scope.