CODEWITHSUNDEEP
htmlcssdry
Alex
Alex

Reputation: 1247

CSS vs DRY

You're creating an HTML layout. Let's assume that you don't need the benefits of multiple stylesheets, that a small increase in HTML size is not a concern, and that you have a style which will only be used once. I'm often in favour of using an inline style here, as I view the repetition of your CSS class name or ID as the cost of an abstraction you don't currently need, and may not ever use.

Standard doctrine these days is to always create HTML layouts using semantic markup and CSS styles, so am I missing something here? Please let me know your thoughts.

Upvotes: 1

Views: 1895

Answers (6)

brianpeiris
brianpeiris

Reputation: 10795

Ideally your CSS should be "Object Oriented" (at least, as OO as CSS can be). You should "inherit" from classes that set common properties and create new classes when you define properties that could be used elsewhere.

Take a look at the OOCSS project which is trying to espouse these principles (or re-introduce them as it were).

To quote Welbog:

... It seems to me that "OOCSS" is just CSS that isn't written haphazardly. Much the same way you can write non-object-oriented designs in OO languages, you can easily mess up the fundamental ideals upon which CSS was created. OOCSS seems to be saying, "Let's not screw up anymore, guys."

Upvotes: 5

jacobangel
jacobangel

Reputation: 7006

"A foolish consistency is the hobgoblin of little minds"

So, in this case is which is the foolish consistency? :) Why does DRY take precedence over the separation of markup and style?

Can you be sure that your CSS rule will only be used once? More over, how can you be sure that it won't need to be changed in the future, and how can you be sure that you would be the person needing to make the change? Are you sure you even need to add a class or id to target this unique element?

I guess I am having trouble seeing how adding 

<input type="submit" style="border: 1px solid red;"/>

is some how "superior" to 12 or so more characters

<input type="submit" class="b-red">

.b-red {border: 1px solid red;}

or to a potentially equivalent character count

input {border:1px solid red;}

Of course there are situations where every rule of thumb can and should be violated. The question is, what do you gain from following DRY that outweighs the importance of following markup/style dichotomy?

Upvotes: 0

CodeJoust
CodeJoust

Reputation: 3810

Personally, I've found that I have an element or two and I would put an inline style in, go back and see that I need more than that element, so I'd change it to a class or forget about it and be not able to change it.

You could also try putting a certain div / page class, and write descendent styles for that in the stylesheet instead of inline elements.

Also, if you ever decide to add javascript, you won't already have a well-labeled class there and you'll need to change it.

Usually this isn't much problem with dynamically generated websites, but it can become a large problem when you go overboard and have tons of inline tags to switch out. It also can make it harder for people if they wish to disable styles for accessability etc-- you usually can overcome this by using a class.

Say, using <b style="color:red">bold</b> instead of body.products div b {color:red}.

I'm personally a fan of selectors, not using too many classes. They are more reusable, and you can edit the whole site in one place with the stylesheets.

But this is overkill <p style="font-weight:bold;font-size:1.2em; text-index:20px;">Indented Bold Paragraph</p> so it this <p class="indent bold larger">text</p> instead you can do

or ``<p><b></b></p>.

Upvotes: 0

Steve Harrison
Steve Harrison

Reputation: 125640

One advantage of keeping the HTML and CSS separate is that you can re-skin the webpage without changing any of the HTML.

Steve

Upvotes: 3

rndmcnlly
rndmcnlly

Reputation: 1618

Even if you only use a particular style once there are still benefits to keeping it with your other styles and not putting it inline. First, there is the separation of concerns that leads to improved maintainability. If you know you are going in to make only a style change, there is a single place to look for any changes. Another benefit is the self-documentation from having to type out the class name. By giving that style a name, even though it is used once, it makes the semantic code below more declarative -- you can read that not only is this random p a paragraph, it is also, say, the intro paragraph.

This is, of course, assuming that you are never going to use that particular style again. If you might than there is even more reason to factor it out into a named style. Inline styles aren't evil, but they are somewhat of a gateway drug.

Upvotes: 10

Paolo Bergantino
Paolo Bergantino

Reputation: 488664

There are some situations in which I usually neglect creating a new class for a simple style change on a single element. It is usually pretty clear when you are doing it that there's a low-to-zero chance of you needing to apply that particular style to something else later down the road. The most common case for me is when I need something to have a particular padding/margin to be in the right place but it's not an element important enough to have its own ID.

This may not be a popular opinion here, but in those scenarios I don't think an inline style is evil.

Upvotes: 1

Related Questions