I need suggestions for getting over my CSS block
March 27, 2007 1:46 PM
I have found it impossible to grasp the concept of CSS. A friend taught me to hand code HTML, then I taught myself how to use Dreamweaver. I love HTML and design nice looking sites that are full of tables, repeated font tags, etc. I really want and need to move on.
I want to learn CSS, but it just does not sink into my pea-brain. I've tried various online tutorials but just can't stay interested, mainly because I get lost pretty quickly into the tutorial.
Certainly it can't be that difficult, what can I do to make this easier for me to absorb?
The way I learned CSS was to include
border: solid 1px red;
in all my boxes. This let me see where everything is and what the browser is actually doing.
I would just start from this and just try creating boxes of different shapes, and then studying what happens on the screen.
posted by unexpected at 1:59 PM on March 27, 2007
border: solid 1px red;
in all my boxes. This let me see where everything is and what the browser is actually doing.
I would just start from this and just try creating boxes of different shapes, and then studying what happens on the screen.
posted by unexpected at 1:59 PM on March 27, 2007
The separation of layout from content is key. Keep your CSS in a separate style sheet, and then you can completely redesign a site just by changing one file.
If you've not checked out css zen garden then have a look, and marvel at the fact that the HTML is the same whichever design you choose.
Practically, I think the thing to do is to go back to working by hand, and start from the very beginning. Forget the font tag exists. Do all your paragraph stylings in CSS, put the CSS in an external style sheet, then change your mind. As soon as you realise how easy it is to alter the appearance of 200 web pages with one line of CSS, you'll be sold. Start with look and feel, don't get into the whole columns thing to begin with. Once you've got the hang of altering the appearance of your headers, footers, paragraphs and the like move onto columns and floats and the like. But if you're doing that you can actually go quite a long way with sites like this one:
three column layouts.
posted by handee at 2:00 PM on March 27, 2007
If you've not checked out css zen garden then have a look, and marvel at the fact that the HTML is the same whichever design you choose.
Practically, I think the thing to do is to go back to working by hand, and start from the very beginning. Forget the font tag exists. Do all your paragraph stylings in CSS, put the CSS in an external style sheet, then change your mind. As soon as you realise how easy it is to alter the appearance of 200 web pages with one line of CSS, you'll be sold. Start with look and feel, don't get into the whole columns thing to begin with. Once you've got the hang of altering the appearance of your headers, footers, paragraphs and the like move onto columns and floats and the like. But if you're doing that you can actually go quite a long way with sites like this one:
three column layouts.
posted by handee at 2:00 PM on March 27, 2007
I would recommend learning CSS in two steps:
First, concentrate on learning to use it for styling text...make your paragraph tags have style associated with them via CSS rather than directly embedding the styling in the HTML. Use h1 and h2 and other text format tags to play around with font styling.
THEN: move on to trying to make the structure of a page with CSS. Once you "get" applying style to specific markup tags, it's easier to get the hang of structure.
I'll admit, it takes a lot of playing around to wrap your head around the box structure that CSS insists on, but it is completely and utterly worth it.
posted by griffey at 2:04 PM on March 27, 2007
First, concentrate on learning to use it for styling text...make your paragraph tags have style associated with them via CSS rather than directly embedding the styling in the HTML. Use h1 and h2 and other text format tags to play around with font styling.
THEN: move on to trying to make the structure of a page with CSS. Once you "get" applying style to specific markup tags, it's easier to get the hang of structure.
I'll admit, it takes a lot of playing around to wrap your head around the box structure that CSS insists on, but it is completely and utterly worth it.
posted by griffey at 2:04 PM on March 27, 2007
Instead of adding a border to tell where my boxes are, I use a background color that's not part of the layout, because the border could shift things out of place.
posted by kirkaracha at 2:07 PM on March 27, 2007
posted by kirkaracha at 2:07 PM on March 27, 2007
I've been pointing table using maelfactors at Zeldmans Designing With Web Standards. It's okay as a how-to, lousy as a reference but excellent as an explantion of WHY you want to move away from tables, fonts etc...
posted by Artw at 2:07 PM on March 27, 2007
posted by Artw at 2:07 PM on March 27, 2007
Maybe if you dig into the "why" of CSS a bit first you'll find it easier to get interested in the "how".
I'd recommend stating with Jeffrey Zeldman's books Taking Your Talent to the Web: Making the Transition from Graphic Design to Web Design and particularly Designing with Web Standards.
posted by timeistight at 2:07 PM on March 27, 2007
I'd recommend stating with Jeffrey Zeldman's books Taking Your Talent to the Web: Making the Transition from Graphic Design to Web Design and particularly Designing with Web Standards.
posted by timeistight at 2:07 PM on March 27, 2007
Redo (one of) your existing web-sites using CSS. Don't try to make it look *exactly* the same, that will be too hard. That way you will learn by necessity, rather than from some dry tutorial.
posted by nowonmai at 2:10 PM on March 27, 2007
posted by nowonmai at 2:10 PM on March 27, 2007
handee is correct.
css is all about separating layout from content. you create a stylesheet that contains your layout "rules". you link to it in the header of your html document.
you then anchor those rules by their rule-names (which are found in the stylesheet, the rule parameters being contained inside the {} brackets of each rule) in the html, by grouping/separating various html elements by given them 'class"es or "id"s. you can override html element parameters and you can do this with pretty much anything:
body
h1, h2, p, h3...
a (links)
css is flexible, and there is usually more than one way of creating an intended effect (so as you get better, you develop a distinct style).
posted by phaedon at 2:18 PM on March 27, 2007
css is all about separating layout from content. you create a stylesheet that contains your layout "rules". you link to it in the header of your html document.
you then anchor those rules by their rule-names (which are found in the stylesheet, the rule parameters being contained inside the {} brackets of each rule) in the html, by grouping/separating various html elements by given them 'class"es or "id"s. you can override html element parameters and you can do this with pretty much anything:
body
h1, h2, p, h3...
a (links)
css is flexible, and there is usually more than one way of creating an intended effect (so as you get better, you develop a distinct style).
posted by phaedon at 2:18 PM on March 27, 2007
I learned by taking a pre-made template and trying to make it look like the site I designed. But, that was incredibly frustrating. I agree that hands-on is the way to go, though.
I like griffey's suggestion of taking text first and then stepping up to layout.
Also, Dreamweaver has some nice CSS editing capabilities. Purists probably scream at the thought, but it is a nice away to get familiar with all the things you can do with CSS. When you edit the CSS with Dreamweaver you select from menus and fill in boxes in a dialog box rather than coding. Then from there, you start to pick up what all that code means. I would suggest the newest version of Dreamweaver, though. It seems to display CSS much more accurately.
posted by bristolcat at 2:20 PM on March 27, 2007
I like griffey's suggestion of taking text first and then stepping up to layout.
Also, Dreamweaver has some nice CSS editing capabilities. Purists probably scream at the thought, but it is a nice away to get familiar with all the things you can do with CSS. When you edit the CSS with Dreamweaver you select from menus and fill in boxes in a dialog box rather than coding. Then from there, you start to pick up what all that code means. I would suggest the newest version of Dreamweaver, though. It seems to display CSS much more accurately.
posted by bristolcat at 2:20 PM on March 27, 2007
CSS layouts do require a slightly different mindset than the table-based nonsense we taught ourselves back in the day. Fortunately, you have many resources to draw from that I didn't.
Download Firefox and the web development toolbar. It will allow you to highlight CSS elements, turn them off completely, etc. It's a great way to get a feel for how the CSS file is modifying the markup.
If you're on a Mac, give CSSEdit a try. It makes organizing and visualizing your style sheet a joy. So much better than messing around with BBEdit or Dreamweaver. I'm not certain if there's an equivalent application on the Windows side, but perhaps someone can suggest one.
If book learning suits you, check out Hakon Wium Lie's Cascading Style Sheets: Designing for the Web. It's accessible, comprehensive, and written by the guys who came up with CSS in the first place.
Finally: If you're at all serious about web design and production, you have to adjust to CSS layouts and the box model. Dreamweaver (on preview I'll add - unless it's used properly), font tags and crunchy tables won't cut it anymore.
posted by aladfar at 2:22 PM on March 27, 2007
Download Firefox and the web development toolbar. It will allow you to highlight CSS elements, turn them off completely, etc. It's a great way to get a feel for how the CSS file is modifying the markup.
If you're on a Mac, give CSSEdit a try. It makes organizing and visualizing your style sheet a joy. So much better than messing around with BBEdit or Dreamweaver. I'm not certain if there's an equivalent application on the Windows side, but perhaps someone can suggest one.
If book learning suits you, check out Hakon Wium Lie's Cascading Style Sheets: Designing for the Web. It's accessible, comprehensive, and written by the guys who came up with CSS in the first place.
Finally: If you're at all serious about web design and production, you have to adjust to CSS layouts and the box model. Dreamweaver (on preview I'll add - unless it's used properly), font tags and crunchy tables won't cut it anymore.
posted by aladfar at 2:22 PM on March 27, 2007
I second the recommendation for finding inspiration in the CSS Zen Garden. I've also gotten a lot mileage from putting a border around everything, as unexpected suggested.
IMO, CSS is halfway between an art and a science. Things work logically for the most part, but not always, especially when you consider browser incompatibilities. This can make it frustrating and intimidating to learn. It might help to just accept that you'll always be facing some ambiguity but, at the same time, that the only way to improve your ability to use CSS is through practice. If you feel lost at first, don't sweat it -- I think even veteran CSS coders feel lost sometimes.
posted by treepour at 2:23 PM on March 27, 2007
IMO, CSS is halfway between an art and a science. Things work logically for the most part, but not always, especially when you consider browser incompatibilities. This can make it frustrating and intimidating to learn. It might help to just accept that you'll always be facing some ambiguity but, at the same time, that the only way to improve your ability to use CSS is through practice. If you feel lost at first, don't sweat it -- I think even veteran CSS coders feel lost sometimes.
posted by treepour at 2:23 PM on March 27, 2007
Thank you all, these are excellent suggestions. I think I now have the courage to press on...
posted by luckyshirl at 2:24 PM on March 27, 2007
posted by luckyshirl at 2:24 PM on March 27, 2007
Thanks for asking! I almost posted a very similar question, but chickened out at the last minute.
posted by Alpenglow at 2:26 PM on March 27, 2007
posted by Alpenglow at 2:26 PM on March 27, 2007
I hit a similar wall in learning to code CSS, and honestly, I didn't get past it until I signed up for a course at my local university. I needed an instructor explain it to me, and be there to answer my questions.
The book we used in class, and that I know have as a reference, is Eric Meyer's Cascading Style Sheets: The Definitive Guide.
This web developer toolbar extension for Firefox lets you view and tinker with the stylesheet of any webpage. It will also outline elements for you (instead of you adding a border, as others are suggesting).
Good luck!
posted by donajo at 2:27 PM on March 27, 2007
The book we used in class, and that I know have as a reference, is Eric Meyer's Cascading Style Sheets: The Definitive Guide.
This web developer toolbar extension for Firefox lets you view and tinker with the stylesheet of any webpage. It will also outline elements for you (instead of you adding a border, as others are suggesting).
Good luck!
posted by donajo at 2:27 PM on March 27, 2007
I was exactly like you, I just didn't "get" CSS. Then, one day, I made a simple style sheet and applied it in a few pages. I started very simple so it would work. Then I added stuff. Believe it or not, that little exercise made CSS click for me.
posted by jayder at 2:28 PM on March 27, 2007
posted by jayder at 2:28 PM on March 27, 2007
Firstly, make sure you're working with valid, well-structured markup (and a proper DOCTYPE), using the right tags in the right order with just a few DIVs to group areas of the page. Don't think about layout, just the logical structure (although most pages need tweaking later to suit the styling).
Start with specifying fonts and colours for different tags; that's pretty simple and you shouldn't have any problems with stuff like h1{color:#000}
Then move on to widths, margin and padding. There are some quirks you'll need to understand later, but just get to grips with the basics.
Next up is positioning and floats. Play with floating fixed-width boxes left and right, and understand how you have to 'clear' floats before placing something below or closing the element containing the floats. Instead of creating a table-based grid, you're pushing boxes left or right, and can put boxes within boxes. Try out absolute positioning, including absolute positioning within a container that has position:relative applied.
Finally, look into sensibly arranging your CSS and using descendant selectors to target elements more effectively and avoid clutter.
From there it's all about learning quirks, tricks and workarounds, and becoming more familiar with the techniques. Once you get your head around it you'll never want to touch hacky old markup again.
posted by malevolent at 2:39 PM on March 27, 2007
Start with specifying fonts and colours for different tags; that's pretty simple and you shouldn't have any problems with stuff like h1{color:#000}
Then move on to widths, margin and padding. There are some quirks you'll need to understand later, but just get to grips with the basics.
Next up is positioning and floats. Play with floating fixed-width boxes left and right, and understand how you have to 'clear' floats before placing something below or closing the element containing the floats. Instead of creating a table-based grid, you're pushing boxes left or right, and can put boxes within boxes. Try out absolute positioning, including absolute positioning within a container that has position:relative applied.
Finally, look into sensibly arranging your CSS and using descendant selectors to target elements more effectively and avoid clutter.
From there it's all about learning quirks, tricks and workarounds, and becoming more familiar with the techniques. Once you get your head around it you'll never want to touch hacky old markup again.
posted by malevolent at 2:39 PM on March 27, 2007
It looks goofy as all-get-out, but I found Head First HTML with CSS & XHTML to be extremely easy to follow and understand. I recommend it highly.
posted by designbot at 2:48 PM on March 27, 2007
posted by designbot at 2:48 PM on March 27, 2007
malevolent lays it out well. There are certainly some poorly-charted regions of CSSland that can trip up even an experienced designer, but learning selectors, the box model, positioning, and floats will take you a long way.
The nice thing about table layout is that it's easy to understand conceptually—in some ways, moreso than the conceptual framework behind CSS layout. CSS does let you do a bunch of neat things, though. Stick with it.
posted by adamrice at 3:35 PM on March 27, 2007
The nice thing about table layout is that it's easy to understand conceptually—in some ways, moreso than the conceptual framework behind CSS layout. CSS does let you do a bunch of neat things, though. Stick with it.
posted by adamrice at 3:35 PM on March 27, 2007
As mentioned previously, there are steps:
1. Formatting text and the like is way too easy
2. Layout of pages is way too hard
3. Then it all comes together and starts making A LOT of sense -
It is totally worth it, but it took me several years to get over step 2.
posted by magullo at 3:40 PM on March 27, 2007
1. Formatting text and the like is way too easy
2. Layout of pages is way too hard
3. Then it all comes together and starts making A LOT of sense -
It is totally worth it, but it took me several years to get over step 2.
posted by magullo at 3:40 PM on March 27, 2007
Thirding css zen garden. It shows you css by example, and the fact that the designs look amazing is motivating. Too many tuts just put ugly boxes and borders on everything. The zen garden book is great too. (i only found the website later!)
posted by kamelhoecker at 4:11 PM on March 27, 2007
posted by kamelhoecker at 4:11 PM on March 27, 2007
nth-ing the suggestions to start simple. Pick a single style you use repeatedly on a page - bold text for headers, red text for emphasis, etc - and create a style for that. Do that with another style or two, getting used to using it each time. Then, move on to combining them.
Finally, play with positioning - spans, divs, floating, positioning, etc. Don't try to replace your table-based positioning in 1 step - try something simple, like a sidebar box. See how the positioning works and reacts with the normal page flow, how nesting works, etc.
After you've reached this point is the time to look at the zen garden book or website...
CSS doesn't impose the box structure - it just exposes the box model that's already there underneath. It's not hard, but it is more complicated. Once you realise tables, etc, are essentially shortcut macros to the individual bits of the box model, you'll be comfortable - and start to see how & why CSS renders differently on different browsers. (Reading the W3C documentation helps too - by this stage, you'll be able to see where the holes and ambiguities are in the specification).
As a bonus, you'll now why why, say, a table of width 100% renders differently in IE to FF to Safari to Opera to ...
posted by Pinback at 4:37 PM on March 27, 2007
Finally, play with positioning - spans, divs, floating, positioning, etc. Don't try to replace your table-based positioning in 1 step - try something simple, like a sidebar box. See how the positioning works and reacts with the normal page flow, how nesting works, etc.
After you've reached this point is the time to look at the zen garden book or website...
CSS doesn't impose the box structure - it just exposes the box model that's already there underneath. It's not hard, but it is more complicated. Once you realise tables, etc, are essentially shortcut macros to the individual bits of the box model, you'll be comfortable - and start to see how & why CSS renders differently on different browsers. (Reading the W3C documentation helps too - by this stage, you'll be able to see where the holes and ambiguities are in the specification).
As a bonus, you'll now why why, say, a table of width 100% renders differently in IE to FF to Safari to Opera to ...
posted by Pinback at 4:37 PM on March 27, 2007
I have that exact same problem. Everytime I try learning CSS (doesnt matter what tutorial I follow).. there comes a point where I feel like I'm being fed to much, to fast and my brain shutsdown and refuses to learn.
I REALLY , REALLY , REALLY , REALLY wish there was a tutorial that started out with a completely blank page. and then added 1 element (such as some text).. and then added one more element (like more text).. and then maybe a box.. ,etc..
Yeah.. I need "CSS for dummies"... All the books I've read start throwing around acronyms and techno words and it kills it for me every time.
Sadly..I can do alot of other technical things like a wiz.. but for some reason CSS (and other coding) just eludes me.
posted by jmnugent at 4:38 PM on March 27, 2007
I REALLY , REALLY , REALLY , REALLY wish there was a tutorial that started out with a completely blank page. and then added 1 element (such as some text).. and then added one more element (like more text).. and then maybe a box.. ,etc..
Yeah.. I need "CSS for dummies"... All the books I've read start throwing around acronyms and techno words and it kills it for me every time.
Sadly..I can do alot of other technical things like a wiz.. but for some reason CSS (and other coding) just eludes me.
posted by jmnugent at 4:38 PM on March 27, 2007
I REALLY , REALLY , REALLY , REALLY wish there was a tutorial that started out with a completely blank page. and then added 1 element (such as some text).. and then added one more element (like more text).. and then maybe a box.. ,etc..
That's a really good idea! There isn't such a book? WE should make one. I bet it would help a lot of people.
Here's a start (I'm using square brackets for the html, because formatting angle-brackets in MeFi makes me insane:
posted by grumblebee at 5:35 PM on March 27, 2007
That's a really good idea! There isn't such a book? WE should make one. I bet it would help a lot of people.
Here's a start (I'm using square brackets for the html, because formatting angle-brackets in MeFi makes me insane:
[html]
[head]
[style]
h1 {
font-size: 25px;
}
[/style]
[head]
[body]
[h1]This is level-one text[/h1]
[body]
[/html]
This page will display the text "This is level-one text", and the characters will be 25px high.posted by grumblebee at 5:35 PM on March 27, 2007
This is a pretty cool resource. It has tons of simple examples (start at the top). You can see code and the resulting page, side-by-side, and you can edit the code and see the changes.
posted by grumblebee at 5:38 PM on March 27, 2007
posted by grumblebee at 5:38 PM on March 27, 2007
Y'all are incredible!
posted by luckyshirl at 5:47 PM on March 27, 2007
posted by luckyshirl at 5:47 PM on March 27, 2007
I'm not a web guru but an architect but I play the role of web guru for my local organizations of architects. I learned HTML from studying what my wife (graphic designer) was studying. I don't know why but it clicked with me. Then along came CSS and I had a eureka moment. Not only did it make sense but it made über-sense -- I finally could see structure within the page and the content was simply that -- content. Indeed, I could even see how to draw with CSS (time consuming to be sure but doable to a degree -- until presented with the inconsistency of browsers). See the structure first and foremost. Start "drawing" CSS boxes and lines and borders and go from there…
posted by Dick Paris at 5:54 PM on March 27, 2007
posted by Dick Paris at 5:54 PM on March 27, 2007
I checked out the Dummies Guide to CSS from the library and found that it helped to get up to speed with the basics.
posted by JJ86 at 6:22 PM on March 27, 2007
posted by JJ86 at 6:22 PM on March 27, 2007
I might have come into this question a bit late, but can I ask you; what is the sticking point for CSS, for you?
People talk a lot about how CSS is about "separating style from content", but rarely go into much detail about how that is a good thing.
Are you familiar with MS Word, and using "styles" in Word?
There are two ways you can use Word. You can type up your document, and tell it to make this bold, and that 14pt, and put a border here, and put another border there, then select all the bits you want to make headings and make them each bold and 18pt and Arial, then you can select various paragraphs that are quotes that you want indented ,and go and adjust the indent arrow in the ruler for each of them, making sure you drag it to the same point each time.
Or..
You can make up a set of "styles":
- Title
- Heading 1
- Heading 2
- Paragraph
- Quoted Paragraph
You can define all the attributes for each of those "styles":
- Title:
18pt Arial Bold with a Blue Underline
- Paragraph:
12pt Times, 1.5 line spacing
- Quoted Paragraph:
Just like "Paragraph" except indented 2cm from the left-hand side.
Then when you write your document, you tell word "This is a Title"..."This is a Paragraph"..."This is a Heading 1".
Afterwards, if you decide you don't want the quoted paragraphs to be 2cm indented, you want them to be 3cm indented with a little blue border running along the left-hand margin. You don't edit the text. You edit the "style", and your whole document is automatically updated, everywhere you've defined something as a "Quoted paragraph".
This is what CSS is doing for HTML. It requires a bit of preparation - you have to think about the styles, and you have to think about the structure. You have to think about how you're going to break up your page - it's not just straight text anymore, suddenly it's headings and paragraphs and menus. So it requires preparation, just like setting up styles in Word requires preparation.
But once that's done, things become very easy. You can change the appearance of every page on your website by editing a single setting in your CSS file, whereas in the past, you would have to go and change every single font tag, for example.
posted by Jimbob at 6:40 PM on March 27, 2007
People talk a lot about how CSS is about "separating style from content", but rarely go into much detail about how that is a good thing.
Are you familiar with MS Word, and using "styles" in Word?
There are two ways you can use Word. You can type up your document, and tell it to make this bold, and that 14pt, and put a border here, and put another border there, then select all the bits you want to make headings and make them each bold and 18pt and Arial, then you can select various paragraphs that are quotes that you want indented ,and go and adjust the indent arrow in the ruler for each of them, making sure you drag it to the same point each time.
Or..
You can make up a set of "styles":
- Title
- Heading 1
- Heading 2
- Paragraph
- Quoted Paragraph
You can define all the attributes for each of those "styles":
- Title:
18pt Arial Bold with a Blue Underline
- Paragraph:
12pt Times, 1.5 line spacing
- Quoted Paragraph:
Just like "Paragraph" except indented 2cm from the left-hand side.
Then when you write your document, you tell word "This is a Title"..."This is a Paragraph"..."This is a Heading 1".
Afterwards, if you decide you don't want the quoted paragraphs to be 2cm indented, you want them to be 3cm indented with a little blue border running along the left-hand margin. You don't edit the text. You edit the "style", and your whole document is automatically updated, everywhere you've defined something as a "Quoted paragraph".
This is what CSS is doing for HTML. It requires a bit of preparation - you have to think about the styles, and you have to think about the structure. You have to think about how you're going to break up your page - it's not just straight text anymore, suddenly it's headings and paragraphs and menus. So it requires preparation, just like setting up styles in Word requires preparation.
But once that's done, things become very easy. You can change the appearance of every page on your website by editing a single setting in your CSS file, whereas in the past, you would have to go and change every single font tag, for example.
posted by Jimbob at 6:40 PM on March 27, 2007
for some reason CSS (and other coding) just eludes me.
Coding is hard, but it's really exciting when you get it, because you feel like you have complete control over these boxes that are such a large part of our lives.
There are a few mistakes that beginners make that make it harder for themselves. If you strive not to make them, you'll have a much easier (but not easy) time:
1) DON'T SKIMP ON TYPING. If you have to name something (e.g. a CSS class or a JavaScript variable), give it a long descriptive name. My co-workers laugh at me, because I make up names like redBorderAroundTheSmallGreenBox, but these names have saved my ass a zillion times. If I skimp and name thing rBorder, I won't be able to figure my code out the next time I look at it.
2) ADD COMMENTS. My rule is this: Every time I write some code, I ask myself whether it will make sense to me in a year. If my answer is no -- if I feel that if I tried to figure out my program by just looking at the code, I'd be even slightly confused -- I add a comment in English. I think hard about these comments. I write and re-write them. They are as important as the code itself.
3) TEST AS YOU GO. Don't write a hundred lines of code and then test them. Write two lines, test them; write another two, test them; and so on. Every time you make a testable change, test it then.
4) COPY/PASTE is your friend. The main problem with my long names is that, if I have to type them over and over, I risk making typos. So I don't retype them. I copy/paste them. I do this as a firm rule. Often I get cocky and feel like I can type them without screwing up. I'm often wrong.
5) CODE TO FORGET. One of the most difficult aspects of coding is how each part of the code tends to rely on other parts. A problem that seems to come from part A can actually be coming from parts B, C or D, because A relies on all of them. So you can get into these mental tangles in which you're trying to hold ten parts in your mind at once while you're troubleshooting. There's this nightmarish feeling that the only way you can figure things out is to think about the big picture -- but the big picture is just too big.
The secret is to get part D working. Treat it as an isolated machine. Once it's working, and you're sure it's working, you can forget about it. You need to know that it plugs into A, but that's all you need to know. You don't need to know how it works under-the-hood, because you know it DOES work. Do the same with B and C. And on the off-chance that you ever do have to pry open their tops and look inside, you'll be thankful for your long names and comments!
If possible, try to finish one part before you take a break. That way, when you come back from the break, you won't have to remember what you were doing. You'll know that part is finished and you can move on. If you MUST leave-off in the middle of a part, that's when you want to leave yourself super-duper, explicit comments.
6) COMMENT OUT. When a can't find a bug (you don't know which of many lines is causing an error), comment them all out (turn them all off) and then un-comment them one-by-one (turn them on one-by one) until something goes wrong.
7) KEEP CODE TOGETHER, THEN MOVE IT APART. Good programmers tend to divide their code up and keep each part in a different file, e.g. html in one file and css in another file. This is a good practice, but it can be confusing. In addition to figuring out your code, you have to navigate multiple windows or tabs as you work on several parts at once.
So keep all your code in one file at first. When you're sure it works, split it up.
At the very least, spend 20 minutes coming up with an optimum window/application arrangement, so that you can switch from file-to-file with ease.
8) LEARN YOUR EDITOR. Coding can can tedious (in terms of how much you have to type) and confusing (in terms of all the stuff you have to keep track of). Your editor is your friend, but only if you take the time to learn its advanced functions. No one want to read an editor's help manual, but do it anyway. It will pay off over and over. Most programming editors have dozens of tricks and shortcuts built in, and these will really help you.
For instance, in my editor, pressing CTRL+D copies the current line down to the next line. This simple shortcut has saved me hours of time, and I feel a little thrill each time I use it (yes, I'm that far gone!)
Spend some time googling and asking opinions about different editors.
9) YOU SUCK AT TYPING. If you're like most programmers, 90% of your errors will be typos. If you're like most programmers, you'll think 20% of your errors are typos. This incorrect assumption will lead you on wild goose chases.
When a block of code isn't working, go over it word-by-word (letter-by-letter if necessary) and look for typos.
Names (class names, variable names, etc.) are usually the culprit, especially if you have to type them multiple times in different parts of the code. The FIRST thing you should check is names -- even if (especially if) you're sure they're not the problem.
If a class called Header is not having any effect, you might have spelled it "Header" in the CSS and "header" in the HTML.
10) DEBUGGING IS FUN. If possible, play a mental game with yourself. After you finish coding, pretend it wasn't you who wrote the code. Pretend a friend handed it to you and told you, "I've written a program. It's almost perfect except for ONE little problem, and this little problem is gumming up the works. See if you're smart enough to find it."
Accept the challenge!
Try to see debugging as an exciting, intellectual detective game -- not as a horrible chore.
11) REWRITE. Novelists write rough drafts and then rewrite, rewrite, rewrite. Programmers should do the same. Often, I see that there's a problem with my code, and I can see that there are two ways to fix it: (1) create a quick hacky band aid and (2) do a massive rewrite. (2) is always better. If you only have time to do the hack today, do it. But then do the rewrite tomorrow.
12) LEARN EVERYTHING THREE TIMES IN THREE DIFFERENT WAYS. Don't just buy one book on CSS. But don't buy three books, either. Buy one book, read one online tutorial and watch one training video. Difficult subjects stick in your brain better if you learn them several different times in several different ways.
13) TRAIN. Coders are athletes. You're never done training. You should always be buying books, reading tutorials, etc.
posted by grumblebee at 6:41 PM on March 27, 2007
Coding is hard, but it's really exciting when you get it, because you feel like you have complete control over these boxes that are such a large part of our lives.
There are a few mistakes that beginners make that make it harder for themselves. If you strive not to make them, you'll have a much easier (but not easy) time:
1) DON'T SKIMP ON TYPING. If you have to name something (e.g. a CSS class or a JavaScript variable), give it a long descriptive name. My co-workers laugh at me, because I make up names like redBorderAroundTheSmallGreenBox, but these names have saved my ass a zillion times. If I skimp and name thing rBorder, I won't be able to figure my code out the next time I look at it.
2) ADD COMMENTS. My rule is this: Every time I write some code, I ask myself whether it will make sense to me in a year. If my answer is no -- if I feel that if I tried to figure out my program by just looking at the code, I'd be even slightly confused -- I add a comment in English. I think hard about these comments. I write and re-write them. They are as important as the code itself.
3) TEST AS YOU GO. Don't write a hundred lines of code and then test them. Write two lines, test them; write another two, test them; and so on. Every time you make a testable change, test it then.
4) COPY/PASTE is your friend. The main problem with my long names is that, if I have to type them over and over, I risk making typos. So I don't retype them. I copy/paste them. I do this as a firm rule. Often I get cocky and feel like I can type them without screwing up. I'm often wrong.
5) CODE TO FORGET. One of the most difficult aspects of coding is how each part of the code tends to rely on other parts. A problem that seems to come from part A can actually be coming from parts B, C or D, because A relies on all of them. So you can get into these mental tangles in which you're trying to hold ten parts in your mind at once while you're troubleshooting. There's this nightmarish feeling that the only way you can figure things out is to think about the big picture -- but the big picture is just too big.
The secret is to get part D working. Treat it as an isolated machine. Once it's working, and you're sure it's working, you can forget about it. You need to know that it plugs into A, but that's all you need to know. You don't need to know how it works under-the-hood, because you know it DOES work. Do the same with B and C. And on the off-chance that you ever do have to pry open their tops and look inside, you'll be thankful for your long names and comments!
If possible, try to finish one part before you take a break. That way, when you come back from the break, you won't have to remember what you were doing. You'll know that part is finished and you can move on. If you MUST leave-off in the middle of a part, that's when you want to leave yourself super-duper, explicit comments.
6) COMMENT OUT. When a can't find a bug (you don't know which of many lines is causing an error), comment them all out (turn them all off) and then un-comment them one-by-one (turn them on one-by one) until something goes wrong.
7) KEEP CODE TOGETHER, THEN MOVE IT APART. Good programmers tend to divide their code up and keep each part in a different file, e.g. html in one file and css in another file. This is a good practice, but it can be confusing. In addition to figuring out your code, you have to navigate multiple windows or tabs as you work on several parts at once.
So keep all your code in one file at first. When you're sure it works, split it up.
At the very least, spend 20 minutes coming up with an optimum window/application arrangement, so that you can switch from file-to-file with ease.
8) LEARN YOUR EDITOR. Coding can can tedious (in terms of how much you have to type) and confusing (in terms of all the stuff you have to keep track of). Your editor is your friend, but only if you take the time to learn its advanced functions. No one want to read an editor's help manual, but do it anyway. It will pay off over and over. Most programming editors have dozens of tricks and shortcuts built in, and these will really help you.
For instance, in my editor, pressing CTRL+D copies the current line down to the next line. This simple shortcut has saved me hours of time, and I feel a little thrill each time I use it (yes, I'm that far gone!)
Spend some time googling and asking opinions about different editors.
9) YOU SUCK AT TYPING. If you're like most programmers, 90% of your errors will be typos. If you're like most programmers, you'll think 20% of your errors are typos. This incorrect assumption will lead you on wild goose chases.
When a block of code isn't working, go over it word-by-word (letter-by-letter if necessary) and look for typos.
Names (class names, variable names, etc.) are usually the culprit, especially if you have to type them multiple times in different parts of the code. The FIRST thing you should check is names -- even if (especially if) you're sure they're not the problem.
If a class called Header is not having any effect, you might have spelled it "Header" in the CSS and "header" in the HTML.
10) DEBUGGING IS FUN. If possible, play a mental game with yourself. After you finish coding, pretend it wasn't you who wrote the code. Pretend a friend handed it to you and told you, "I've written a program. It's almost perfect except for ONE little problem, and this little problem is gumming up the works. See if you're smart enough to find it."
Accept the challenge!
Try to see debugging as an exciting, intellectual detective game -- not as a horrible chore.
11) REWRITE. Novelists write rough drafts and then rewrite, rewrite, rewrite. Programmers should do the same. Often, I see that there's a problem with my code, and I can see that there are two ways to fix it: (1) create a quick hacky band aid and (2) do a massive rewrite. (2) is always better. If you only have time to do the hack today, do it. But then do the rewrite tomorrow.
12) LEARN EVERYTHING THREE TIMES IN THREE DIFFERENT WAYS. Don't just buy one book on CSS. But don't buy three books, either. Buy one book, read one online tutorial and watch one training video. Difficult subjects stick in your brain better if you learn them several different times in several different ways.
13) TRAIN. Coders are athletes. You're never done training. You should always be buying books, reading tutorials, etc.
posted by grumblebee at 6:41 PM on March 27, 2007
If you use Firefox, you should grab Firebug. Among other things, you can open Firebug, select "Inspect", and then start hovering over parts of a page, and it will outline each element and show you what styles are being applied. It's kind of hard to describe but it's insanely fun to use.
posted by anaelith at 6:50 PM on March 27, 2007
posted by anaelith at 6:50 PM on March 27, 2007
Oh and in general grumblebee has some very useful advice for programming (-cough- CSS is not programming, it is just markup, but n'mind that), but please don't use names like redBorderAroundTheSmallGreenBox ... because what if you change the colour/layout? Then you've got a blue "red border around the small green box" around a large purple oblong....
Names should be descriptive of function, rather then form... "usernameInput", "usernameInputHighlight", etc.
(Yes, it's a mindset that you get into. And you start deciding that instead of printing out a few emergency contact sheets, you should project them onto your walls, so that you only have a single point of change in case someone gets a new phone number...)
posted by anaelith at 6:57 PM on March 27, 2007
Names should be descriptive of function, rather then form... "usernameInput", "usernameInputHighlight", etc.
(Yes, it's a mindset that you get into. And you start deciding that instead of printing out a few emergency contact sheets, you should project them onto your walls, so that you only have a single point of change in case someone gets a new phone number...)
posted by anaelith at 6:57 PM on March 27, 2007
Thanks for pointing that out, anelith. If you're naming CSS rules things like blueBox or leftColumn, you're not thinking in CSS yet. You'll regret the blueBox name when you decide to make the box yellow. Then you'll have a yellow box called blueBox.
It's a little confusing, because CSS is about style (color, etc.), and yet you shouldn't use style-attributes in your names.
This is because you're not naming the styles, you're naming the objects that the styles will be applied to.
anaelith, you're right, CSS writing is coding, but it's not programming. But most of those tips have served me well when doing any kind of coding.
posted by grumblebee at 7:14 PM on March 27, 2007
It's a little confusing, because CSS is about style (color, etc.), and yet you shouldn't use style-attributes in your names.
This is because you're not naming the styles, you're naming the objects that the styles will be applied to.
anaelith, you're right, CSS writing is coding, but it's not programming. But most of those tips have served me well when doing any kind of coding.
posted by grumblebee at 7:14 PM on March 27, 2007
I'm convinced the 'various online tutorials' could not teach you CSS, not because you are defective, but because they suck. Most books on CSS do too. They cover 'A takes precedence over B' and 'Y takes precedence over X' but they never, ever get all the combinations of A, B, X, and Y that are needed to fully specify the situation. The Definitive Guide does not suck, and I too recommend it. And second, or nth, what malevolent and grumblebee laid down.
posted by eritain at 7:16 PM on March 27, 2007
posted by eritain at 7:16 PM on March 27, 2007
These days, you can use a CMS like Wordpress or Movable Type. They'll give you all the content, and you can focus on the CSS.
No affiliation to either company, but I've used and I like both wp and mt
posted by theiconoclast31 at 7:45 PM on March 27, 2007
No affiliation to either company, but I've used and I like both wp and mt
posted by theiconoclast31 at 7:45 PM on March 27, 2007
One thing helping me is to start with the "style" attribute in regular html code. It's not proper CSS yet, but you can start learning the vocabulary without altering your workflow. So instead of using font you could use < p color: #f00;> around some text.
Once you've figured enough of that out, you'll want to start making style sheets just to avoid all the copy and pasting. So the progression to CSS is a lot more natural than the tutorials that want you to replace all your italics with span class="kindofimportant" right away.
posted by Gary at 8:46 PM on March 27, 2007
Once you've figured enough of that out, you'll want to start making style sheets just to avoid all the copy and pasting. So the progression to CSS is a lot more natural than the tutorials that want you to replace all your italics with span class="kindofimportant" right away.
posted by Gary at 8:46 PM on March 27, 2007
In Firefox, you can install the extension Stylish and have a look at userstyles.org.
That extension lets you change the styles on any webpage Firefox sees. It is fairly good for immediately seeing how a style change affects a page. (note: you should generally stick in an !important to make sure your style overides the pages current style - e.g. 'a {color: red !important}'.)
posted by MonkeySaltedNuts at 11:28 PM on March 27, 2007
That extension lets you change the styles on any webpage Firefox sees. It is fairly good for immediately seeing how a style change affects a page. (note: you should generally stick in an !important to make sure your style overides the pages current style - e.g. 'a {color: red !important}'.)
posted by MonkeySaltedNuts at 11:28 PM on March 27, 2007
These days, you can use a CMS like Wordpress or Movable Type. They'll give you all the content, and you can focus on the CSS.
If you really want to learn css this is bad advice, not to mention you'll be overwhelmed. Start from the ground up with a very basic html file and have some fun. Start small, experiment, don't short cut. It'll be worth it in the long run.
posted by justgary at 2:36 AM on March 28, 2007
If you really want to learn css this is bad advice, not to mention you'll be overwhelmed. Start from the ground up with a very basic html file and have some fun. Start small, experiment, don't short cut. It'll be worth it in the long run.
posted by justgary at 2:36 AM on March 28, 2007
forgot to mention but there is a Web Developer Toolbar for Firefox which is amazing for understanding/debugging CSS. (There is also one for IE which is less amazing, but still useful.)
posted by kamelhoecker at 6:49 AM on March 28, 2007
posted by kamelhoecker at 6:49 AM on March 28, 2007
I had same problem - Hands on Training Dreamweaver 8 Daniel Short and Garo Green did the trick. Helped me eith Dreamweaver (Which I thought I knew) AND CSS.
Go for it
posted by dodialog at 8:38 AM on March 30, 2007
Go for it
posted by dodialog at 8:38 AM on March 30, 2007
I have difficulty with css too. I learnt html from basics/notepad and CSS just too wierd. I work more in php or ASP notepad style coded at work for internal stuff where it doesnt matter if theres no style.
posted by browolf at 10:55 AM on October 21, 2007
posted by browolf at 10:55 AM on October 21, 2007
This thread is closed to new comments.
If you can't find a site right off the back, I'd suggest picking one from Open Web Design. Org
posted by bleucube at 1:57 PM on March 27, 2007