To Shorthand Or Not To Shorthand,

[SamuelMSr]

Ok so I am learning quite a bit about CSS, and let me tell you this is FRIGGIN AWESOME! I am having a blast.So here it is, I am reading more then one book and talking to people and doing a lot of different things to learn as I find this is better then just one source, and I am getting conflicting advice.Some say to never use shorthand, that it may take longer to put each rule on its own line but later it can make changes easier and if anyone else has to read it they may find it easier.Others are saying to ALWAYS use shorthand and make quicker work of it all.What is your opinion. I personally dont mind doing each rule on its own line as I find it easier to see what I have done, especially since I am extremely new to all this.Any advice is welcome, just would like to hear the input you guys have on this subject.Thanks!!Sam

[jeffman]

I mix and match. Shorthand always for borders, margins and padding. Almost never for fonts. Too hard to read.That's just me.

[thescientist]

I don't think I shorthand. For some reason I like tracking it all individually, line by line. Although I supposed some would counter that not short handing adds extra lines of code, but in this case since CSS is just interpreted text, (nothing as complicated as what I would have to code for work, hah!) I don't think its that big of deal, and its fun to be verbose sometimes, haha. But yeah, it'll get cached anyway, so it doesn't bother me.'

[Ingolme]

Use shorthand properties, but UNDERSTAND them first.When you use the shorthand method, you must keep in mind that everything that you did not explicitly set will be reset to the default value!.Often people come here saying their background image isn't working, or their border isn't displaying. Here's the code, can you see the mistake?

background-image: url(file.jpg);background: green;

border-style: solid;border: 3px red;

[ProblemHelpPlease]

Also when using shorthand make sure you know exactly what must be inlcuded and in what order, the font tag is a good example. Anything that reduces the amount of code whilst performing the same overall function can only be a good thing.

[jeffman]

Anything that reduces the amount of code whilst performing the same overall function can only be a good thing.

That's a pretty strong statement. It is no longer 1975, and programming for the web is not the same as programming for a machine that must fit an operating system and a program into 64K of RAM. From that perspective, the whole concept of HTML is ridiculous. All our web pages and scripts would be compiled binaries. We'd all be writing assembly code. Ecch!Excess code cannot be defined only in terms of size. You can reduce any program by combining statements, using 1-character variable names, removing whitespace, and so on. But this will not necessarily make the program execute faster. It may save download time, especially if you can reduce 100K to 75K, and that's a worthwhile goal. But if you have a small document, reducing 11K to 10K is trivial. No user would ever perceive the difference.If the programmer or his/her colleagues cannot understand the finished product in order to debug or maintain it, there is a problem. For this reason, most web documents designed by professionals strike a balance between efficiency and programmer friendliness.If you have the organizational resources and the time, then you can create a development version of a page and a compacted release version of a page. View the source of a hundred pages designed by SERIOUS pros and get a sense of who's doing that. Some do, some don't. The compacted jQuery file certainly does. I get a sense that Microsoft does. Apple's front end looks like they strike a balance. (The presence of comment tags is a giveaway.) developer.mozilla.org also looks like it strikes a balance. Again, the comments are telling.Efficiency is good. But let's not go overboard and say that ANYTHING that reduces code is automatically for the best. (Unless maybe you were making a distinction between code and comments; but that's not very useful; these are text-based protocols, and bytes are bytes.)