It seems that everybody else is designing css a bit different from me, mine render correctly I just want to know if I am doing everything correctly. If not what is it that im doing wrong... Here is a recent site I did in css: http://www.ebushing.com (I know that I dont have a style.css file for it, thats what the client wanted). Thank you in advance!
Well, I'm seeing a few things that are 'wrong' - not with the CSS you use, so much as how you use it. 1) You inlined the CSS on each page. Since those pages all share common styles that's what an EXTERNAL stylesheet is for. Pretty much if you use the STYLE attribute OR the STYLE tag, you're missing the point of using CSS. 2) You assume the default line-heights are going to be correct - which is completely inconsistent cross-browser and likely why I'm seeing four different spacings in four different browsers. 3) You used px metric fonts on the content. This is a complete accessibility /FAIL/... hell you'd be better off with pt than what you have now, though %/em exists for a reason! (assuming one remembers that on LF/120dpi both %/em and pt are supposed to auto-enlarge 25%, and on some handhelds will start out at 78% the size of a desktop) 4) You are absolute positioning EVERYTHING and using a fixed height image behind your content. This means if you add/remove content to be taller than your image the site breaks. It means if you switch to using dynamic fonts, your site layout might break. Overall though, I'd say your biggest problem lies not in your CSS, it's in your markup - and I can't believe I'm saying this to someone - it's your LACK of markup. 1) Tranny Doctype. Transitional is for supporting old/outdated half-assed crap from 1997, NOT for building new websites. 2) No language encodings 3) No media types for your styling 4) No images off graceful degradation. See how the site title and contact info are static images? People browsing with images off (like people on metered connections), handheld users for whom your images don't fit the screen, SEARCH ENGINES... you get the idea. 5) On the home page you've got what looks like a paragraph and a list. Why no list tag... Either that or you've got REALLY bad grammar. "This means: We have it" - I'm assuming that you wanted a double break there... Though if you are using double breaks in your markup, you are probably doing something wrong! 6) you've got content images in the CSS. I'm all for moving images out of the markup to the CSS, but not when they are CONTENT. Both .image1 and .image2 appear to be content images, so those SHOULD be IMG. 7) outdated and unneccessary attributes like 'target' - that particular one stands out because we aren't supposed to use it anymore unless you have framesets, and targeting 'self' without framesets is redundant since that's the default behavior of all links! 8) Invalid markup. Your home page is fine, but the products page has a laundry list of "what the devil" in there. For example: <a href="srb1.html" target="_self" ><li>Standard Radial Bushings</li></a> COMPLETELY invalid markup. Anchor is an inline-level tag. LI is a block level tag. Inline-level tags CANNOT contain block-level ones. (HTML level has NOTHING to do with CSS 'display' apart from being the default value!) and the only tag UL's, OL's or other item (LI) based lists can directly contain is LI. Meaning those should all be: <li><a href="srb1.html">Standard Radial Bushings</a></li> You want the whole LI area to be able to be clicked (I'm assuming that's why you did it that way) make the anchor display:block. This particular coding problem is likely why most of them aren't clickable in Opera... and I bet you don't get a lot of people clicking on those links in the first place since there are ZERO visible clues to tell the user they are links. No hover states, no underlines, no differentiation of color; That's bad design. It's an accessibility /FAIL/, poorly coded with little to no SEO. It also doesn't help a whole lot that the static content common to every page takes up a full third of the screen height on my 1200px tall display. You're pushing the content too far down the display for 800x600 users, likely meaning they won't even see the content on the homepage... I'd consider taking an axe to that orange 'information' box, and move the office info and warehouse info up next to the site logo; lord knows you've got the room. ... and work on image encodings a bit. There's a bit of a "christ, it's 200k for THAT?!?" going on there. Being saturday morning I might have some time once I shower and eat. You've got such a simple layout it should only take me a few minutes to rewrite that home page into how I'd do it - so you can see the difference. I'll document what/why certain choices were made in it's creation so you can understand why you're seeing it done differently by others. Though I'd point out, you're already head and shoulders over most of the people on forums like DP since you seem to have a minimalist at heart when writing your HTML... You did not slap DIV's around everything willy-nilly - hell, your biggest problem is a LACK of markup; something I RARELY encounter.
... and here's that rewrite: http://www.cutcodedown.com/for_others/vinogradov/template.html As with all my examples the directory: http://www.cutcodedown.com/for_others/vinogradov is unlocked so you can grab the gooey bits. It's valid XHTML 1.0 Strict, would be valid CSS2 if I hadn't had to resort to a few IE and FF workarounds like zoom and -moz. Tested working IE 5.5, 6, 7 & 8, FF 2 and 3.6, Opera 10.10 and 10.5 beta, and the latest iterations of Saffy and Chrome. To break it down, lets start in the markup. First, XHTML 1.0 STRICT. No reason not to. We also have the language incoding both for XML and non-XML covering our bases, as well as a content-language meta. I use LINK to make the stylesheet external. Include it on every page, put every page's CSS into it. Why? Because it's cached across pages so dimes to dollars if they visit more than one page on your site, you just saved bandwidth. You'll notice I use media types, and left commented out links to CSS for print and for handhelds. Because I used semantic markup I'd not dive too deep into making a handheld CSS; I'd probably just add FaC (fonts and colors) and leave it at that. Once we get out of the head and to our body, you'll see div#pageWrapper. This is where I set my width, or should I say min-width and max-width. This way I only have to set it ONCE on the page, not on a bunch of separate elements. For the heading... hey heading... don't we have TAGS for that? I use a H1 for the site logo because on my site designs I usually don't have or want an element that would be a unique H1 for every page on the site. that means either using multiple H1's (bad) or not having H1's on those pages (worse). Much like the title of a newspaper being on every page, or the title of a book being on every other page - the site title is my H1. All other headings are subsections of that. The span is there as a presentational hook to style that text much like the image we'll be replacing it with for images-off users, while the empty bold tag is a image sandbag we'll use to place the logo image OVER the h1 text hiding it. Given your graphics this is one of the few times I'd wrap a div around that UL... Oh wait, you didn't have that. Menus are LISTS of choices... So we use a unordered list for menu. You'll see I put in accesskeys - NORMALLY I rail against the use of the title attribute when it's the same as the content of the anchor, but in Opera it shows up on the accesskeys menu instead of the URL... so that's good accessibility. A full blown rewrite would include numbered versions of those links as well as a 'top', 'bottom' and 'next' link - that menu would be set to display:none for "screen" but shown on "handheld". All over the document you'll see me have HR's. Those are to divide up sections visually when CSS is not used. Handhelds, less capable browsers - throw them a bone, it's maybe 30 bytes for the whole document including the CSS to hide them in 'screen'. div#info is your yellow box. Instead of using an image I put the text in the page. I played with the styling a little too to make it a bit more CSS friendly. ".highlightBox .firstBorder" and ".hightlightBox .secondBorder" are an implementation of sliding doors using this image: http://www.cutcodedown.com/for_others/vinogradov/images/yellowBox.png We'll get to how that works in the CSS. For now let's just say .first shows the top/left, .second shows the top/right. The 'information' part is obviously the heading for this section. It has 3 parts, the stuff on the left, the stuff on the right, and the stuff in the center, so a div with ID for each of those. You'll notice I avoid using classes or div's with names like 'left' or 'right'. To me that's presentational markup and has no place on a page. If you're going to use a class, it should say what it is, NOT how it's going to appear. I also did NOT use paragraphs on those elements because GRAMATICALLY they are not paragraphs and/or flow text. HTML is not about layout or presentation, so the 'typesetting' meaning of paragraph should have jack **** to do with it's HTML meaning (and in fact had jack **** to do with it BEFORE CSS came along if you used them properly). The bottom border is built with a simple nested div. Outer div is bottom/left, inner div is bottom/right. Our #content div gets a topBorder that functions just like .bottomBorder does on #info. Instead of showing top/left and top/right our .firstBorder and .secondBorder div's only show the left and right 'tiled' parts of the image. For reference, that's this image: http://www.cutcodedown.com/for_others/vinogradov/images/contentBox.png Which gets a bit trickier than the previous one, using a technique I call Eight corners under one Roof since we're using one image file to do a job most people would use at LEAST eight to accomplish. The heading, paragraphs and lists don't need a whole lot of explanation - again though, double breaks are a miserable /FAIL/ since they don't actually say what anything IS. You have flow paragraphs, mark them up with P, you have a list of 'this means' - mark it up as a list. You have images in the content, use an IMG tag for them. Both those images get classes to indicate what they are. A trailing plate is TYPICALLY one you want to the right of the content (as opposed to a leading plate which goes before it), while a normal plate is centered and all to itself; pretty much what you had. This also means we can put alt text in so people with images off or unable to see images will be able to at least know there was an image there and what it was of. From there it's just the bottom border for the content and closing out everything... Ok, this is probably hitting up against the post limit for DigitalPoint. I'll write up the CSS and post that in my next response.
... continued - on to our screen.css First thing I put in every CSS file is a reset. My reset is smaller than the big ones like Eric Meyers... I dislike anything larger becuase usually it wastes time either changing things I don't want changed, or setting things I'm probably going to set different anyways. Just null margins and padding, strip borders off the two elements where they can be an annoyance, and DONE. Remember I said yank the horizontal rules? There it is. The body tag I set some padding so the edges of our images don't lie flush with the browser window. The comment there says it all, an extra half PX on the right to correct for firefox not rounding off widths properly. The text-align is also properly commented... The font size declaration you'll notice I condense to a single line. normal weight/style, 85% of the default size, 140% the font-size as our line-height (I like tall line-heights) and of course the face. Why %/em? Accessibility on the content. We want our content to automatically grow in size for large font/120dpi users, windows table users, and to shrink in size for many handheld users - all of whom will royally bitch you out if your content is done in px metric fonts. From there it's colors and background - you know how to use those - though again I find the condensed property a bit nicer to deal with. On the paragraph tag you'll see I pad the bottom. Up top we nulled the margins; I hate margins on paragraphs because you can have all sorts of margin-collapse issues - a 1em space below is just as good. #pageWrapper sets our width.. or not. You can see I rewrote it to a semi-fluid width design between 800 and 1152 friendly. Going wider would make long lines of text harder to read, going narrower would break the layout and really most anything using the 'screen' css in it's entirety these days should at LEAST be able to handle the 752 minimum width I come up with after taking 32px out for browser chrome and 8px side body padding. The position:relative is there so that if we declare width:100% inside it all browsers (ok, IE) will use the width of #pageWrapper instead of that of body. The auto-margin is of course centering for all standards compliant browsers. * html #pageWrapper is our IE 6/earlier fix for the complete lack of min/max-width in those browsers. First I set a fixed width should javascript (and therin expressions) be disabled. Then a simple expression can change that width value as appropriate to our low value, high value, or auto. This could undo having a haslayout trigger and IE will screw up all of our sliding doors and gilder-levin image replacements without it, so I resort to putting zoom:1; on it as a safeguard against that. The h1 also gets position:relative, but this is so that we can absolute position our <b> image sandbag off the H1's position. I set a width and center it, set up a font-size and some colors. Because we are interacting with an image-replacement we HAVE to use PX here, but thankfully at 36px nobody is going to bitch about it being too small. h1 span is set to display:block so that it is forced onto it's own line the same width as it's parent (our h1). I then invert it's colors just like the logo did, and add some letter-spacing to make it's text about the same width as the regular h1 text. I left some extra space on each side so that should one of our fallback fonts be used or a different renderer gets involved, there's some 'play'. h1 b - the image is larger than our h1 becuase I made large sections of it palette transparency to save a bit on the filesize, as evidenced by it being a 11k .png to your original 47k one. The top line ended up a transparency becuase I made it 128px in height to take advantage of a renderer encoding quirk - so we set it's top position to -1px so that the background of the h1 doesn't show through. The -50px is figured from our h1 being 307px and the image being 407px... 100px divided by 2. Width and height equal to the image and then the image itself, hiding our styled text for people using images. #mainMenu - the div gets overflow:hidden and a fixed height to stop IE5 from making it 3px too tall for god knows what reason. The left padding makes it so we see the left edge of the background image: http://www.cutcodedown.com/for_others/vinogradov/images/mainMenu.png while the margin-bottom is just to space us away from the next element. #mainMenu ul - first we turn off bullets since we don't want those. Text-align at this point SHOULD still be set for center, but IE6 has a habit of ignoring that on SOME systems so we have to set it again. The right padding is just there to make sure our centered menu items are perfectly centered. Showing mainMenu.png as "top right" shows the right half of the image - boom, there's our sliding doors allowing us to expand/shrink up to the 1280 width I made that image. You can see I also set a color so that when images are off it's still a bar. The next two lines I documented rather heavily in there, but again this is to get around a quirk in how LI work in terms of adding extra space between elements that we probably don't want. Because it's a fixed height image background we are forced to use px metric fonts unless we want a broken layout. I consider 14px to be the bare minimum when you are in that situation, and really 16px would have been better there but I didn't want to go too far from what you had on the original. #mainMenu li - I set these to display:inline and then don't even TRY to do anything more with them. Doing so might trip the 'staircase' bug in IE7, so just skip it. #mainMenu a - These I want to set padding on, both top/bottom and sides. We COULD use line-height to center them top to bottom, but given the background image is NOT equal height top to bottom because of the drop-shadows we're better off having a bit of control. To get top/bottom working we need a 'display:block' type, but we want them centered. Display:inline-block to the rescue. I included the -moz fallbacks needed for Gecko 1.8/earlier support just because a lot of people are still running around with FF 2.x or it's equivalents (like iceweasel). We undo the word-spacing/letter-spacing trick, turn off underlines, set that black color, and then I load the background image again... "Wait, he's loading it again?" - damned straight. If you look at the image you can see I made a darker version below the first one. I slide that up into view on hover. #mainMenu a:active, #mainMenu a:focus, #mainMenu a:hover - With these I slide that image up, and change the colors so there's plenty of visual cues that it's a working menu. .top / .bottom border - These are properties that regardless of what background you are going to have these elements are most likely to share in common. clearing floats 'just in case', overflow:hidden so that floats inside it are wrapped, haslayout trigger so that floats inside it are wrapped in IE, and the font-size fix so we can actually make this element shorter than the font-size in IE... You can see there's a lot of IE workarounds here. .top / .bottom div - the nested DIV also share some properties. They're floated to the right, and are 16px wide. Pretty simple. This technique as-is only works with opaque background images, it can be adapted for use with transparencies using some margin trickery, but for this page it's fine as is. .firstBorder - I use the height:1% haslayout trigger becuase for some reason zoom screws up IE 5.5, but withough haslayout IE6 for some reason refuses to show the background we load later on. The padding not only gets us clear of the image, but also contains our content padding. .secondBorder - I set this to wrap floats just because if you float something in your content, it's nice to know it will be contained. The zoom is there for much the same reason. Same padding as .first just on the opposite side, and FINALLY I set our text-align back to left. .highlightBox - this is our yellow-ish one. Background-color is so it will still look like a box with images disabled, margin-bottom is to space it away from our content area. If you look at the images for both areas you'll see I stripped off the top and bottom white padding; why waste bandwidth on whitespace? .highlightBox .firstBorder - set our background-image top-left. .highlightBox .secondBorder - set background top-right, there's our sliding doors. The top padding is to push our content down off the rounded corners. .highlightBox .bottomBorder - bottom left... hmm, see a pattern here? .highlightBox .bottomBorder div - bottom right - that's it for that box. .contentBox - setting the background color just like for .highlightbox The next four you can figure out from how .highlightBox works. We're just setting up our corners for sliding doors off our parent image. The only major difference is that on the DIV I'm using "-1264px 0px" because we want to be able to tile our content to any height, which means we have to take a bit different an approach. The .firstBorder and .secondBorder for .contentBox show this approach, -1280px lets us use our left half of the image. We HAVE to have the 'tiled' right part of our image on the far right for it to show properly, hence my use of putting the 'tiled' copy to the right of our 'corners' in the source image. Now that we have all our boxes done: #info h2 - I fix the font size of the h3 so that I can scale the center text area. The actual flow text is style dynamic, so fixing the heihgt of the headers at 16px or larger is acceptable. The negative margin-bottom allows our floats to be ridden up next to this text - I took some liberties with the styling but that goes with the territory of making that text and not a fixed image. #info h3. #info .subhead, #info .subhead h3 - again, fonts, padding, alignment, big deal. #info .office - gee, a float. #info .warehouse - hey, the opposite float with an opposite align. the bottom padding is just to make certain we push our box tall enough that the bottom border is past the background gradient. #content ul, #content ol - add some padding so we can see their bullets in the right place. #content li - space 'em out a bit #content h2 - dynamic font, dynamic padding. .leadingPlate, .trailingPlate, .plate - these are the three standard 'plate' types I use. I put the extra padding and border you had on the IMG tag instead of in the image like you had. Again that's static content you probably shouldn't be wasting image filesize on. ... and that's it for the CSS. So why use the 4k of HTML and 6k of CSS to your original's 4k of HTML all by itself? It does so much more. Accessible font sizes, dynamic width, dynamic height you NEVER have to worry about breaking if they want to add/remove content, no images for text, images off graceful degradation, CSS off graceful degredataion, semantic markup to help with SEO (though really the copy needs a rewrite for that), and, well, it now only uses 49k of images making the entire page at 59k almost a quarter what you had. Hope this answers your questions... actually, hope it makes you ask more questions. Questions are good. When you stop questioning things, THEN there's a problem.
Im not trying to defend myself, I asked for criticism & Love it, and thank you. CSS: 1) I already knew that, I use external stylesheets in my other sites. 2) Im not sure what that means? hope you explained it in your other posts. 3) Thanks, I can do that next time ! 4) What is the fix to this? I tried using fixed but that only worked in IE HTML: 1) I just used what dreamweaver gave me, Ill try to pay attention next time. 2) Ill look that up. 3) How do I write out these styles everytime I do a site? It seems like it would be a waste for a small business site that gets little views. 4) Actually, I dont fully get the idea, sorry, can you help me out with this one? 5)The client told me to copy and paste the paragraph, didnt catch it, but thanks again. 6) Explain just a little bit, but I think I got that main thing. 7) Will fix in the future. 8)Yeah, that is exactly what I was going for, thanks! Im only 16 and im trying to get a head start on this, your a really big help. Now ill read your other 2 posts.
another question, might be really stupid: But why do you sometimes use a . and sometimes use # when writing css? whats the difference? I always used a . and, what is an easy to learn css book that I could get? is the sitepoint one any good? Thanks again for your help.
Good to know. Do you use media types too? line-height is the height of a line of text - increasing it spaces lines apart, decreasing it can make text overlap on the vertical. The HTML specification does not actually say EXACTLY what the default line-height should be, though it recommends 120-130% the font-size. Like anything else where they don't say exactly what it should be, the various browser makers all went their own directions. For the most part IE, Webkit and Opera all use 120%, though their rounding differences can make the line-height vary by a PX or two. Firefox and other gecko based browsers on the other hand seem to willy-nilly vary between 120 and 130% almost at random, even in the same font face and size from line-to-line. Worse, the default line-height does NOT inherit if you change the font-size only on a 'child' element. I made a font size reference page a while back that shows what I mean by that at the bottom. http://battletech.hopto.org/html_tutorials/fontCompare/template.html Because of that I always declare line-height if I change my font-size... and at that point one may as well condense all the properties thus: font:normal 85%/140% arial,helvetica,sans-serif; (re: absolute positioning and fixed height graphics) Let elements go together in 'flow', using margin and float, not position:absolute; Absolute positioning should be reserved for effects like menu hovers or image replacement - it should NOT be used to position actual content type areas. As to the images, you slice them up into different elements and design them to be tileable as I did in my example. Oooph. I won't completely go off on you about that but if you'll look around you'll find I have a remarkably low opinion of Dreamweaver; saying things like "The only thing about Dreamweaver than can be considered professional grade tools are the people promoting it's use" or "The only thing you can learn from Dreamweaver is how NOT to build a website". (Both are quotes from a recently departed friend) You should put dreamweaver down (like Old Yeller) and go get a flat text editor testing in the REAL browsers, not some goofy preview pane. (re: media types) If it's getting little views, it's not promoted right.... It's actually pretty simple to do the three you need to think about if you use semantic markup. screen.css is simple, that's the one we're USED to thinking about. Handheld all you should really set is text align and colors (and some handheld browsers like Opera will use the colors and alignments from screen). Print leave black and white, pretty up the positioning, and hide things a user doesn't need when they print like menus. Accessibility is rarely a waste of time, and can be done pretty easily. re: images off degradation. A lot of people browse the internet with images off for a host of reasons - 50 miles north of me a good Internet connection is 56k dialup... you go to Utah, the Colorado's and get more than 20 miles from a major city, you're not going to FIND broadband so a lot of people disable images to make the 'modern' web usable. People on handhelds and in some other countries end up on 'metered' plans which limit how much they can download so they too will often disable bits and pieces of a page to not hit their limit. Screen readers for the blind and others don't see images - Search engines (which is how you get visits in the first place) don't even SEE images if you use them instead of text and as a rule of thumb are blind to ALT text too (like most attributes). Go into opera on your original, and under View > Images choose 'no images', you'll see the problem with the original page. Then check my rewrite, you'll see the difference. I used a technique called 'gilder-levin image replacement' on the logo, and made certain the menu also had fallbacks for images not present. It's called "graceful degradation" - when certain "gee ain't it neat" extras on the page are not available to the user agent (aka browser) the page should 'degrade' in a useful fashion. This means semantic markup when CSS isn't present, content for images when images aren't present, and having the page still FULLY accessible when javascript isn't present. All of those methods and technologies should ENHANCE a page, and NEVER supplant it's content. You will find some people out there who say don't bother with all that... Oh, but handhelds are only 1% of my traffic, oh but dialup is only 1% of my traffic, oh but who cares about the people in North Colorado, they're only 1%. You start adding up all those 1%'s and soon you've alienated a quarter of the Internet... It also helps to remember that 1% might not sound like a big deal, but that's currently around 150 million potential users; If your target demographic ends up falling into that 150 million... The 'oh but it's only 1% of my traffic' claim is also a bit flawed in it's logic, since you have to ask "Is that because the people on those technologies have no interest in your site, or is it because your site doesn't work on those technologies?" If your site doesn't work for those users, how can you trust your own numbers of what % of people want to use your page from those techs? But as I often say, Percentages can lie! When working as a developer you have to watch for stuff like that. Usually the client is looking to you to implement things like headings, paragraphs and lists. During my rewrite I noticed it was a copy/paste from something like Word. Look closely and you'll see I ripped out the styled quotes and replaced them with flat ones. It's an english language site - you can't write the content with 7 bit ascii here's something wrong The two pictures of the ball bearing I would make as IMG tags. They 'look' like content, not styling so let people (and search engines) know those images are there. Putting them in as images with alt text that says what they are, like 'ball bearing' or 'bearing sleeve' means that if someone does a google image search, they will possibly see that image listed and visit - garnering you traffic and possibly a conversion. Well, your minimalism in the HTML already puts you ahead of MOST adults in the development arena who haven't updated their skills since 1997 or are learning from decade out of date books and tutorials. At least you're not using tables for layout, slapping twenty div in before you even get to the first line of content, or doing things like classes for what should be semantic tags. You've got most of the basics down good and just need to explore deeper into accessibility, semantics and SEO. The only stupid question is one you know the answer to Periods indicate classes, number signs indicate ID's... which naturally has you asking : "What's the difference between an ID and a Class?" ID's are unique identifiers, this means you can only use the same 'id' once on a page. They can be used for a lot more than a class can be as you can directly target them individually from javascript (document.getElementById), and can be used like they were a 'name' type index in the URL. For example http://www.cutcodedown.com/for_others/vinogradov/template.html#content will automatically scroll the page down to the #content DIV. This is functionally identical to the old <a name="content"></a> links and what you are supposed to be using instead of them on a modern page. ID's also 'trump' classes in CSS - this is called 'specificity'. If you have this: <div id="articles"><div class="article"> Code (markup): if you send this CSS: #articles div { color:red; } .article { color:blue; } Code (markup): Normally in CSS whatever is stated LAST takes precedence, but because that first one is set with an ID it will always override the second one as being 'more important'. There's a whole host of situations in which that can be useful so it's a second reason to use an ID. But again, you can only have ONE instance of ID="somename" in your markup. Each name for an ID MUST be unique, while classes you can re-use over and over. If you mean "HTML and CSS the Right Way" by Ian Lloyd, then yes. He skips past a lot of outdated/outmoded coding practices; Though really it might be a bit TOO beginner oriented given what you are already able to do. I've been unable to find any advanced HTML or CSS book to recommend to people that seems to be worth a damn, most of them (as I've said already) seem a decade behind what professional developers are and should be doing. It's what I do.
I just downloaded his ebook and I will start reading it shortly, ill also try to do some tutorials in the near future Thanks again man !