Code Re-use on CSS and HTML - Debate

Hello all,

I careful consider this forum opinions. I have some doubts that I will try to expose the best I can, hoping that I can clear my head over this subjects a little bit more.

As you may know, grids are really important on a graphic design point of view.
Regardless if you are designing a book (where grids more clearly make sense) or web site, otherwise, you will never make a web portal like Yahoo or any major news website were you have a bunch of articles and you have to visually organize the all thing. Or can you?

On this circumstances, visual proportion is not just a math concept, is a human one.

I’m trying to re-use code on CSS and HTML. The question is, the line that separates what you can reuse and what you can’t, seems to be really thin.

“CSS Frameworks” it’s something that I read. (only). I see people telling and repeating how “fast” it is. I doubt. Really.
It’s fast when you are laying out a page with two columns and 3 divs and write a <p> there telling: “Look how fast this is?!”. But once you get deeper and deeper, on one layout, it could become a nightmare to understand and to fix. At the very end, I presume, we will trying to fix the “grid” instead of CSS and HTML markup.
Since I’m not that CSS proficient, I mean, I work with CSS for some years now, I can make may way to flexible layout, but I cannot say I know the inner guts of it, because I don’t, so, since I’m not that CSS proficient, I believe using pure CSS is a wise choice here.

I’m thinking about creating a CSS file with:


	BASE - redefinitions over default layout engines decisions

	MAIN MENU- at least the basics like text-decoration: none; and so forth.

	FORMS - without making any "positional guesses" nor bloating the all thing with shadows.


Considering those points, I would like to generally launch this debate about what do you re-use (if anything), on your CSS files? And, related to this, how do you deal with the massive amount of “responsive websites” that you should start developing more and more often?

Thank you very much.


You seem to be asking two main questions here. The first question seems to be whether to use frameworks/grids or to build them yourself and the second question seems to be about building re-usable css.

The answer to the first question is not always straight forward as it depends on the actual job in hand. If you are creating a “one-man-band” website where you are the sole coder then in most cases you don’t need a grid or framework to help you as setting up a a few columns in basic CSS takes minutes and minimal code. Most of us already have our default templates set up and ready to go with all the code that we need and like for the task in hand anyway.

If on the other hand you are part of a team and building a large website with multiple components then frameworks/grids (like bootstrap) can standardise the process and make the job much easier and quicker but at the cost of some code bloat. Bootstrap for example has all the components you will likely ever need built into it and it’s a few seconds work to throw in a nav that scales responsively and magically turns into a dropdown for mobile. Or create popups, dropdown menus, collapsible menus and many other things with a few keystrokes or a simple copy and paste. This allows you to build large, solid and reliable sites quite easily and quickly as long as you stick to the basic defaults.

The other benefit of a grid is that all the other members in the team must use the same format and so standardises the process so that you don’t get so much spaghetti code being passed back and forwards - although you can never guarantee that…

On the other hand if the project in hand is very stylised and not “grid friendly” then it can take longer to build as you have to bend the framework to fit. The other downside of a framework is that there is a steep learning curve and you have to get used to someone else’s way of coding.

In answer to your second question the secret of using reusable code is to abstract and standardise the elements that you use so that you don’t reinvent the wheel on every page. Don’t be too specific with your rules e.g.

nav #nav li strong{background:red}

when something like


Is much more usable even though it means adding a class to the strong element.

Don’t be afraid to add classes!

The number of times I’ve used things like #main p{margin:0 2em} and then need to make special cases for other p elements and need to over-qualify it again #main p.special{margin:0}. It would have been much better just to have added a class to the p element to start with. The other problem with specificity like the former example is that it hits all p elements in that section and who knows in the future what else may be added into that section. You may have a re-usable snippet that fits nicely into that section but it then gets hit by the rules cascading from above.

There is a time and place for being specific but usually within smaller contexts where you are happy that things won’t change.

When you build an element that is being used across a site then create the basic standard structure first and then you can if required modify that structure where needed with a modifier class. If you do this carefully you will not need to cancel styles out but just add to them instead. (It also helps to tell your designers not to change the element on every page just because they think it looks neat).

As far as media queries go then I’ve completely changed my approach and I no longer contain all the rules in a single media query for each layout. I use multiple media queries throughout the stylesheet and I include them right after the element (or a suitable group of elements). If I build a container then I will give that container the rules it needs for all viewport widths then and there and not hide it away miles away from the section it refers to.


normal styles here......
/* media query for that rule goes here here */
@media screen and (max-width:980px) {	
.test{tyles here....}

.more styles{
more page styles here..

It does mean you have more code but you end up with a more logical approach and one that is easy to construct as you go and easier to modify later. If you use the old method then it becomes almost a separate job where you build the main layout first and then you go and make the alternate versions. The problem with this is that it may be too late to make something work if you wait until the end. Therefore build and test each element as you go across the viewport width and adjust html and css until it works and then move on to the next element.

That’s just a few thoughts off the top of my head and probably not as well presented as it should have been :slight_smile:

Thanks a lot for sharing your thoughts here.

At the bottom line, I’m thinking about time. And ways we may have to develop faster CSS and HTML. At least that’s the main goal:
Trying to figure out, what ways other fellow “cssers” may have to develop faster, future proof and easily maintainable, code. :slight_smile:
As far as I can judge myself, I’m doing it very slowly. :frowning:

You’ve presented some nice ideas, among them:
a) consider frameworks for consistency.
b) use classes. They are cheap, and allow you to create a more re-usable changeable layouts.
c) don’t place your media queries on the very end. Code and test. Test and code.

Regarding c), can I ask you, what does the designer gives you?
I mean, do they made the layout based on some defined width, or they give you the high-fi prototypes for ALL devices the site is intended to work with? Or they give you nothing of this, and it’s up to you to judge where the layout should drop and how should it drop? (I’m saying “drop” but I could also think of “build” in case of mobile first approach).

Regarding a), I still have many doubts about consistency if, again, we think in terms of time. Consistency towards code leads to a faster time in development. And frameworks provide that. I agree. But frameworks also provide “extra stuff”. I don’t feel something like this is easier (and faster) to maintain:

<div class="col-sm-6 col-md-5 col-md-offset-2 col-lg-6 col-lg-offset-0">

Despite this, I’m still willing to learn and to try new methods that help me go faster on this css development. And if frameworks are that thing, I may turn my head into them but, as far as I can tell, on a long run, they don’t seem very “much” faster as far as I can tell, but perhaps you or anyone more experience them me can prove me wrong.

Thanks a lot for this privilege of learning and debating.

Most of my work is from clients as I am not a designer as such (just a csser and htmler) and therefore I work from designs given to me. So far all the PSDs I have been given have been based on fixed width and its been up to me to turn them into responsive layouts. When I see the psd for the first time I will make notes and say what is and isn’t possible and what will need to happen to make the page scale and so on. Some designs are just too brittle so you just have to say that they are not viable unless they just want a fixed width layout.

Usually good clients will understand but sometimes ignorant ones will want it to look exactly like the drawing on all devices and widths so you have to educate them or leave them well alone.

It’s often not very hard to spot how a layout needs to change for smaller devices and relatively small tweaks as you progress can create a layout that scales nicely. It does get hard if the site is image heavy and the images are large or if there are large data tables as they just won’t scale well and you need to come to a compromise.

Regarding a), I still have many doubts about consistency if, again, we think in terms of time. Consistency towards code leads to a faster time in development. And frameworks provide that. I agree. But frameworks also provide “extra stuff”. I don’t feel something like this is easier (and faster) to maintain:

<div class="col-sm-6 col-md-5 col-md-offset-2 col-lg-6 col-lg-offset-0">

The problem with code like that is that if you don’t understand the framework then its hard to debug. On the other hand anyone who knows the framework will understand exactly what it does and how to change it and which classes to add/remove. I dislike so many classes like that but occasionally there is a need to modify a rule but 99% of the time you need to keep it simpler than that with only 2 or 3 classes.

When you write your own code you will fully understand something like this:.

<div class=“highlight mainhighlight expenses”>

But others on the team won’t and may have used the same classes elsewhere or used different classes for the same job. So you do need to create your own consistency in a similar way that frameworks do and stick to it.

And if frameworks are that thing, I may turn my head into them but, as far as I can tell, on a long run, they don’t seem very “much” faster as far as I can tell, but perhaps you or anyone more experience them me can prove me wrong.

For 99% of my work I use my own code and would not use a framework but on larger projects where the client has a team who are familiar with a framework then it makes sense to use one. As I said earlier (IMO) frameworks are faster to build if you use their defaults but if your design isn’t built with that framework in mind then it could be a long haul.

I’ve just created about 100 pages for a client using bootstrap and despite my grave reservations it was actually quite easy to work with after the initial learning curve. Of course the code base is many times larger that it would have been had I created it from scratch but as it contained a lot of interactive components it was much simpler using bootstrap. The dynamic elements worked much more smoothly than my own jquery routines (of which I am a beginner). I did not use many of the grids though and usually just used a fluid wrapper or a couple of simple columns (span8 span4) and then stuck my own code inside.

In the end its up to you and some people will swear by frameworks and others avoid them like the plague. It may be worth your time just downloading bootstrap and playing around with it for a few days. It will only cost you time and then you can make a better decision on what you want to do.

In the end its just html and css (and jquery).