5 ms·

>> I think the whole community went to separating the HTML tag names from the styles and work only with class names [1]. I don't usually nitpick but I don't th

by ddoolin 12y ago

>> I think the whole community went to separating the HTML tag names from the styles and work only with class names [1]. I don't usually nitpick but I don't think one link is representative of the `whole community`. Just this thread seems to prove it's pretty divided on the issue. What is the recommendation, then? .collection .collection-item .collection-item-anchor? Genuinely curious here.

drinchev 12y ago
References : [1] http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/ http://www.smashingmagazine.com/2011/12/12/an-introduction-t... [2] http://bramsmulders.com/how-i-improved-my-workflow-with-smacss-sass.html http://bramsmulders.com/how-i-improved-my-workflow-with-smac... [3] https://github.com/davidtheclark/scalable-css-reading-list https://github.com/davidtheclark/scalable-css-reading-list I don't usually reply in this way, but this way of writing CSS has been proven to me in many hard to predict situations and is something that I would fight for in every possible way, everywhere I can. :D I've been part of large projects that if you don't follow some styleguide rules you end up with "!important" in your codebase. Which is bad. Scalable CSS writing ( even more important for a CSS framework that you use as a base ) consists of a more modular approach to your stylesheet. Let's say you have a list I would usually do it : <ul class='collection'> <li class='collection-item'> <a class='button button--primary'></a> </li> <li class='collection-item'>Normal Text</li> </ul> By doing this I can safely remove the .button, code ( module ) and put it somewhere else on my page without affecting how it will look like. Something more if I feel that I have a totally different link in this exact place, well yes. I would call it '.collection-item-link', because '.special-fancy-link' isn't semantic at all.
- rimantas 12y ago
  OOCSS, BEM and staff like that is just abuse of CSS. It is however widely used, because people are too lazy.
  - dsego 12y ago
    Nope, those techniques are attempts to squeeze at least something out of a really piss-poor tool that is CSS. Cascading is not a feature.
- exodust 12y ago
  * "and is something that I would fight for in every possible way, everywhere I can. :D" At my last job, fighting about CSS and dev processes sometimes overtook actual coding and design. I'm glad to be free of control-freak colleagues. Smart and nice control-freaks, but control-freaks nonetheless. <li class='collection-item'> No matter how you sell it, what you have here is a css tautology. It's a "list item", the element name is right there for all to see and use, including the machine. Yet, the first thing you do is give it a new slightly similar name "collection-item". And then the very next item you do it all again. And then to justify it all, call it "OOCSS" like it rolls off the tongue. The machine blinks but renders your tautology anyway. The machine has no say in what is the most sensible approach. On another example, let me say: There's nothing wrong with "#sidebar h3". A typical house might have a garage at the side. Still part of the house, but different and permanent enough to have its own ID. It has furniture inside, as does the house. But garage furniture serves a different purpose. The point is, #main and #garage are perfectly fine and make a lot of sense. "Skinning" and code re-use can be achieved in different ways using CSS. As long as there's a coherent logical approach, you can have skinning, performance and a maintenance friendly site without ever touching frameworks. The other thing is that repetition of some code is not a problem. We don't need to be OCD about a handful of repeating CSS rules. There is not usually any progression into wild, unruly CSS just because a few repeats are found here and there. Funny but ugly (and irrelevant) stuff in the smashingmag website HTML code... <li id="menu-item-2016" class="menu-item menu-item-type-taxonomy menu-item-object-post_tag menu-item-2016 menu-item-techniques"> CSS used "out of the box" is production-ready, and can perform incredibly well in all sorts of environments. CSS grids can be useful, but are not necessary. That's my opinion based on several years working in this area. If you think "CSS grids gone wrong" isn't a thing, then think again. I'm talking about long term maintenance of the site where the "grid" becomes this "thing that someone installed ages ago that may or may not get the special attention it requires in future". Grids are needy, they have dependencies that may get compromised over time depending who is working on the site and how the design evolves. They have limitations, and they have underlying complexity that works to give the illusion of simplicity. Personally I prefer my illusions in the content, not the code.
  - ahallock 12y ago
    > No matter how you sell it, what you have here is a css tautology. It's a "list item", the element name is right there for all to see and use, including the machine. The names are similar because they've created a general framework. They should have probably name-spaced the component as well with prefixes. Using class names creates a scope so your rules don't spill out and pollute everything else. It's like local variables in a function, and it's also a hack to behave more like XML. For example: <li class="product-sku"> is approximating: <sku> Maybe web components will fix this, but I'm not up-to-speed with that technology.

by ddoolin 12y ago

drinchev 12y ago

References : [1] http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/ http://www.smashingmagazine.com/2011/12/12/an-introduction-t... [2] http://bramsmulders.com/how-i-improved-my-workflow-with-smacss-sass.html http://bramsmulders.com/how-i-improved-my-workflow-with-smac... [3] https://github.com/davidtheclark/scalable-css-reading-list https://github.com/davidtheclark/scalable-css-reading-list I don't usually reply in this way, but this way of writing CSS has been proven to me in many hard to predict situations and is something that I would fight for in every possible way, everywhere I can. :D I've been part of large projects that if you don't follow some styleguide rules you end up with "!important" in your codebase. Which is bad. Scalable CSS writing ( even more important for a CSS framework that you use as a base ) consists of a more modular approach to your stylesheet. Let's say you have a list I would usually do it : <ul class='collection'> <li class='collection-item'> <a class='button button--primary'></a> </li> <li class='collection-item'>Normal Text</li> </ul> By doing this I can safely remove the .button, code ( module ) and put it somewhere else on my page without affecting how it will look like. Something more if I feel that I have a totally different link in this exact place, well yes. I would call it '.collection-item-link', because '.special-fancy-link' isn't semantic at all.

rimantas 12y ago
OOCSS, BEM and staff like that is just abuse of CSS. It is however widely used, because people are too lazy.
- dsego 12y ago
  Nope, those techniques are attempts to squeeze at least something out of a really piss-poor tool that is CSS. Cascading is not a feature.
exodust 12y ago
* "and is something that I would fight for in every possible way, everywhere I can. :D" At my last job, fighting about CSS and dev processes sometimes overtook actual coding and design. I'm glad to be free of control-freak colleagues. Smart and nice control-freaks, but control-freaks nonetheless. <li class='collection-item'> No matter how you sell it, what you have here is a css tautology. It's a "list item", the element name is right there for all to see and use, including the machine. Yet, the first thing you do is give it a new slightly similar name "collection-item". And then the very next item you do it all again. And then to justify it all, call it "OOCSS" like it rolls off the tongue. The machine blinks but renders your tautology anyway. The machine has no say in what is the most sensible approach. On another example, let me say: There's nothing wrong with "#sidebar h3". A typical house might have a garage at the side. Still part of the house, but different and permanent enough to have its own ID. It has furniture inside, as does the house. But garage furniture serves a different purpose. The point is, #main and #garage are perfectly fine and make a lot of sense. "Skinning" and code re-use can be achieved in different ways using CSS. As long as there's a coherent logical approach, you can have skinning, performance and a maintenance friendly site without ever touching frameworks. The other thing is that repetition of some code is not a problem. We don't need to be OCD about a handful of repeating CSS rules. There is not usually any progression into wild, unruly CSS just because a few repeats are found here and there. Funny but ugly (and irrelevant) stuff in the smashingmag website HTML code... <li id="menu-item-2016" class="menu-item menu-item-type-taxonomy menu-item-object-post_tag menu-item-2016 menu-item-techniques"> CSS used "out of the box" is production-ready, and can perform incredibly well in all sorts of environments. CSS grids can be useful, but are not necessary. That's my opinion based on several years working in this area. If you think "CSS grids gone wrong" isn't a thing, then think again. I'm talking about long term maintenance of the site where the "grid" becomes this "thing that someone installed ages ago that may or may not get the special attention it requires in future". Grids are needy, they have dependencies that may get compromised over time depending who is working on the site and how the design evolves. They have limitations, and they have underlying complexity that works to give the illusion of simplicity. Personally I prefer my illusions in the content, not the code.
- ahallock 12y ago
  > No matter how you sell it, what you have here is a css tautology. It's a "list item", the element name is right there for all to see and use, including the machine. The names are similar because they've created a general framework. They should have probably name-spaced the component as well with prefixes. Using class names creates a scope so your rules don't spill out and pollute everything else. It's like local variables in a function, and it's also a hack to behave more like XML. For example: <li class="product-sku"> is approximating: <sku> Maybe web components will fix this, but I'm not up-to-speed with that technology.