5 ms·

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 cascad

by 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?
  - 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.
- Sakes 12y ago
  The answer is LESS or SASS but for the love of god NOT JS. If you are concerned with breaking cascading then... .default-button(){ // properties } .component-a button { background-color: red; } .component-b button { .default-button(); color: green; }
  - spion 12y ago
    .default-button is still global in that example and may be accidentally overridden by someone working on another part of the site.
    - talmand 12y ago
      Which is actually quite true, but that problem lies with the person who overwrites the properties. That is not a problem in CSS. The most I would say that the HTML structure and CSS classes was not properly planned out to help prevent such things. It can be done, it's just most examples of this type of thing is more along the lines of "I want to do it my way!", which is not always a proper way to go about things.
      - spion 12y ago
        Its definitely not a problem with the person. That person may be working on a, say, date picker component (or something equivalent that is not yet covered with HTLM5) that provides minimal styling (with the ability to override it). They don't even know all their end-users. They decided to use the name `.calendar`. Was that safe? Nope, their user #3 had an "upcoming events" calendar using the same class name that totally breaks when the datepicker CSS is included on the page. Should they make sure to prefix all their class names with their name? What if someone else with the same name also decides to do this? What if they make a new alternate datepicker, must they add the version number/descriptor too? This is probably one of the reasons why we don't yet have separate reusable components with minimal overridable styles for the web (instead we have only entire pre-styled frameworks) If styles had scope and HTML had a way to import them, we could say `import calendar from "path/to/file"`, then use the calendar style on our component and be sure that there is no way its going to leak outside of outside its lexical scope. Web components will fix this (html imports, scoped stylesheets). But web components aren't ready yet. Let me ask you a different question though: is there a reason for the "oh god, not JS" sentiment? The solution is potentially even simpler than CSS: styles are defined as variables containing JSON objects, they're exported as a module, and can be imported and used by any component and mixed freely. No cascading/selector rules, no priorities, no overrides. When HTML CSS and JS share scope, things become much simpler.
lhorie 12y ago
Manually ensuring class names don't clash only scales so far. The problem this tries to address is the problem of maintainability when the entirety of the codebase doesn't fit in your head (because you have many people committing CSS at a fast pace, or a lot of junior devs, or because the codebase is large, or old, or the deadline is too tight, or any other number of reasons) There's a world of difference between Facebook with its hundreds of devs commiting code to the same codebase over the span of many years, vs an agency where it's typical for one frontend person to own the entirety of the CSS codebase for a month-long project. In the latter case, you usually don't need the ability to scale the team (or can get away with enforcing ad-hoc processes). In the former case, having tooling that enables non-clashing class names by default is worth the trade-offs.
- 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.
deleted 12y ago
[deleted]

by talmand 12y ago

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?
- 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.
Sakes 12y ago
The answer is LESS or SASS but for the love of god NOT JS. If you are concerned with breaking cascading then... .default-button(){ // properties } .component-a button { background-color: red; } .component-b button { .default-button(); color: green; }
- spion 12y ago
  .default-button is still global in that example and may be accidentally overridden by someone working on another part of the site.
  - talmand 12y ago
    Which is actually quite true, but that problem lies with the person who overwrites the properties. That is not a problem in CSS. The most I would say that the HTML structure and CSS classes was not properly planned out to help prevent such things. It can be done, it's just most examples of this type of thing is more along the lines of "I want to do it my way!", which is not always a proper way to go about things.
    - spion 12y ago
      Its definitely not a problem with the person. That person may be working on a, say, date picker component (or something equivalent that is not yet covered with HTLM5) that provides minimal styling (with the ability to override it). They don't even know all their end-users. They decided to use the name `.calendar`. Was that safe? Nope, their user #3 had an "upcoming events" calendar using the same class name that totally breaks when the datepicker CSS is included on the page. Should they make sure to prefix all their class names with their name? What if someone else with the same name also decides to do this? What if they make a new alternate datepicker, must they add the version number/descriptor too? This is probably one of the reasons why we don't yet have separate reusable components with minimal overridable styles for the web (instead we have only entire pre-styled frameworks) If styles had scope and HTML had a way to import them, we could say `import calendar from "path/to/file"`, then use the calendar style on our component and be sure that there is no way its going to leak outside of outside its lexical scope. Web components will fix this (html imports, scoped stylesheets). But web components aren't ready yet. Let me ask you a different question though: is there a reason for the "oh god, not JS" sentiment? The solution is potentially even simpler than CSS: styles are defined as variables containing JSON objects, they're exported as a module, and can be imported and used by any component and mixed freely. No cascading/selector rules, no priorities, no overrides. When HTML CSS and JS share scope, things become much simpler.

lhorie 12y ago

Manually ensuring class names don't clash only scales so far. The problem this tries to address is the problem of maintainability when the entirety of the codebase doesn't fit in your head (because you have many people committing CSS at a fast pace, or a lot of junior devs, or because the codebase is large, or old, or the deadline is too tight, or any other number of reasons) There's a world of difference between Facebook with its hundreds of devs commiting code to the same codebase over the span of many years, vs an agency where it's typical for one frontend person to own the entirety of the CSS codebase for a month-long project. In the latter case, you usually don't need the ability to scale the team (or can get away with enforcing ad-hoc processes). In the former case, having tooling that enables non-clashing class names by default is worth the trade-offs.

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.

deleted 12y ago

[deleted]