Where to draw the line between efficiency and practicality

tags:

css
html

views:

110

answers:

+3 Q:

Where to draw the line between efficiency and practicality

I understand very well the need for websites' front ends to be coded and compressed as much as possible, however, I feel like I have more lax standards than others when it comes to practical applications.

For instance, while I understand why some would, I don't see anything wrong with putting selectors in the <html> or <body> tags on a website with an expected small visitation rate. I would only do this for a cheap website for a small client, because I can't really justify the cost of time otherwise.

So, that said, do you think it's okay to draw a line? Where do you draw yours?

+3 A:

Some best practices can be safely ignored if you know what your are doing and why you are doing it.

Don't cut corners because you are lazy, but don't over engineer a 2 page website. Use your judgment.

But, if you delude yourself into thinking you are better than you are, either yourself, or a future maintainer will be cursing your existence.

Byron Whitlock 2010-03-15 18:32:34

And always assume the next maintainer is an axe wielding maniac.

Yacoby 2010-03-15 18:34:23

+2 A:

For instance, while I understand why some would, I don't see anything wrong with putting selectors in the or tags on a website with an expected small visitation rate

I assume you mean putting inline CSS into those tags. Well, there's nothing wrong with that per se. As far as I'm concerned, everybody is allowed to do that to their heart's content (as long as I don't have to maintain it.) But a practice that puts all the CSS into a separate style sheet, so that the HTML file consists really only of a skeleton and the actual content, is just cleaner, easier to maintain and a joy to the eyes.

I would only do this for a cheap website for a small client, because I can't really justify the cost of time otherwise.

I don't think this reasoning is correct. A cleanly separated structure is equally expensive to build when you've got the hang of it, and cheaper to maintain in the long run.

Pekka 2010-03-15 18:33:34

Actually, I just meant tagging it with a class or id. I have heard before that it's bad to do such a thing, because to render the site, the browser has to keep checking back on that hyper-parent element. Perhaps I misunderstood or heard wrong. I only used it as an example because it seemed like one of these hyper-efficiency measures, such as compressing your HTML or CSS files.

dclowd9901 2010-03-15 18:35:45

@dclowd Why would tagging a body with a class or ID be wrong? I don't understand, that's a perfectly valid practice IMO. Funnily enough, I'm at the moment writing a blog post about how one should do more of that to make later customizations easier (= in order to be able to target elements on certain pages but not on others.) Maybe you can give an example what you mean exactly?

Pekka 2010-03-15 18:36:47

Best practices so called for a reason. Your work will always reflect you, and although these things may seem small and insignificant, they will aid maintainability, readability etc when you come back to modify something. The profitability argument is one oft cited by freelancers - if you don't always do it, you may never do it. In time you'll realise it's actually quicker to "do it right" than bodge it, and you'll be proud of your work.

Always adhere to standards and best practices!

Andy 2010-03-15 18:35:25

+2 A:

A small client who doesn't have a lot of money to spend is going to be extremely angry when he asks you to change some color and it turns out that will take you two hours because it's specified in a bunch of in-line styles rather than in a css file.

I would also argue that if you get in the habit of using an external stylesheet and just applying styles in your HTML, you will find that it's actually faster than in-line css.

JacobM 2010-03-15 18:35:51

Exactly! It might seem like a one-off project at the time, but it almost always seems like you end up making changes...often for several years. Spend a little extra time now doing it properly, and save yourself hours of headache later!

Dan Breen 2010-03-15 18:38:57

Yeah, wasn't exactly referring to in-line. At this point, it seems like I misunderstood what I had been told about classing or id-ing html or body tags, but there still exists the difference between a 17KB 24-bit png or a 14KB 8-bit png, or compressing all of your .js or .css files. Those are the kinds of things that I stop at.

dclowd9901 2010-03-15 18:42:15

+1 A:

Where I draw the line is going to depend on the project. You're always going to have to choose a balance between readability and efficiency.

For example, it's possible to make HTML and JavaScript very efficient by making it unreadable--stripping whitespace, shortening element, variable, and function names, etc. To evaluate whether or not to do so, I would calculate delta in hardware costs plus opportunity cost of the heavier file and compare it to the cost of writing a generator that will take clean, easy-to-read code and turn it into terse, easy-to-load code. Whichever solution costs less is then the one to use.

Jekke 2010-03-15 18:39:55

ansaurus

tags:

views:

answers:

Where to draw the line between efficiency and practicality

related questions