Comments on: Our (CSS) Best Practices Are Killing US http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/ A Term of Endearment Mon, 07 May 2012 17:31:22 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: How To Develop Scalable And Maintainable CSS | Van SEO Design http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-21316 How To Develop Scalable And Maintainable CSS | Van SEO Design Mon, 02 Apr 2012 12:33:01 +0000 http://www.stubbornella.org/content/?p=785#comment-21316 [...] time we question these flawed practices and those questions are leading us to ideas like OOCSS, SMACSS, and css [...] [...] time we question these flawed practices and those questions are leading us to ideas like OOCSS, SMACSS, and css [...]

]]> By: Large (and small) Scale CSS Architecture – Food for Thought. « .: scott.durnell :. http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-20871 Large (and small) Scale CSS Architecture – Food for Thought. « .: scott.durnell :. Fri, 16 Mar 2012 17:02:06 +0000 http://www.stubbornella.org/content/?p=785#comment-20871 [...] http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/ [...] [...] http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/ [...]

]]> By: Dan http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-20041 Dan Tue, 06 Sep 2011 17:56:52 +0000 http://www.stubbornella.org/content/?p=785#comment-20041 Is there another post where you explain why using IDs and descendant selectors is so bad? It's mentioned a few times here as if everyone already agrees that's the case. Is there another post where you explain why using IDs and descendant selectors is so bad? It’s mentioned a few times here as if everyone already agrees that’s the case.

]]> By: Jurij Burkanov http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-20024 Jurij Burkanov Thu, 28 Jul 2011 15:38:27 +0000 http://www.stubbornella.org/content/?p=785#comment-20024 Hello Nicole, I just discovered your blog and OOCSS idea and find them both absolutely great. Being a front-end developer myself I invented/ing my own philosophy, which is in may ways simular to yours (well, we all have to fight the same problems, at last). In my version, there are 3 main levels in document: a general template (some general blocks like header-body-footer), a structure (a set of positions / sizes that differentiates layouts of different pages) and elements, which are much like OOCSS modules and which can nest other elements as well. I also use namespaces, which are just a chain of classes in the body tag (simular to the breadcrumb) that allow me to speak the same elements differently, depending of their location: so I can have a generalized style for .headline and give it some variations on some specific sections of the site or single page. (Namespaces are created in .sass as variables). Where I go really differently is: all my "fresh" elements are isolated and can't be reused. For a good reason: many of them are existing only because designer wanted something "special" on some special page. So, all elements from the beginning are selected with namespace - this assures me, that it's styles would not appear on an other page a year later, when someone else creates an element with the same name or that it won't be re-written because of the same problem. If designer adds later another page, I usually just add it's namespace to list of the pages, where this styling must happen. If I see, that an element is being intensively used, I can delete namespace to "open" it's styling for the whole site, or just modify namespace by deleting one segment of the chain to "open" it for some part of the site (chain is = breadcrumb). I also use .sass partials and a composing file to have all elements styled with their own file, which lay in their folders tree (named after the class of the elements top-parent), which also represents layout structure - so it's supereasy to find place, where each element is styled. There are also a mix of naming / structuring conventions I use to be able to find elements easily. Hello Nicole, I just discovered your blog and OOCSS idea and find them both absolutely great. Being a front-end developer myself I invented/ing my own philosophy, which is in may ways simular to yours (well, we all have to fight the same problems, at last).
In my version, there are 3 main levels in document: a general template (some general blocks like header-body-footer), a structure (a set of positions / sizes that differentiates layouts of different pages) and elements, which are much like OOCSS modules and which can nest other elements as well. I also use namespaces, which are just a chain of classes in the body tag (simular to the breadcrumb) that allow me to speak the same elements differently, depending of their location: so I can have a generalized style for .headline and give it some variations on some specific sections of the site or single page. (Namespaces are created in .sass as variables). Where I go really differently is: all my “fresh” elements are isolated and can’t be reused. For a good reason: many of them are existing only because designer wanted something “special” on some special page. So, all elements from the beginning are selected with namespace – this assures me, that it’s styles would not appear on an other page a year later, when someone else creates an element with the same name or that it won’t be re-written because of the same problem. If designer adds later another page, I usually just add it’s namespace to list of the pages, where this styling must happen. If I see, that an element is being intensively used, I can delete namespace to “open” it’s styling for the whole site, or just modify namespace by deleting one segment of the chain to “open” it for some part of the site (chain is = breadcrumb). I also use .sass partials and a composing file to have all elements styled with their own file, which lay in their folders tree (named after the class of the elements top-parent), which also represents layout structure – so it’s supereasy to find place, where each element is styled. There are also a mix of naming / structuring conventions I use to be able to find elements easily.

]]> By: Got Messy CSS? You’re not Alone | NUCAP Blog http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-20016 Got Messy CSS? You’re not Alone | NUCAP Blog Wed, 13 Jul 2011 21:19:49 +0000 http://www.stubbornella.org/content/?p=785#comment-20016 [...] conference Sullivan calls out some so-called best practices of CSS that might in fact be part of the reason we end up with tangled CSS: It is time to let ourselves off the hook. There is nothing we could have done by trying harder. [...] [...] conference Sullivan calls out some so-called best practices of CSS that might in fact be part of the reason we end up with tangled CSS: It is time to let ourselves off the hook. There is nothing we could have done by trying harder. [...]

]]> By: Nicole Sullivan http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-19885 Nicole Sullivan Thu, 26 May 2011 00:38:54 +0000 http://www.stubbornella.org/content/?p=785#comment-19885 @El Guapo @Joshua Kincaid - I advise against reliance on specificity, not the cascade. The cascade rocks. @El Guapo @Joshua Kincaid – I advise against reliance on specificity, not the cascade. The cascade rocks.

]]> By: Canuck http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-19874 Canuck Tue, 24 May 2011 20:49:24 +0000 http://www.stubbornella.org/content/?p=785#comment-19874 I come from the SGML and XML worlds, so my background is almost 100% semantic. Warnings against "classitis" sound like silly noob fussing to me -- I'm glad you called it out. Why not keep things simple, as they were intended? an id identifies a specific instance of something (<em>this</em> paragraph, not <em>that</em> one). a class identifies a general type of something (an <em>overview</em> kind-of paragraph, not a <em>warning</em> kind-of paragraph. Lots of other SGML and XML document types allow both ids and some kind of class/type/category attribute, and people don't seem to have a problem understanding how to use them -- I'm not sure why the HTML <em>id</em> and <em>class</em> atts have caused so much gratuitous hair-pulling in the CSS world. I come from the SGML and XML worlds, so my background is almost 100% semantic. Warnings against “classitis” sound like silly noob fussing to me — I’m glad you called it out. Why not keep things simple, as they were intended?

an id identifies a specific instance of something (this paragraph, not that one).
a class identifies a general type of something (an overview kind-of paragraph, not a warning kind-of paragraph.

Lots of other SGML and XML document types allow both ids and some kind of class/type/category attribute, and people don’t seem to have a problem understanding how to use them — I’m not sure why the HTML id and class atts have caused so much gratuitous hair-pulling in the CSS world.

]]> By: Nicole Sullivan http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-19873 Nicole Sullivan Tue, 24 May 2011 19:41:42 +0000 http://www.stubbornella.org/content/?p=785#comment-19873 @Ryan You make a good point. It is definitely possible to be *too granular* with your classes. <code>float-left clear sidebar grid6</code> is an example of being too granular. @Ryan You make a good point. It is definitely possible to be *too granular* with your classes.
float-left clear sidebar grid6 is an example of being too granular.

]]> By: El Guapo http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-19872 El Guapo Tue, 24 May 2011 19:35:55 +0000 http://www.stubbornella.org/content/?p=785#comment-19872 @Joshua Kincaid I concur! This would have been infinitely more useful and less error prone than the cascade, which is automatic. I find it ironic that what was touted as a major feature of CSS( the cascade ) is advised against by such luminaries as Ms. Nicole. What I really, really wish for is an end to the dogmatic adherence to the way the web is built. Its now 20 years later, more or less, since the creation of HTTP, HTML, a little later CSS and javascript. Being shackled to old ideas that, while great for the day, are now so archaic and plain crappy for developing complex applications just sucks. I mean, really, a *document* format as an application platform? Really? Sure we have things like gmail, but would you really want to write something like that in HTML? Hats off the the Google devs who suffered through creating that. Anyway, I digress... CSS is just not cut out for the job, and with the long, long life of Microsoft browsers, we'll be suffering the sins of the past for decades to come. Wheeeee..... @Joshua Kincaid I concur!

This would have been infinitely more useful and less error prone than the cascade, which is automatic. I find it ironic that what was touted as a major feature of CSS( the cascade ) is advised against by such luminaries as Ms. Nicole.

What I really, really wish for is an end to the dogmatic adherence to the way the web is built. Its now 20 years later, more or less, since the creation of HTTP, HTML, a little later CSS and javascript. Being shackled to old ideas that, while great for the day, are now so archaic and plain crappy for developing complex applications just sucks. I mean, really, a *document* format as an application platform? Really? Sure we have things like gmail, but would you really want to write something like that in HTML? Hats off the the Google devs who suffered through creating that.

Anyway, I digress… CSS is just not cut out for the job, and with the long, long life of Microsoft browsers, we’ll be suffering the sins of the past for decades to come. Wheeeee…..

]]> By: Ryan http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/comment-page-1/#comment-19853 Ryan Fri, 20 May 2011 21:04:50 +0000 http://www.stubbornella.org/content/?p=785#comment-19853 From what I understand about an id - it is used once per page, so would it not make sense to use id's as the building blocks of your site? ex. id="header" or id="page-wrapper" Watching your video, I question a lot of the ways I have done css in the past, how things have evolved etc. I recently started using LESS (server side, no js) and quickly found that you really have to plan and analyze your sites much more than just creating with more standard css. Which in my mind is a good thing. I have found myself using a combination of head.js (without a lot of the garbage) as a hook for specific pages. So, I will create my classes that are most broad in scope, then target specific pages for differences. I can see where this can become very complicated as far as specificity for sure. However, I feel that by creating a bunch of classes to accomplish certain 'global" styles - ex. class="float-left clear sidebar grid6" And maybe I sort of missed some of your point in the video, but I feel when you get a element with 5-6 classes attached, you should just be using inline styles. At that point, any change you make you have to go in and fool with the html instead of just dealing with the css. My ultimate goal in any project, rather it's an online app or a website is to have the ability to completely change a layout without having to spend all my time in the html and do it mostly in the css. What are your thoughts? Am I completely missing the point? From what I understand about an id – it is used once per page, so would it not make sense to use id’s as the building blocks of your site? ex. id=”header” or id=”page-wrapper”

Watching your video, I question a lot of the ways I have done css in the past, how things have evolved etc. I recently started using LESS (server side, no js) and quickly found that you really have to plan and analyze your sites much more than just creating with more standard css. Which in my mind is a good thing. I have found myself using a combination of head.js (without a lot of the garbage) as a hook for specific pages. So, I will create my classes that are most broad in scope, then target specific pages for differences.

I can see where this can become very complicated as far as specificity for sure. However, I feel that by creating a bunch of classes to accomplish certain ‘global” styles – ex. class=”float-left clear sidebar grid6″ And maybe I sort of missed some of your point in the video, but I feel when you get a element with 5-6 classes attached, you should just be using inline styles. At that point, any change you make you have to go in and fool with the html instead of just dealing with the css.

My ultimate goal in any project, rather it’s an online app or a website is to have the ability to completely change a layout without having to spend all my time in the html and do it mostly in the css. What are your thoughts? Am I completely missing the point?

]]>