Okay, I am completely rubbish at CSS...Utterly rubbish, I can code in PHP But when it comes to designing I just can't do it.. ..Can someone suggest to me some visual tutorials (with pictures etc..), or even better, can some people suggest to me some screencasts (video) tutorials on CSS... Thanks guys!
I haven't found many out there that are that good. I would be willing to help you. If you can come to me with a design I can help you program that design into a working site using CSS, for free! In my opinion that is the best practice, utilizing the programming of a design.
hi, i recomend you to frequent css tricks, net tuts, smashing mag, six revisions, there are allot on the smashing mag network to follow really usefull
First, if you are a complete nube to CSS, go get "Build Your Own Web Site The Right Way Using HTML & CSS by Ian Lloyd. When learning from this book take everything you THINK you know about HTML and throw it in the trash. Sitepoint sells it, you can find it at most major booksellers, and I've even seen it at a few public libraries. He skips right past a decade of bad practices and bad code and gets right down to writing things the MODERN way. There's a LOT of bad advice on writing both HTML and CSS out there - most tutorials still using tables for layout, and even when they don't they just end up being "The same people who wrote endless nested tables now just make endless nested DIV's with pointless classes." The biggest hurdle to doing CSS PROPERLY is the concept of separation from content - aka getting the RIGHT HTML for you to apply your CSS to. Your markup should say what things are, NOT how they are going to appear. It's called semantic markup - You don't use a H1 becuase it's bold big text, you use a H1 because structurally all other headings on the page are subsections of that heading. You don't use <font size="+2"><b> you use a heading tag because it's the start of a section... You don't use double breaks you wrap the text in paragraph tags - conversely you don't slap paragraph tags around non-flow text or non-text elements just because some SEO whackjob told you to... (an image is NOT a paragraph of text!!!)... Menus are lists, quotes go in quote tags - it's actually pretty simple if you just use the tags for what they are FOR. To 50/50 it, half people's problems with CSS come from rubbish HTML, the other half come from cross-browser oddities. That other half has it's root in the netscapeisms vs. IEisms when neither followed the specification - today it's FF vs. IE and BOTH a similarly flawed even when your rabid firefux fanboys refuse to see anything wrong with their browser. Tell that to the STILL broken inline-block implementation, STILL broken absolute positioning inside inline level elements, STILL broken 'scope', STILL "broken" form elements (for *** sake could we get all the browser makers on the same page with that already?!?), and the decade old Bugzilla 915. Someone tells you to use FF as your primary testing platform, tell them where to shove it - you need to test as you go in ALL browser engines, since Safari is rabidly standards compliant, What of the standards Opera supports it does more accurately, Firefox 'supports' a lot of standards but fails to implement many of them properly, and IE... well, IE's off in it's own little world. Most of the time if you have 'problems' it's going to be IE - it actually doesn't help that right now you at minimum need to support three different versions, 6, 7 and 8. Generally 8 is the best behaved if your page already works in FF/Opera/Saffy, and 7 usually only needs a couple minor fixes - the big one that's hard to support is IE6... BUT 99% of IE problems can be fixed quite easily. 1) Use a valid doctype so IE is not in quirks mode. This gives you the same 'box model' as all other browsers. 2) Even with the same box model, you may end up wanting to support IE 5.5 and 5.2 (5.2 is the last iteration of IE for the Mac). In that case avoid declaring WIDTH or HEIGHT the same time as padding and border. I'm so into the habit of not declaring them at the same time I don't even have to think about it anymore. MOST of my pages still work in 5.5 and 5.2 just fine. 3) if a float has background images disappear when scrolling, set the element to position:relative; 3) 4) if a float has it's margins double, declare display:inline; on it - strange as that sounds. Floats are inherently display:block and nothing you declare for a display property can change that. (well, except perhaps display:none)... So all browsers ignore display:inline so far as making it an inline flow element - BUT, it trips something in IE that makes the margin doubling behavior dissapear. 5) Haslayout - back before there was CSS Microsoft added a trigger internally to say if elements needed extra positioning calculations or should be re-rendered when the screen size changes or dimensionless IMG tags load. An element that should be re-rendered was said to 'have layout' while elements that lacked layout could be rendered faster without recalculating their position. CSS can make all sorts of positioning changes as the page loads causing elements to appear in the wrong place, or not at all in IE. Some CSS properties can trip haslayout fixing this problem - zoom, width and height are the easiest. Zoom should be avoided where possible since it's a IE specific property and invalid CSS, but it does no actual damage anywhere else since by the rules of CSS unknown properties are ignored (so when we add new properties in the future it doesn't break everything). The so called 'Holly Hack' of height:1% is valid CSS, but requires care that you do not declare it the same time as overflow:hidden when a parent element has position:relative, or if the parent element has a fixed height declared on it. When in doubt, if IE seems to be off in never-land, toss zoom:1 on it or it's parent. 6) Comments - Yes, COMMENTS! Comments between floats will often make one of the floated elements either disappear, or worse render TWICE. Solution? Put comments INSIDE your elements... You'll often see bad commenting like <div id="cnt"><!-- start content --> </div><!-- end content --> What's wrong with that you ask? Well, we're opening a div, so of course it's the start. If you used a ID that was meaningful, you'd not need the first comment. The second comment is again Carlos Mencia hex grey since of course it's the end, that's what </div> means, it doesn't tell us if it's a ID or class we are closing, and finally, it can completely screw up rendering in IE if you float #cnt or what comes after it! What that probably SHOULD be is: <div id="content"> <!-- #content --></div> Don't need the first comment since we didn't use some half-assed abbreviation, the ending comment (which is handy in a lot of cases) does not trip the rendering bug and provides useful information. On top of the IE specific crap, there's just some good practices: VALIDATE. Invalid markup when it comes to cross-browser CSS is tying one hand behind your back and making more work not just for yourself, but for the next poor shlub who has to try and maintain the page or make changes. If your HTML doesn't validate, it's not HTML, it's gibberish. You'll see a lot of dimwits out there saying validation doesn't matter - YES, you can hack around invalid markup, but usually that will just result in your doing complete bullshit like that IE conditional comment crap and multiple stylesheets for each browser (the pinnacle of stupidity) STRICT. All new pages SHOULD be written in a strict doctype where possible, if for no other reason than to make you NOT use tags or attributes you shouldn't be using in the first place. Know how I said separation of presentation from content? FONT, CENTER, ALIGN, VALIGN, BGCOLOR, BORDER, TEXT, LINK, VLINK, ALINK, WIDTH, HEIGHT - those are all presentation and as such have NO ******* PLACE IN MODERN MARKUP!!! If you are using any of those you have already screwed up, and if someone teaching you markup tells you to use them, you're listening to the wrong person! Likewise you should avoid using the STYLE attribute just because the idea is to get presentation OUT of the markup. You don't apply the style in the markup, you say WHY you are applying the style in the markup with the tag or a class. Not every ejaculation deserves a name... Which is to say, not every element needs an extra div with a class around it. Not every element needs a class on it for styling to be applied. You'll often see nimrod nonsense like this: <div id="mainMenu"> <div id="menuBorder"> <ul id="menuList"> <li class="menuItem"> <a href="/" class="menuAnchor">Home</a> </li> <li class="menuItem"> <a href="/forums" class="menuAnchor">Forums</a> </li> <li class="menuItem"> <a href="/faq" class="menuAnchor">FAQ</a> </li> <li class="menuItem"> <a href="/contact" class="menuAnchor">Contact Us</a> </li> </ul> </div> </div> Code (markup): When all they are doing is 100% width with border top and bottom and some top/bottom padding... What's wrong with that? EVERY SINGLE ONE of those classes is unneccessary... If every tag inside a parent ID or class is getting the same class - don't waste time putting a class on it. Even the wrapping div's are likely unneccessary since padding should be on the anchor or the UL, and the border can be applied to the UL. This is all that should be needed: <ul id="mainMenu"> <li><a href="/">Home</a></li> <li><a href="/forums">Forums</a></li> <li><a href="/faq">FAQ</a></li> <li><a href="/contact">ContactUs</a></li> </ul> Code (markup): So how do you nab those child items in the CSS? Original | Rewrite #mainMenu == #mainMenu #menuBorder == #mainMenu #menuList == #mainMenu .menuItem == #mainMenu li .menuAnchor == #mainMenu a That's it. Good rule of thumb is that if you are nesting more than three div deep - you are probably screwing up or doing things the hard way. If you keep your markup simple, your CSS will be simple. FORMATTING - for **** sake indent your code and put identifiers and properties on their own lines in CSS. These endless jumble single line messes just make more work, and usually result in the common mistake of declaring the same property twice with different values. I can't count the number of times I've seen CSS like this: #pageWrapper { width: 768px; position: relative; margin-left: auto; margin-right: auto; display: block; font-size: 85%; line-height: 130%; font-face: arial,helvetica,sans-serif; width: 1120px; color: #FFF; } Code (markup): With the person asking "Why isn't it rendering at 768px" - *thunk* BECAUSE it's declared 1120 AFTER. Dee Dee Dee. It also helps to learn to use condensed CSS properties, and to learn what tags are inline-level and which ones are block level - which lets you take that entire mess and reduce it to: #pageWrapper { position:relative; width:768px; margin:0 auto; font:normal 85%/130% arial,helvetica,sans-serif; color:#FFF; } Code (markup): Easier to read, no redundancy mistakes because you can actually FIND each property since it's not a blurred run-on mess - AND it's less code. (the display:block was removed since #pageWrapper is likely a DIV, and div's are block level - meaning it DEFAULTS to display:block!) Alright, I've run at the mouth long enough - Lemme just point you at one of my older posts about good coding habits since much of it is stuff that will make your life easier... a little extra effort at the start means less work later. http://forums.digitalpoint.com/showthread.php?t=1036280 Which is a bunch of stuff that will serve you well in ANY programming language. Remember, the tab key is your friend, and WYSIWYG editors are the mortal enemy.