3 ms·

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 } .compon

by 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.
    - Sakes 12y ago
      I do have a reason for saying "oh god not JS". In my experience, the biggest reason people try and solve CSS issues with javascript is because they don't fully understand CSS and how to structure it in a maintainable way. I used to hate CSS. I still think it is very flawed, just google how to center something and watch all the blogs pop up. But rather than cursing it the rest of my dev days, I took the time to learn it and structure it properly. I now never spend longer than a few minutes trying to resolve a css bug. Ideas like the OPs only procrastinate someone's true problem, which is they don't know how to properly work with the technology that they are forced to work with.
    - talmand 12y ago
      Your example only shows to me problems in the person and/or the team doing the CSS coding. It is certainly possible to namespace CSS if guidelines are established at project start, just like with coding any other language. What happens if two developers namespace their class in the same way? The reason I would say no to a JS solution is simply because you are adding yet another step to the render of the page, more code for the browser to parse, and in the end results in the same issues you started with as they are only masked. This is just an attempt to make something work in a fashion it was designed to do. I'd rather fix the problem at the source instead of adding another layer to the problems. But in the end, no matter what fancy JS code that comes up it still has to render out the CSS exactly as the browser expects it to be. That means that whatever this thing generates, people who know CSS can hand-code the exact same thing. Any problems that exists for CSS exists in this as well, it just masked so it's not readily apparent.
      - spion 12y ago
        But what if there isn't a single cohesive team developing the website? There are no globally established practices for CSS name-spacing and there are multiple ways to do it (based on what tradeoffs you're willing to make). See font-awesome for an example of what I mean by library (yes, they prefix everything with `fa-` which is fine until the bootstrap team comes up with a FizzActivity widget in bootstrap, which you wont be able to use together with fontawesome) What happens if two developers namespace their class in the same way in JS? Well, with CommonJS this is pretty much impossible (import by path), and even without CommonJS there is no incentive to do it as you can easily pick a huge namespace without it affecting anyone. Just adding `var shortName = long.namespace.containing.shortName;` fixes the long name without that short name having effects anywhere else in the code or any of the inner functions (components) you may call, because... lexical scope. And sure, we can hand-code everything in assembly too - after all thats what compilers do anyway. But that doesn't mean that the higher level language has all the problems that assembly has. A tool like this can do a lot of the job for you, by generating unique names and letting you refer to them via any (variable) name you like.
  - deleted 12y ago
    [deleted]
- Sakes 12y ago
  I don't see the difference between your concern and being concerned with a green developer changing some base class (in java for example) without fully understanding how those changes will affect the rest of the application. You can introduce bugs that a compiler won't catch. It seems to me your main problem is how do you have people who don't know what they are doing perform like an experienced developer/designer.
ttty 12y ago
So you css will have the same structure as html.. Therefore why not putting your css in your html. Well, in this case you should put the css in the javascript module which renders the html and then the css.
- Sakes 12y ago
  The example I provided above aggressively overwrites any inherited CSS properties for some component B. Example 1: <div class="component-a"><button></button><div class="component-b"><button></button></div></div> Example 2: <div class="component-b"><button></button></div> Result: The <button> wrapped in div.component-b for both above examples will render exactly the same, ignoring html structure.

by Sakes 12y ago

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.
  - Sakes 12y ago
    I do have a reason for saying "oh god not JS". In my experience, the biggest reason people try and solve CSS issues with javascript is because they don't fully understand CSS and how to structure it in a maintainable way. I used to hate CSS. I still think it is very flawed, just google how to center something and watch all the blogs pop up. But rather than cursing it the rest of my dev days, I took the time to learn it and structure it properly. I now never spend longer than a few minutes trying to resolve a css bug. Ideas like the OPs only procrastinate someone's true problem, which is they don't know how to properly work with the technology that they are forced to work with.
  - talmand 12y ago
    Your example only shows to me problems in the person and/or the team doing the CSS coding. It is certainly possible to namespace CSS if guidelines are established at project start, just like with coding any other language. What happens if two developers namespace their class in the same way? The reason I would say no to a JS solution is simply because you are adding yet another step to the render of the page, more code for the browser to parse, and in the end results in the same issues you started with as they are only masked. This is just an attempt to make something work in a fashion it was designed to do. I'd rather fix the problem at the source instead of adding another layer to the problems. But in the end, no matter what fancy JS code that comes up it still has to render out the CSS exactly as the browser expects it to be. That means that whatever this thing generates, people who know CSS can hand-code the exact same thing. Any problems that exists for CSS exists in this as well, it just masked so it's not readily apparent.
    - spion 12y ago
      But what if there isn't a single cohesive team developing the website? There are no globally established practices for CSS name-spacing and there are multiple ways to do it (based on what tradeoffs you're willing to make). See font-awesome for an example of what I mean by library (yes, they prefix everything with `fa-` which is fine until the bootstrap team comes up with a FizzActivity widget in bootstrap, which you wont be able to use together with fontawesome) What happens if two developers namespace their class in the same way in JS? Well, with CommonJS this is pretty much impossible (import by path), and even without CommonJS there is no incentive to do it as you can easily pick a huge namespace without it affecting anyone. Just adding `var shortName = long.namespace.containing.shortName;` fixes the long name without that short name having effects anywhere else in the code or any of the inner functions (components) you may call, because... lexical scope. And sure, we can hand-code everything in assembly too - after all thats what compilers do anyway. But that doesn't mean that the higher level language has all the problems that assembly has. A tool like this can do a lot of the job for you, by generating unique names and letting you refer to them via any (variable) name you like.
- deleted 12y ago
  [deleted]
Sakes 12y ago
I don't see the difference between your concern and being concerned with a green developer changing some base class (in java for example) without fully understanding how those changes will affect the rest of the application. You can introduce bugs that a compiler won't catch. It seems to me your main problem is how do you have people who don't know what they are doing perform like an experienced developer/designer.

ttty 12y ago

So you css will have the same structure as html.. Therefore why not putting your css in your html. Well, in this case you should put the css in the javascript module which renders the html and then the css.

Sakes 12y ago
The example I provided above aggressively overwrites any inherited CSS properties for some component B. Example 1: <div class="component-a"><button></button><div class="component-b"><button></button></div></div> Example 2: <div class="component-b"><button></button></div> Result: The <button> wrapped in div.component-b for both above examples will render exactly the same, ignoring html structure.