avoiding spacing helper classes

[Rick Lowes]

A colleague of mine who leads the html/css development for our site now has proposed something I'm looking for opinions about.

We're currently designing new page templates for our site, using lego-block style OOCSS component library/styleguide of objects - invariably what we are running into is that for a specific area of the page where we are placing an object like a button, or media objects, etc, we tend to need overrides on the default spacing or layout, due to the number of variations of page templates we need (yes, fewer page templates are our goal, but we still need a fair number of unique ones) - i.e. we need the object to have a little more margin or padding or floated left vs. right etc in one section of a page template vs. another. This has made it necessary to add spacing helper classes to our markup in some cases, which is frankly starting to look ugly, and is going to drive markup changes constantly as we update the design of the page templates going forward.

One thing he has suggested is adding a class for each major "chunk" of the page template, so that we could apply location-dependant padding/margin/layout type overrides to specifics object within that page chunk. Now while it could take a bit of work to figure out what level these classes should be at (i.e. how many page template "chunks" should have classes, how big are these chunks, etc) but we think this is doable. Bear in mind we are not using SASS or LESS or any of these types of tools currently because our dev team is simply not up to snuff on them yet, so we're looking for a solution that just uses plain CSS (i.e.no "mixin" type solutions).

Conceptually I think this does make sense since it we are somewhat separating the "object", which should be an encapsulated thing with the best defaults you can come up with (i.e. a single blue button with text), from the layout/position of that object within the page template/section - which is already likely to be affected by the page markup and it's position within the document (i.e. source order, adjacency to other objects, etc). Having these parent classes would allow you to target that object with different spacing etc if you needed it without having to add individual helper classes to each specific object, and filling your page with "mvn", "mbn", "ptl" which is where we are at currently.

What are your thoughts? thanks,

Rick

[Parker Ault]

This sounds a bit like the [BEM](http://bem.info/method/definitions/) naming convention, although I'm not completely sold on it.  In my experience, portability is king, even if it comes with a lot of verbosity and *gasp* ugly markup.  I would rather have verbose HTML – which is easy for everyone on the dev team to understand, even if it makes some eyes bleed – than convoluted or deeply nested CSS, which is a maintenance nightmare and requires a lot of deep domain knowledge.  In my opinion it's perfectly fine to have ugly markup if it decreases development time & complexity, increases portability, and allows you to get your product into your customers' hands more quickly.  It's a lot easier to give some spacing classes to your dev team and ask them to use them sparingly than to require them to kick the html back over to you every time they need to adjust some padding.  Don't let the perfect be the enemy of the good!

Parker

[Rick Lowes]

This is not really BEM - this is about creating a parent class that would be used for the particular section of the page, and using that as a way to target that item using decendant classes only for spacing/layout modifiers. So something like:

.a-certain-template-section .button {

     margin/padding/float

}

On Tue, Jul 16, 2013 at 1:39 PM, Parker Ault <parke...@gmail.com> wrote:

This sounds a bit like the [BEM](http://bem.info/method/definitions/) naming convention, although I'm not completely sold on it.  In my experience, portability is king, even if it comes with a lot of verbosity and *gasp* ugly markup.  I would rather have verbose HTML – which is easy for everyone on the dev team to understand, even if it makes some eyes bleed – than convoluted or deeply nested CSS, which is a maintenance nightmare and requires a lot of deep domain knowledge.  In my opinion it's perfectly fine to have ugly markup if it decreases development time & complexity, increases portability, and allows you to get your product into your customers' hands more quickly.  It's a lot easier to give some spacing classes to your dev team and ask them to use them sparingly than to require them to kick the html back over to you every time they need to adjust some padding.  Don't let the perfect be the enemy of the good!

Parker

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jamund Ferguson]

Hey Rick,

I also ran into trouble with the spacing classes. In my organization my team is primarily responsible for maintaining the CSS components and setting standards while other teams are in charge of a particular part of the website. With spacing classes being as flexible as they were the same pattern was being implemented differently on different parts o the site.

Even worse we did a major design overhaul (CSS only) and found the completely non-semantic spacing classes required huge amount of changes to our HTML (which required changes to tests, etc) and really took a lot of work. So much work in fact that we ended up ripping them out and replacing them with 2 things:

- We use grids everywhere

- We have only 2 spacing classes no (.p and .np) which means padding or no padding (actually it's margins, but whatever)

In terms of parts of the site specific stuff, I think you're setting up a trap for yourself and my suggestion is to keep trying to create generic components that meet the needs of the team otherwise it's going to be a maintenance nightmare (even in the short term!

Best of luck,

Jamund

--

[Parker Ault]

I understand.  My criticism of this approach is: you are buying slightly cleaner markup at the cost of added complexity and reduced portability in the CSS.  Instead of writing a few spacing utility classes and your base button styles once, you'll need to add a new layout class for each section you want to use it in.  In the end it's just a matter of preference, but I say it's better to move the complexity into the markup, which is usually write-and-forget anyway.

Parker