After reading “5 Steps To CSS Heaven” over at pingmag.jp, and disagreeing with some of what was said I thought that writing this would be appropriate. I’ve been writing CSS professionally now for about 2.5 years so here are 5 quick tips that help me out in my day to day work. I wouldn’t call them best practices because everybody has a style that works for them, but these are what work best for me.
1. Organize Your CSS
Jon says you should write a table of contents at the top of the file, but I don’t really care about that, especially since I’m usually the only person to look at my CSS file. A table of contents is useful if how you demarcate your sections changes with each CSS file, but why make your life complicated? I like how his example file has an entire section for “Typography”. That’s like going to a supermarket and seeing one gigantic isle marked “Food”…. all parts of web design have to do with typography so lumping them all together doesn’t help you out much.
I lay out my CSS files the same way, every single time. I 1) lump all container/layout blocks together (divs with an ID of “header”, “footer”, “maincontent”, etc.) at the top, 2) then my headings H1 through H6, 3) then paragraph and link styles, and 4) then all my lists (navigation, etc.). I’m normally looking through my CSS with something like, “hey where’s that footer style?”, “damn that subtitle on the right has too much padding-bottom”, or “I have to change the hover state on that current navigation tab”, so organizing my CSS file according to what type of element it’s referring to jives with how I think about CSS.
Here’s the CSS file I always start with, feel free to nab it and use it for yourself.
Now couple the page organizational idea I just mentioned with the CSS indentation technique I’ve written about before, and you have a pretty clean CSS file. Check out Business Logs’ springtime.css for an example of the combination of these two techniques. Now if your brain doesn’t work like mine, I fully recommend organizing your CSS file in a way that matches how you work. Don’t just copy what I’ve said here if it doesn’t make sense to you, find out a pattern that makes sense to you and go with it.
2. Avoid Default Styles
As someone who works on fairly complex layouts all the time, I’ve learned that the easiest way to confuse myself and stare at my CSS file for awhile is to have default styles running rampant. By “default style”, I mean defining a default tag with no specificity, like this:
a {
color: red;
text-decoration: none;
border-bottom: 1px dotted red; }
or:
h2 {
font: bold 18px/1.4em "Lucida Grande", "Verdana", sans-serif;
color: #000;
border-bottom: 1px dotted #ccc;
padding: 0 0 3px 0;
margin: 0; }
The problem with defining all links or all H2s at the same time is that I use different link and H2 styles all over my layout, depending on where the tag shows up. A link inside of an H4 in the main column is going to look different than a link inside of a right column paragraph, but if I define all links to be red and have a bottom-border like I did above, then they’ll both start out with those styles. I’ll have to overwrite the color and the border-bottom if I wish to make them look different, and if I forget, then the default link style will cascade down and show up, probably making my link pretty ugly.
What I do in my CSS is this:
h2 { }
#maincontent h2 {
padding: 0;
margin: 0;
... }
To remind myself that a generic H2 is around, I leave the empty h2 { } in my stylesheet, right above all the specific H2 styles. This doesn’t really do anything from a CSS standpoint, but stylistically I now can scan down my CSS file and see if a wacky style somewhere is due to a default style I forgot to remove, or if it’s something else. Plus, scanning down a nice column of empty heading tags really breaks up the style sheet for me, making it easier on the eyes.
Judi brings up a good point down in the comments, and that instead of totally neglecting the default style, you find the lowest common dominator across all your particular H2 headings, or what have you, and make that the default. If all of your H2s have 0 margin, then make it so. Thanks Judi!
3. Use Your Utility Tags
Many times you’ll have a section in your design that calls for various typographical weights/looks all on the same line, or very close to each other. You might have a subheading on your blog with a different color for your permalink vs. your comment link, or a heading with a quick subheading right below it in a smaller font. For these little styles, I don’t like to drop in random divs and classes because I feel they’re not semantic and defeat the purpose of your nice XHTML everywhere else. Instead, I use some tags that I like to call Utility Tags. They would be:
<small>, <em>, and <strong>
I use these three tags all the time to accomplish little areas of design that are overkill for an extra div or class. Here’s an example of some XHTML that uses a utility tag:
<h2>Title Of Entry Here <small>Quick subheading here</small><h2>
Inside of an H3 heading I dropped a small tag to accomplish a subtle design change. I want the H3 main text on one line, and then the small text on the next line in a different font. Here’s my CSS:
#parentelement h2 {
font: bold 18px "Trebuchet MS", "Tahoma", sans-serif;
color: #f00;
padding: 0 0 3px 0;
border-bottom: 1px dotted #aaa; }
#parentelement h2 small {
display: block;
font: normal 12px "Lucida Grande", "Verdana", sans-serif;
color: #333; }
I used a utility tag inside of a heading, no class needed, and then targeted it directly via CSS descendant selectors. This keeps your XHTML uncluttered and lets you do quickie styles with no real effort. What’s the display: block; doing in there? Well normally <small> is an inline-level element, so instead of dropping <br /> right before it to make it jump to the next line, I just swap its display for block and have it do it by itself.
4. Use The Right Tool For The Job
I’m not a validation nazi, but I do appreciate the usage of semantic tags instead of generic ones. There are 6 heading tags (<h1> through <h6>) so before you start dropping in <div class=”sectiontitle”>, use what you’ve already got in your arsenal, namely, heading tags, because they’re there for a purpose. I rarely use DIVs for anything other than a box to surround sections on my site, so if your XHTML suffers from divitis then try replacing some of your tags with pre-existing HTML instead.
5. Name According To Where It Is, Not What It Looks Like
Over at PingMag, the article tells you drop classes like “red” and “strong” on your DIVs for quick styling, but I think that’s an awful piece of advice. Better names would be “error”, “important-message”, or whatever else you can come up with, because at least those names let you know WHAT it is instead of force-feeding you what it looks like. What’s better, telling you that the thing over there is a firetruck and you knowing that it’s red, or me telling you there’s a big red truck over there and you asking me if it’s a firetruck. One conveys more semantic meaning than the other, so pick the better of the two if given the choice. A commenter named ASD summed this up nicely:
“class=”strong red align_right” – you are serious?
This is awful naming. Names should relate to content, not presentation. That’s the whole point of CSS – seperating presentation from content.”
Couldn’t say it better myself.
About Mike Rundle
Excellent read Mike! I never though about not styling my default tags until now, but if you think about it, it is kind of redundant. I also like the way you leave the default tag in the style sheet though, as it does aid readability.
I am god awful at organising my CSS, if it wasn’t for Dreamweaver’s find feature I couldn’t cope in my CSS files, a starting template is deffinatly going to be something I need to look into.
On the topic of organising, I was brainstorming a more OO CSS, with sort of classes, so you can apply styles to a base “object”, I wrote up my ideas in this post.
Thanks Brett!
Sam, the article you wrote up is fantastic, I’d love to see you ideas put into action.
I probably needed this. My CSS layout tends to be incredibly disorganized
Regarding your utility tags.
To my understanding, you can’t place a block element inside an inline element and validate, such as you’re showing with “small” inside the “h2″.
But I do it too, so I wont tell anyone.
Hey Nico, all heading tags (H1 through H6) are block-level elements by default, so my method is nice and legal. If I were to change the H2 to an inline element while maintaining the small tag as block-level, then it wouldn’t validate.
Great article, Mike. The only thing I would disagree a bit is in rule #2. I think the key is to find the lowest common thread between your styles and apply it at a level that means you only have to type it once. So if your h2s always tend to have 5 px padding, then you don’t want to have:
h2 { }
#maincontent h2 {
padding: 5px;
color: blue;
}
#sidebar h2 {
padding: 5px;
color: black;
}
etc. etc.
Instead I would do something like:
h2 {
padding: 5px;
}
#maincontent h2 {
color: blue;
}
#sidebar h2 {
color: black;
}
Truthfully, I prefer to organize by section, not HTML. So instead of keeping all the h2s together in one lump, I tend to lump all the #maincontent styles together, starting with h1-h6, then p, blockquote, td, etc. and then ending with any classes that are specific to that section. Then #sidebar, #footer, etc.
Those styles that are global are at the top.
At least it always starts out that way. ;-)
Hey Judi, very good point! The funny thing is that I’ve done exactly that in the past, but forgot to mention it here. I like your lowest-common denominator line, I think I’m going to add that to the entry :)
Good call on #5, Mike. It always drives me nuts when I see this happening. I can’t tell you how many times I’ve updated someone else site and wound up having something like div.red { color: green; }.
I must say that while I agree with avoiding class names like red and strong and so on, I am guilty of fright and fleft simply because I get thrills out of using fright for {float:right;} and therefore fleft {float:left;}
:D
Thanks for this article, Mike — although I lay out my CSS a little differently than you do, this has made me step back and re-evaluate some of my habits.
I notice that you don’t use a generic
* {border:0; margin:0; padding:0}
at the top of your CSS. That’s something that I’ve found helps keep cross-browser compatibility — I then set margins and padding explicitly for each element that needs them.
Even then, extra margins sometimes show up that are only curable with child selectors, like this:
#box1 > #innerbox {margin:0}
Some good advice/tips for CSS organization.
I love how the result of #3 looks with styling, however, the usage of a element within an h2 element, unstyled, looks kind of odd if you ask me. That’s my only niggle with that technique.
Thanks for sharing these tips my fellow Indian food croonie.
Right on. In terms of naming classes and IDs, I find myself avoiding hyphens and underscores lately. For example, instead of “align_right” I would do “alignRight”. Another would be, “tbl-stop-the-madness” vs “tblStopTheMadness”. Although coming short on the readability scale, I guess it plays nicely come play-time with JS. Thoughts on that?
Great article, thanks! I’ll be sure to use your example file.
But you’re right about the indentation, it’s not for everyone. I prefer just having the elements in the right order (generic on top), and then separating the sections with some whitespace.
The other point I would make about #2 is that some tags are used for multiple purposes. I kept getting caught out on this a while ago because if you have an a style for ‘a’ in your CSS, it will not only mark links but also apply to named anchor tags (<a name=”bob”> for example). So being too general with the defaults can have additional side effects if you’re not careful. :)
1. Yep.
2. I don’t do like this, simply because I like having a generic style for “everything.” It’s not hard to override either. A good rule, though, is never to use !important inside a “default style.”
3. But look at that in a non-CSS browser. Please, at least, have a space between the “big” and the small text.
4, 5. Yep.
If you have access to a Mac and XyleScope, #2 is really unnecessary to stick to, and it can even be useful in some situations (see for instance my initial.css file)
:-)
“all heading tags (H1 through H6) are block-level elements by default”
d’oh!
If I could share a tip I’d say plug in the default stripper file “undohtml.css” from Tantek Celik. It strips inconsistant defaults preset by different broswers. things such as margins and font-sizes.
http://tantek.com/log/2004/undohtml.css
It’s the first thing I do on every style sheet.
Mike, these are great points. I love the ‘small’ idea – I had never thought of doing that for subheads.
I actually find a CSS table of contents very useful, especially when you are working in a team, but even when you’re working on a site by yourself.
Very often my style sheets will run to several hundred lines. That can make for a lot of scrolling. If you have a ToC all you have to do is highlight the section you want, hit ‘F3′ (‘Find Next’ in Windows) and you’re where you want to be. Very handy!
Funny, you didn’t mention progressively indenting your styles in this post – don’t you do that anymore?
Christian, yup, still do it :) I thought it’d be overkill to write about it again, so I just linked to it in the last ‘graph of the #1 section.
A great set of explanations, Mike. I particularly enjoyed the take on PingMag’s recent article, which had me leaving the side wondering “What are they thinking?”
Using a ToC might be a viable option, but in my case I have my CSS broken into the generic “Structure,” “Typography,” “Links,” etc. sections. I also make use of indents when I have a class of an element (i.e., h1 and h1.logo).
One more thing, and granted it’s been mentioned time and time again, is comment certain parts of the code. If you have a hack, an overriding line of CSS, a tricky way of doing someting, you should comment it. It keeps CSS in line and lets you as the author of it remember why/how you do things.
Good article!
I’ve been putting more stuff in one row, especially now that I have a widescreen monitor. It’s not for everyone, but I find it makes for a lot less scrolling. I can find things faster.
so instead of:
h2 {
margin: 0;
padding: 5px;
color: steelblue;
font-family: arial, sans-serif;
}
I use:
h2 {margin: 0 0 1.2em 0; padding: .5em; color: khaki;}
h3 {margin: 0 0 1.2em 0; padding: .25em; color: #f0f;}
h3 cite {display: block; font-size: 80%; font-style: normal;}
Thanks for these great tips!
Great post – yep I’m guilty of putting in display-type names sometimes, rather than purpose-names.
I’m not keen on putting in empty styles – I’m all for not defining defaults (though I still do!) – but if you need to break up sections and subsections why not just use comments? That way it’s not redundant markup.
I wrote that admittedly-slap-dash article in a couple of hours, and my examples could have been a lot better, that’s for sure. However, it appears people prefer being judgmental over actually reading the content – in no way was I *recommending* visual class names (don’t tell me this isn’t something you’ve done before – we can’t all be perfect 100% of the time). The point was about isolating properties that you use a lot, which would also allow you to combine classes later. Class naming conventions weren’t even touched on. It was simply about helping you to streamline your document – if that’s what you want. In no way is it any kind of “best practice”.
As for naming conventions – you know it’s funny. Last time I wrote a CSS-related article I got comments remarking on how it’s not “good” to write camelCase in CSS. This time to make people happy I used underbars. And look what happens – you can’t please anyone, and most people at the end of the day believe what *they* are doing is right.
Anyway, nice article.
In addition, you write:
“I like how his example file has an entire section for “Typography”. That’s like going to a supermarket and seeing one gigantic isle marked “Food”…. all parts of web design have to do with typography so lumping them all together doesn’t help you out much.”
and follow it with:
“I fully recommend organizing your CSS file in a way that matches how you work. Don’t just copy what I’ve said here if it doesn’t make sense to you, find out a pattern that makes sense to you and go with it.”
I find this a bit contradictory. In all the work that I do, I find that separating typographical properties from my layout properties to be a huge headache-reliever.
Taking a look at the CSS to your personal site, you are declaring font properties over and over again when you really don’t need to. If for example you decided you wanted to change all Trebuchet fonts to something else, you would need to go through the entire length of your document to do so, or do a find&replace. By keeping all the typographical elements in one place, and also by combining the classes a little, such a process would be made much easier.
This kind of action doesn’t happen so much with positional elements – for example I rarely need to make all my divs become the same size or colour, but often I will want to influence all the fonts or all the line-heights on the page.
Like you said, it depends on the way you work, and all I know is ever since I started separating my positional stuff from my typographic stuff, I’ve been working a lot more efficiently. The example in the article is too simple to illustrate what I mean – it’s probably better if you refer to the stylesheet on my personal site.
I think is referring to how something should be presented and should not be used when speaking about writing semantic markup.
em, strong are fine because they don’t refer to the way something should be rendered.
what if someday you wanted that content in small to be rendered in a large red font.. kinda confusing no?
my .02 cents anyways
In this example:
<h2>Title Of Entry Here<small>Quick subheading here</small><h2>
I would be somewhat concerned that a simple HTML to text converter (as might be embedded in a search engine spider or a screen reader for the blind) might see “Here<small>Quick” as “HereQuick” since it might not take CSS into account and realize that you’ve changed the semantics of from inline to block. Putting a space before “<small>” solves the problem and gives you the option of changing your CSS to switch back from block to inline in the future without having words squashed together.
Nobody’s made mention of utilizing the contextual nature of CSS to help organize your styles.
My style sheets typically start with setting up some site-wide and rational defaults for various commonly used tags and elements … stuff like setting
body{
font-size:62.5%;
border:0;
margin:0;
padding:0;
background:#F9F3D8;
font-family: verdana, arial, helvetica, sans-serif;
color:#000;
}
form{display:inline}
p, h1, h2, h3, h4, h5, h6{padding:0; margin:0 0 10px;},
etc… This way I don’t find myself doing those things over and over again.
Then comes the structural stuff:
#wrapper{width:742px; border:1px solid #CBC9AE; margin:50px auto 0; padding:0;}
#header{width:742px; height:71px; background:#76905A; border-bottom:1px solid #B4A745;}
#content{min-height:400px; background:#FFF}
#footer{height:40px; border-top:1px solid #D9D9D9; }
Now that the basic page structure is set, I’ll then begin setting styles that I will be utilizing within each section directly underneath the section styles. So if I was up the content area, I might do something like this:
(#content repeated here for clarity … )
#content{min-height:400px; background:#FFF}
#content p{padding:0 15px; font-size:1.1em}
#content a{color:red; text-decoration:none; font-weight:bold;}
#content a:hover{text-decoration:underline;}
This way my CSS is completely organized by the structural layout of the page. If I need to adjust a style from some part of the page I know EXACTLY where to look for it, and I don’t have to specify a whole bunch of .classes to style things all over the place, saving me time when I’m writing my markup. In other words, I don’t have class=”some-class” all over the place.
Good article!
Interestingly I recently wrote an article about Organising CSS, which you may (or may not) find interesting:
http://mattwilcox.net/archive/entry/id/642/
Also, next time I comment on a blog and think my opinion might get flamed, I’ll use my real name and not ‘ASD’. You live and learn.
Nice, complete article. However, I disagree with the use of HTML tags, such as and to style the page. Doesn’t that defeat the purpose of a style sheet, which is to facilitate the separation of content from style?
Our web site Pathf.com uses a few farily complex styles and the stylesheet is therefore pretty daunting to look at if you havent seen it before. However I make sure that I never cut corners by styling through HTML, because I think the disadvantages of having a complicated stylesheet are outweighed by the benefits of separating content and style.
What do you think?
Here’s my default CSS that I use at the top of every stylesheet:
/* avoid browser inconsistencies */
ol,ul,li,h1,h2,h3,h4,h5,h6,pre,form,body,html,p,blockquote,fieldset,input,div
{ margin:0; padding:0; }
/* remove blue linked image borders */
a img,:link img,:visited img { border:none; }
/* de-italicize address */
address { font-style:normal; }
what if someday you wanted that content in small to be rendered in a large red font.. kinda confusing no?
The choice to use SMALL is maybe borderline. I usually use SPAN myself for this purpose in headings. However, I don’t think this is a fair criticism of the technique. First of all, there is no such thing as pure semantic HTML. If you want pure semantics then you better write an XML spec to define every single element. Using a billions DIVs and SPANs and classes just so you can say something is semantic is worthless pedantry.
People often forget that HTML is a document markup language. There are many formatting aspects of documents that don’t have clear semantic ties. Sometimes the only semantics is that I want this piece of information to look different for design purposes, not because it has some categorizable meaning. Forcing it to have some meaning with a wordy class name is silly.
Standards are like database normalization: they make everthing easier, and a lot of hard stuff possible. But also like normalization, there is a point at which you can go too far in the name of ‘correctness’ at the expense of development time and performance with no real benefit.
A good example of presentation classes I use all the time are class=”right” and class=”left”. Of course it’s not semantic, but it’s a handy way of floating things. I don’t want to stop and take 2 hours deciding what each particular block and image I am floating IS semantically, then giving them all their own classes, and writing 2 pages of selectors with float:right and float:left in them. There is simply no value in that. Not in HTML. Not on a webpage today. If that kind of thing floats your boat then go take a look at the semantic web and take that attention to semantic purity to somewhere where it is useful instead of bogging down best practices with mental gymnastics and busywork.
One other trick I use is to varied the colors I use very slightly. If I use #FFFFFF in 5 places in my design I will use #FEFFFF, #FFFFFE, or some other variant. The visual difference is not noticable but if you sample the color you will notice the one spot that is unique. Then you can use “find” in your editor to find the exact location of that color. I only do this when it is possible in the future that the two or more elements might have a different color from one another.
recently I started separate the 4 categories that you have into 4 different files like
layout.css
links.css
main.css
etc……
and then do @include in the main.css so i won’t have to scroll forever to get to the ones that I wanted.
Wonderful. This will help a lot, as I’m still fairly new with CSS. This really has shown me that organization is pretty important, but overkill is not. I suffer from not being able to find a certain element or class in my .css files, and end up resorting to the age old Find tool.
I love the table of contents idea. If your working with a team of designers, this is great, plus it’s a good habit for other uses, and nice for people interested in css but not fluent.
Gabe, you said it better than I ever could.
—Sholom Sandalow—
Nice, complete article. However, I disagree with the use of HTML tags, such as and to style the page. Doesn’t that defeat the purpose of a style sheet, which is to facilitate the separation of content from style?
(I’ll capitalize tag names and ommit less-than and greater-than characters)
EM and STRONG, like pointed out before, are symantic. While most (nearly all graphical) browsers render EM as italic text and STRONG as bold text, they’re nothing like I and B.
If I were to be using a text-to-speach engine, the browser would put emphazise the text in EM tags as well as the words in STRONG. (Probably a little different) SMALL would perhaps be said softer, or in a whispering voice. While bowser style these tags, you, the site designer, should do it. Setting a ‘strong { font-weight: bold; }’ in your CSS wouldn’t be an odd idea, after all, the W3C spec (probably) doesn’t say at all that STRONG text should be bolded.
Heck, you could give the STRONG tag the following CSS, and it’ll still serve its purpose: ‘strong{ font-weight:normal; font-size:1.1em; color:green; }’ However, if you would give the B tag a font-weight:normal, then it’d lose its meaning.
I don’t indent often, I often work on my laptop which only supports up to 1024×768, so I don’t have the resolution for things like this. In cases that I do indent, I do it like this:
tag
{ }
— tag:hover
— { }
— tag:after
— { }
As for organizing the CSS blocks, that’s usually random for me, although I do try to keep with the layout of the XHTML. (Header, body, stuff inside the body, footer) It’s often a mess, but hey, there’s always good ol’ CTRL+F. (lame excuse, I need to change my habits ;) )
I’m kind-of interested to see how you all organize your CSS, inside of your definition blocks, in other words, would you do it like this:
tag { font-size: 2em; color: red; border: 2px solid red; background: #fc8; width: 300px; } — (In one row)
And/or:
tag {
background: #fc8;
border: 2px solid red;
color: red;
font-size: 2em;
} — (alphabetized)
And/or:
tag {
background: #fc8;
border: 2px solid red;
width: 300px;
color: red;
font-size: 2em;
position: absolute;
top: 0px;
} — (Categorized [element display, font, positioning])
I personally use the latter, multiple rows and in some form of categories, although I often take liberties in it. Usually I stick Margin and Padding with the ‘positioning’ category.
html, body { padding: 0; margin: 0; }
OR
* {padding:0; margin:0; border:0}
??
I’ve found this rule makes for more efficient sheets.
A few years ago, I totally redesigned my site to use valid XHTML and CSS. I wish I had known your tips back then — they probably would have prevented my CSS stylesheet from becoming so huge and hard-to-manage. At this point, it would probably be easier to throw it out and create a new one, instead of trying to re-figure out all of the multiple ways that my numerous classes and IDs impact my site. Oh, well — live and learn. I am mentioning your article in my May 26, 2006, Journal entry.
Great article, liked your tip “avoid default styles” going to be reworking my css files tomorrow based on this. Actually i’m happy in general to see so many css articles around latley.
From the main article:
Whoa. Yes, the point of CSS is to separate presentation from content, but this is a CSS Classname we’re talking about here. It’s… presentation!
Classnames are all about presentation. Now, if naming them according to the semantic elements in your page helps you to use them best, and to remember what they mean, then great. But, naming something has to do with presentation (a classname) in a way that reflects the presentation it will give you makes perfect sense. In particular, many classes are entirely independent of content, location, etc…
(ID’s are potentially a different ballgame: an ID should ideally be slightly more semantic, as it relates to an organizational component. But a classname is strictly presentational. That said though, they’re both CSS. CSS falls within the aegis of presentation, not content semantics. And while ID’s are often given to semantic elements, the ID attribute is CSS, not content.)
I really like this blog piece Mike. Lots of great simple advice.
I do take up issues with point #5. I used to name all my styles by the content they described, for example .error-form{}. However I quickly became frustrated when I wanted to reuse that style for content that I hadn’t originally anticipated. So I found myself asking, now which subheader style was it that had verdana11 in it? Then I have to go back and check the stylesheet which is a pain.
For my purposes, I have found it extremely useful to combine several generic styles in exactly the manner you advise against, simply because I can recall exactly what the style contains from memory without having to look it up.
Just my 2 cents!
Thanks for the great article though! Ben
Nice tips Mike.
I will point out that “Name According To Where It Is, Not What It Looks Like” should probably be “Name According To What It Is, Not What It Looks Like”.
For instance, someone creates a section ID called ‘LeftSide’ and ‘RightSide’ – what happens when you switch sides in the CSS?
~ Teli
I know I am kind of getting off topic, but I need some advice. Should I make a website so that I use very little HTML and mostly CSS or do you think that it is better to stick to using HTML tables? I am very good with tables, but I am just starting to learn CSS. Could somebody please put and end to my struggle? Would you please reply on my blog since I would be more likely to find your response on my blog than here where there are so many comments. Thanks in advance.
Nice tips! Thanks!
Very nice solid tips!
Utility tags are new to me! I should digg them more in detail.
Thanks for sharing.
regards.
id and class attributes are HTML attributes – they exist in the HTML spec and not in the CSS spec. CSS AND JavaScript both use these as hooks to refer to certain elements in order to manipulate their presentation and/or behavior. If you want for classes to share style as in Verdana 11px you chain your selectors … h2,.subheading {font:normal 11px Verdana,sans-serif;}. Define your structure first (HTML) then build styles that apply to it and not define styles and apply them wherever they fit.
Hi, People. I really like it site! Good job, nice logo… wealth of information on site and a nice design.
I make site too http://postcard-printer.5bi4j1zo.com
GOOD LUCK ;)