SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 32
  1. #1
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Background image vs. usability, or, tables vs CSS

    Hello all,

    I'm in a bit of a rut.

    I'm trying to design a website with my paltry knowledge of HTML/CSS and it's actually going better than planned. But I've hit an obstacle.

    The website is not the simple column-defining, color setting, width-defining procedure as usual. It's a little more graphic than that and I want the content to be something which users can use to navigate.

    My first idea was to simply make the website in photoshop (I have) and slice it, setting <a> as I go and making each sliced image a button for navigation. That works. Then the problems begin.

    Dead center I want to import a blog, allowing my peers to write updates to the website without formal knowledge of coding. But I can't really put that code into the table. (And there's no way to layer content with just HTML/CSS that I'm aware of.)

    So the natural next step seems to be making a background image, then, utilizing CSS to fit content to where it needs to be. Simple, but the issue is this:

    Wouldn't a large, unsliced image be a bandwidth hog even by today's standards? I vaguely recall that slicing is an effort against this. If I place in my graphic content as the background, I'm just making one whopping image that browsers need to load.

    Is this even an issue? And if so, do I have options?

    Thanks!

  2. #2
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,564
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    Well normally just one image (if you compress it then it shouldn't be a problem) won't be a hassle at all, just make sure the image file isn't something ridiculous like a BMP where it takes a massive time to load.

    If you have more hten one image on the page then it would be best to have all the images combined into one file and then shift around that actual one "image" to find the specific "image" you are looking for .

    Normally for a content background youy would want it to be a repeating image that you can repeat because otherwise if the content is too long/short then the image would either be chopped off early or would end too early
    Twitter-@Ryan_Reese09
    http://www.ryanreese.us -Always looking for web design/development work

  3. #3
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    Well normally just one image (if you compress it then it shouldn't be a problem) won't be a hassle at all, just make sure the image file isn't something ridiculous like a BMP where it takes a massive time to load.

    If you have more hten one image on the page then it would be best to have all the images combined into one file and then shift around that actual one "image" to find the specific "image" you are looking for .

    Normally for a content background youy would want it to be a repeating image that you can repeat because otherwise if the content is too long/short then the image would either be chopped off early or would end too early
    This explains why it ends prematurely as well.

    Is that the repeat-y function?

    Thank you Ryan.

  4. #4
    I Love Licorice silver trophybronze trophy Datura's Avatar
    Join Date
    Aug 2006
    Location
    Florida USA
    Posts
    5,775
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Well, there are ways to get an image down in size, even if it is large. It just can not be a color heavy image, more of an image that is pale and gossamer.

    There is another technique that works quite well: On top of the last image layer create another layer filled with one color and set the opacity of it lower. Test it out what it does to your image, sometimes 70&#37; opacity works, sometimes it needs to be just 20%. Depends on what you want. That brings down the weight of a file a lot because now there is an all over hue.
    Ulrike
    TUTs: 1 2 3 4 5 6 7 8 9 10

  5. #5
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,564
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    Yes, if your content div is 800px wide for exampke, make a 800x5px (5px is a rough guestimate) and then just set the image on the content div and repeat-y it (down the y axis, think back to graphs from math class )
    Twitter-@Ryan_Reese09
    http://www.ryanreese.us -Always looking for web design/development work

  6. #6
    I Love Licorice silver trophybronze trophy Datura's Avatar
    Join Date
    Aug 2006
    Location
    Florida USA
    Posts
    5,775
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kp606 View Post
    This explains why it ends prematurely as well.

    Is that the repeat-y function?

    Thank you Ryan.
    Yes.
    repeat-x, the background image will be repeated only horizontally.
    repeat-y, the background image will be repeated only vertically.
    Ulrike
    TUTs: 1 2 3 4 5 6 7 8 9 10

  7. #7
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Datura View Post
    Well, there are ways to get an image down in size, even if it is large. It just can not be a color heavy image, more of an image that is pale and gossamer.

    There is another technique that works quite well: On top of the last image layer create another layer filled with one color and set the opacity of it lower. Test it out what it does to your image, sometimes 70% opacity works, sometimes it needs to be just 20%. Depends on what you want. That brings down the weight of a file a lot because now there is an all over hue.
    How clever!

    Thank you both. I will give this a try tomorrow. (I decided to leave the file on my work computer to save my sanity. )

  8. #8
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)


    I thought I had figured it out, but I still can't...

    Bit of a different issue:

    utilizing background-image is nice and all, but the problem is: how do I float an image map over where the navigation bar should be? ...and guarantee a resized window won't move it?

    Any solutions?

    Thanks!

    PS To give you an idea of the desired layout: http://kylepicone.com/images/CC_Website_BenV2.jpg
    Last edited by kp606; May 7, 2010 at 17:25. Reason: Added image.

  9. #9
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    To place something in the foreground over something else so that it will always be there if the page is resized you need to do the following.

    Set the content that is behind to position:relative in the CSS. Then add the content to go in front into the end of that position:relative and make it position:absolute. That will place it on top of the other content and you can then set the top and left as required to move it to exactly where you want it relative to what is behind it.

    A position:absolute block inside a position:relative block is positioned on top of the relative block and moves with it maintaining the same position.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  10. #10
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    To place something in the foreground over something else so that it will always be there if the page is resized you need to do the following.

    Set the content that is behind to position:relative in the CSS. Then add the content to go in front into the end of that position:relative and make it position:absolute. That will place it on top of the other content and you can then set the top and left as required to move it to exactly where you want it relative to what is behind it.

    A position:absolute block inside a position:relative block is positioned on top of the relative block and moves with it maintaining the same position.
    felgall, I'm afraid I don't follow. I'm not sure what needs what attribute.

    Here is the code for reference:

    Code:
    body {background-image:url("images/CC_Website_BenV2.jpg");
    background-repeat:repeat-y;
    position:relative;
    margin-left:auto;
    margin-right:auto;
    width:1024px;
    height:1390;}
    
    img.floatimage {border:0px;
    /*visibility: hidden;*/
    position: absolute;
    margin-left:72px;
    margin-right:72px;
    margin-top:154px;
    
    }

  11. #11
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,564
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    That snippet there should be working (althoug you should avoid auto margins on the body element along with position:relative (to have IE not break)
    Twitter-@Ryan_Reese09
    http://www.ryanreese.us -Always looking for web design/development work

  12. #12
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    That snippet there should be working (althoug you should avoid auto margins on the body element along with position:relative (to have IE not break)
    I did get it to work though I had to make a small change and I don't recall what now.

    Sadly however...

    I then realized I wanted to center the webpage. That seems to be a game changer.

    Code:
    body {background-image:url("images/CC_Website_BenV2.jpg");
    background-repeat:repeat-y;
    background-position:center;
    position: relative;
    width: 1024px;
    height:1390px;
    }
    
    
    img.floatimage {
    /*visibility: hidden;*/
    margin-left:auto;
    margin-right:auto;}
    
    /*for reference */
    /*{position:absolute;
    margin-right:72px;
    margin-left:72px;
    margin-top:154px;
    }*/
    I feel very silly for not being able to figure this out. But nothing I do will get the static image box to respond.

    I think felgall's advice is only applicable if the background image is statically set so as to not go anywhere.

    Again I'm sorry for all the questions.

  13. #13
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    That snippet there should be working (althoug you should avoid auto margins on the body element along with position:relative (to have IE not break)
    Change in plans! I'm sorry for being so needy.

    How do I achieve the same effect if I center the webpage utilizing auto margins (and all the proper IE precautions).

    I'm changing things like a madman but to no avail.

    Code:
    body {background-image:url("images/CC_Website_BenV2.jpg");
    background-repeat:repeat-y;
    background-position:center;
    /*position: relative;*/
    width: 1024px;
    height:1390px;
    }
    
    img.floatimage {
    /*visibility: hidden;*/
    position: absolute;
    margin-left:0;
    margin-right:0;
    margin-top:154px;}
    
    /*{position:absolute;
    margin-right:72px;
    margin-left:72px;
    margin-top:154px;
    }*/
    Is there a "center" code I'm not aware of? Is that in the HTML?
    Last edited by kp606; May 7, 2010 at 18:36. Reason: More detail.

  14. #14
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    There isn't much point placing the position:relative on the body - it is the particular part of the page that you want to align the element over that needs to have position:relative in order to place one element on top of another and keep them together as the viewport size is changed. If you leave off the position:relative THEN the position:absolute ends up relative to the body instead of relative to the element you want to tie it to.

    See http://www.felgall.com/cshow09.htm for an example of how to do it.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  15. #15
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    There isn't much point placing the position:relative on the body - it is the particular part of the page that you want to align the element over that needs to have position:relative in order to place one element on top of another and keep them together as the viewport size is changed. If you leave off the position:relative THEN the position:absolute ends up relative to the body instead of relative to the element you want to tie it to.

    See http://www.felgall.com/cshow09.htm for an example of how to do it.
    One of the two images involved is the background. I don't know if what you said still applies but it sounds as though you're interpreting this as two separate elements not in the background.

  16. #16
    Mouse catcher silver trophy
    Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,838
    Mentioned
    114 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by kp606 View Post
    Wouldn't a large, unsliced image be a bandwidth hog even by today's standards? I vaguely recall that slicing is an effort against this. If I place in my graphic content as the background, I'm just making one whopping image that browsers need to load.
    A large image will (for anyone with broadband, which is most people in the developed world - if your target market is likely to include a disproportionately high number of people who probably don't have broadband, you may need to rethink) download and quicker in a single image than if you dice and slice it - because then, usually the sum of the parts is greater than the whole, and you've got a load of extra overhead in terms of HTTP requests, not to mention all the extra code in the original document and the additional layout processing needed to reassemble the pieces.

    Dice and slice was needed maybe 10 years ago, but improved technology means it doesn't help any more. In fact, things have gone the other way - in 2004, A List Apart were advocating the use of Image Sprites, where far from splitting up one image into small ones, you combine all your small images into one large one!

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    To me, even starting out drawing some goofy picture in Photoshop is putting the cart before the horse. People do not visit websites for the goofy graphics you hang on the page, they visit for the CONTENT. That's why I advocate a content first approach...

    I figure out whoever started propagating this "design in photoshop" nonsense, and, well - they best avoid dark alleyways for a while. Most of the time you end up with design elements that are impractical to code resulting in blote, impractical in terms of filesizes, impractical from an accessibility standpoint. In general we're talking buggy broken train-wrecks that likely end up being crappy little stripe fixed width layouts with accessibility /FAIL/

    FIRST code the html with semantic markup and some standard styling containers and hooks - THEN create the layout with the CSS, and then only at the end should you be thinking about using the paint program to make graphics to hang on your layout.

    Even if you end up having to work from some stupid .PSD - you are best off forgetting the PSD even exists while making the markup, barely look at it when doing the layout in CSS, and most of the time throwing it away and making new images from scratch when hanging the graphics on it since 'slicing' usually doesn't give you images that work with techniques like CSS Sprites, sliding doors, or eight corners under one roof. Usually such designers don't even THINK about graceful degradation for things like Images off, CSS off, screen readers - and frankly if you aren't thinking about any of that while drawing your goof-assed PSD, you aren't thinking SEO either.

    ... and if nothing else, I still consider 64k for an entire page template without content the ideal target (thats HTML + CSS + JS + Images), and around 170k the upper limit I'll allow in my stuff.

    Giant bloated slow image backgrounds, slicing a PSD until the page is built on 50-100 separate files - these are ways to drive users AWAY from your site, not draw them in no matter how 'pretty' it is.

  18. #18
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    To me, even starting out drawing some goofy picture in Photoshop is putting the cart before the horse. People do not visit websites for the goofy graphics you hang on the page, they visit for the CONTENT. That's why I advocate a content first approach...

    I figure out whoever started propagating this "design in photoshop" nonsense, and, well - they best avoid dark alleyways for a while. Most of the time you end up with design elements that are impractical to code resulting in blote, impractical in terms of filesizes, impractical from an accessibility standpoint. In general we're talking buggy broken train-wrecks that likely end up being crappy little stripe fixed width layouts with accessibility /FAIL/

    FIRST code the html with semantic markup and some standard styling containers and hooks - THEN create the layout with the CSS, and then only at the end should you be thinking about using the paint program to make graphics to hang on your layout.

    Even if you end up having to work from some stupid .PSD - you are best off forgetting the PSD even exists while making the markup, barely look at it when doing the layout in CSS, and most of the time throwing it away and making new images from scratch when hanging the graphics on it since 'slicing' usually doesn't give you images that work with techniques like CSS Sprites, sliding doors, or eight corners under one roof. Usually such designers don't even THINK about graceful degradation for things like Images off, CSS off, screen readers - and frankly if you aren't thinking about any of that while drawing your goof-assed PSD, you aren't thinking SEO either.

    ... and if nothing else, I still consider 64k for an entire page template without content the ideal target (thats HTML + CSS + JS + Images), and around 170k the upper limit I'll allow in my stuff.

    Giant bloated slow image backgrounds, slicing a PSD until the page is built on 50-100 separate files - these are ways to drive users AWAY from your site, not draw them in no matter how 'pretty' it is.
    Thank you for your candid thoughts. But I am a designer, not a developer nor coder by training. This is all incredibly foreign to me. On the flipside, I could practically point at Photoshop and it'll do flips for me. Flash content, among other things, have made the web must prettier than it is today. Although I realize the types of loops people jump through to make that happen, I embrace it.

    I was able to solve my own problem by using containers, image maps, and breaking the background into three simple images.

    Though I understand your argument—and sympathize, to be sure—

    The limitations in web coding are numerous. There is only so much color and type can achieve. Even then... as you know, web standards on type are horrendous. CSS's flexibility is terrific but I wasn't going to be relegated to simple columns, navigation bars, and the Georgia typeface.

    What's more is that our organization is contending with hundreds of websites run and owned by the University. There is already over-saturation occurring with the University template, as well as even simpler templates. Students here range from the 18-22 age range and have little attention spans on top of that—add in difficult course loads and jam-packed Blackberries and you all of a sudden are blessed if you can get a few pages few a week, let alone, a day. Superficiality, given the audience, is nothing short of appropriate. "Clarity of information" is already being done 100x over in their books and emails. (Though I don't even think they'd know what that means!) There comes a point where clarity is interpreted as banal, and we can't let that happen.

    And your comments about accessibility are well-taken. But to be sure: No one will be looking at this mobile, and if they are, there's simply no point. I'm attempting to integrate accessibility into the HTML and will gradually test it as I progress. As I said, I'm new to web design so adding on the philosophy of "Internet for all," PLUS just the basic coding is tough. It may come second nature to you. It does not to me.

    Your argument also undermines those of us who are visual thinkers. I don't put words to a .txt file and hope to imagine what it will look like. It's also very disheartening. It's like describing a sketch prior to making a sketch: there's no substance.

    Regardless, this is to please the clients (my peers) so it will be reworked as needed. But thank you.
    Last edited by kp606; May 8, 2010 at 11:20. Reason: Clarity.

  19. #19
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Well, it does always depend on the target audience and what the actual content is... YMMV.

    I tend to work with pages full of text information and usually having all the 'copy' done up first before even thinking about how to present the content on a website. In that way, giant images, flash content and other nonsense just gets in the way.

    Sounds like your content might be different from that, so your needs are different.

    Though, do you have a link to the site in question? Without seeing what it is you are actually working on anything said in this thread so far is little more than wild guesses. EVERY case is different, and there are no easy answers as to what's appropriate and what's not.

  20. #20
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Well, it does always depend on the target audience and what the actual content is... YMMV.

    I tend to work with pages full of text information and usually having all the 'copy' done up first before even thinking about how to present the content on a website. In that way, giant images, flash content and other nonsense just gets in the way.

    Sounds like your content might be different from that, so your needs are different.

    Though, do you have a link to the site in question? Without seeing what it is you are actually working on anything said in this thread so far is little more than wild guesses. EVERY case is different, and there are no easy answers as to what's appropriate and what's not.
    It is a work in progress, but I was able to put it up earlier this morning. All the links are dead at this moment: kylepicone.com/CC_Website_BenV2_2.html

  21. #21
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by kp606 View Post
    Thank you for your candid thoughts. But I am a designer, not a developer nor coder by training. This is all incredibly foreign to me.
    So the first thing you need to learn in order to start working on adding web designer to your other designer skills is that on the web the design is done using a language called CSS (or cascading style sheets) which determine how the content defined in the HTML is supposed to look.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #22
    I Love Licorice silver trophybronze trophy Datura's Avatar
    Join Date
    Aug 2006
    Location
    Florida USA
    Posts
    5,775
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kp606 View Post
    It is a work in progress, but I was able to put it up earlier this morning. All the links are dead at this moment: kylepicone.com/CC_Website_BenV2_2.html
    Looking at the layout there is one thing that really bothers me. You have the white "sheet" lying there angled. When you now put your text into this sheet, the type(ing) will appear crooked, there will be more space on the left side towards the bottom than on the top, and vice versa for the right side.

    Being visually inclined must also mean to get things done in a logical fashion
    Ulrike
    TUTs: 1 2 3 4 5 6 7 8 9 10

  23. #23
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Datura View Post
    Looking at the layout there is one thing that really bothers me. You have the white "sheet" lying there angled. When you now put your text into this sheet, the type(ing) will appear crooked, there will be more space on the left side towards the bottom than on the top, and vice versa for the right side.
    That's also something I'd take an axe to for another reason - the complete lack of dynamic height. Fixed height images behind your content is most always a miserable failure at future-proofing. SOMEDAY somebody is going to want to add content taller than that image. If you are using dynamic fonts (pt/em/&#37 on the content - which it appears you are - and fill it to the gills with text, load it on a large font/120dpi system and enjoy the content text blowing right past the bottom of your image. VERY much one of those "draw a pretty picture" moments without thinking about the behavior of the content likely to go into it.

    Which is not to say the overall idea isn't without merit - It's very attractive - but I'd throw out the existing images to remaster a set to allow for dynamic height on the content area, images off graceful degradation, CSS off graceful degradation, no image maps, heading orders that make sense, etc, etc.

    I have time later tonight or tomorrow morning I'll toss together a rewrite to show what I mean by that - right now it's using 150k of images for what I personally doubt should take more than 50k - maybe 70k once things like rollover effects are added. (and I WOULD add rollover effects).

    Really it's maybe ten to fifteen minutes to put that together.

    -- edit -- also doesn't help that by totalling 1024 it's not even 1024 friendly. Remember, subtract 32px or more for scrollbar and browser chrome.

  24. #24
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    That's also something I'd take an axe to for another reason - the complete lack of dynamic height. Fixed height images behind your content is most always a miserable failure at future-proofing. SOMEDAY somebody is going to want to add content taller than that image. If you are using dynamic fonts (pt/em/%) on the content - which it appears you are - and fill it to the gills with text, load it on a large font/120dpi system and enjoy the content text blowing right past the bottom of your image. VERY much one of those "draw a pretty picture" moments without thinking about the behavior of the content likely to go into it.

    Which is not to say the overall idea isn't without merit - It's very attractive - but I'd throw out the existing images to remaster a set to allow for dynamic height on the content area, images off graceful degradation, CSS off graceful degradation, no image maps, heading orders that make sense, etc, etc.

    I have time later tonight or tomorrow morning I'll toss together a rewrite to show what I mean by that - right now it's using 150k of images for what I personally doubt should take more than 50k - maybe 70k once things like rollover effects are added. (and I WOULD add rollover effects).

    Really it's maybe ten to fifteen minutes to put that together.

    -- edit -- also doesn't help that by totalling 1024 it's not even 1024 friendly. Remember, subtract 32px or more for scrollbar and browser chrome.
    If you can, I'd be very appreciative. Thank you

    The assumption is that the pages will contain little information to begin with, but it is better to be safe than sorry.

  25. #25
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Here's how I'd approach that same basic layout idea:

    http://www.cutcodedown.com/for_other.../template.html

    As you can see I got rid of that white part of the page being slanted and the texture on the folder so it's now dynamic height. You can add content until blue in the face and it will auto expand to fit it. It also now has graceful degradation when you turn images off, some cute rollover effects, is 1024 friendly, and drops down to less than 50k for the entire template.

    As with all my examples the directory:
    http://www.cutcodedown.com/for_others/kp606

    ... is unlocked for easy access to the bits and pieces. Valid XHTML 1.0 Strict and would be valid CSS 2.1 if not for a couple browser specific properties (zoom, -moz). Tested working 100&#37; in IE 6, 7 & 8, Opera 10.52, Firefox 2 and 3.6, and the latest flavors each of Saffy and Chrome. It is also functional in IE 5.5, though the hover effects on the sidebar are slightly broken appearance-wise due to IE 5's lack of z-index. (It's still usable)

    To break it down for you, we'll start in the markup. Follow along with the source.

    *** HTML ***

    We start off with a STRICT doctype. Tranny is for supporting old/outdated/outmoded/half-assed coding techniques using tags and attributes we aren't even supposed to be using anymore, and there's little legitimate reason to not be writing to STRICT.

    You'll notice the link for the CSS includes MEDIA types. Given the wildly different capabilities of various devices it's a really good idea NOT to send any CSS to "all". I left the hooks for the other two common sheets I design in there, just commented out.

    div#pageWrapper - First div I most always have. If you are setting a fixed width, or designing 100% min-height, or a dozen other layout techniques having a DIV wrapping everything just makes life easier.

    H1 - The first heading on the page, even when a logo, I try to use a HEADING tag for (who'd have thunk it!?!) - this way our heading order from a structural standpoint (what HTML is FOR) always makes sense, since all other heading tags on the page are by definition supposed to be subsections of that h1 (and are supposed to always come after it). I tossed in some nested spans and a small tag as presentational hooks so we can style it images off to look a lot like how it looks images on. The break tags assist with this, and also make it look nice when CSS is disabled/not-present/not wanted.

    #mainMenu Just a simple flat list.

    hr - You'll see a few horizontal rules present. Those are for people viewing with CSS disabled to divide up the sections a bit more. We'll hide those in the CSS.

    div.contentTop is simply a empty sandbag for applying the top rounded corners and shadow.

    div.contentSides is for the sides of that folder image.

    ul#sideTabs - those sideways tabs on the left. I put them inside .contentSides since it's going to be simplest to have their images overlap the background on .contentSides.

    div #content - we'll use this to make our white background box.

    div.stickyPad - another image sandbag div. This time for that little piece of paper that says "college council". We use a separate div for this so we can float it later, allowing our content to wrap around it.

    h2 and p - just some placeholder content.

    div.contentBottom - the sandbag for the bottom rounded corners.

    div#footer - just the simple footer content.

    ... and that's really all there is to the markup. You'll notice my commenting style puts the comment BEFORE the closing element. Putting them inside the element avoids a couple IE rendering bugs that can occur when comments are placed in-between floats or in-between positioned content. The nastiest of those are the double-render and disappearing content bugs, but there are more subtle errors that can drive you nuts. You can also see I don't waste time saying "end content" - of course it's the end, that's what </div> means!

    *** CSS ***

    Follow along with:
    http://www.cutcodedown.com/for_others/kp606/screen.css

    First thing I put in every CSS file I write is a simple reset to make sure all browsers start out with the same margins, padding and borders on the elements I use the most. There are larger resets, but they are a bit saggy around the midsection for my tastes. There are smaller resets, but they often break things like form elements causing more harm than good. This is the nice safe middle-ground.

    hr - As mentioned, we hide the horizontal rules in the CSS.

    body - the text-align is to center #pageWrapper in IE5, which incorrectly centers DIV on text-align and ignores margin:auto; - I set the default font up as 85% since that's roughly 14px at 96dpi, 17px at 120dpi, 12px at 72dpi, or basically 10pt. WCAG says use %/em - who are we to argue. (when the W3C recommends something, it helps to pay attention). I ALWAYS declare the full condensed 'font' line with style and line-height when I change font size becuase you cannot trust the default line-height and the entire property is ignored in some browsers if you don't declare at least 'normal'.

    For more info on font sizes, check out this little page I threw together on the subject.
    http://battletech.hopto.org/html_tut.../template.html

    From there it's just the background color.

    #pageWrapper - I narrowed your width to the 1024 friendly 992px. I always allocate 32 px for scrollbar and browser chrome on my targets. Personally I'd consider opening it up to at least a semi-fluid layout, but I didn't want to get too complicated on you by introducing things like sliding doors or eight corners under one roof.

    The margin:0 auto is for standards compliant centering, I add the top/bottom padding here so we don't have to even think about margin collapse, and the text-align sets things back to 'normal' after our IE 5.x centering.

    h1 - the position:relative is to allow us to absolute position the nested nested span over our text for gilder-levin style image replacement. The overflow:hidden gives us float wrapping in standards browsers, and I toss the holly hack at it to get float wrapping in IE; AND to squash positioning bugs.

    Rather than declare widths on most of our internal areas I prefer to use margin or padding to push things in, that way I don't even have to think about the math to come up with the width. It also opens the door to making the layout semi-fluid or even fully fluid.

    The padding plus all of our line heights totals up to the same height you had in your image. Since it had a flat color background we can then use a much smaller image and make the content to the right of the school logo show as actual text. From there it's just fonts and colors. You'll notice all fonts in the h1 and menu are declared in px - this is because if "120dpi" or other non-default metric users have the fonts auto-enlarge it will break the image interaction. Thankfully the smallest we're going to be using is 16px, and it's very unlikely anyone is going to get upset over that being too small.

    h1 span - the outermost span is used to wrap the part of our text that gets floated to the left when CSS is present. The display:inline is a fix for IE incorrectly doubling margins on floats. Floats are inherently display:block and nothing you ever set for 'display' is supposed to be able to change that, but for some wierd reason in IE setting display:inline trips some wierd bit of code that fixes the margin bug.

    The width forces proper wrapping to match the image, the margin pushes the text we'll be showing over, and from there it's just font size and centering.

    h1 small - display:block forces it to obey the line-height declared in it and not the line-height of it's parent. Then we just set the text smaller.

    h1 span span - this is were we place this image:
    http://www.cutcodedown.com/for_other...ges/h1Logo.png

    ... over the text. By using a much smaller image the bandwidth savings are enormous. Absolute position it, set the width, set the height, assign the background. Pretty simple, and overwrites the text in our span. Images off (or things that don't see images like search engines) the user sees the pretty styled text, images on they see the image.

    #mainMenu - strip the bullets, I set the fixed height rather than mess with float wrapping, in this case it has the same effect. Again the margin to push it in instead of declaring a width. By using text-align and display:inline / inline-block on the lists contents we can center the menu text and just pad them apart evenly. The font-size declaration makes all browsers treat white-space between inlines pretty much the same way, and finally the background-color for images off and the image.

    #mainMenu li - whenever possible I just set these to inline and then try to pretend they don't exist. If you were to add dropdown menus, you would then be forced to do something more with them.

    #mainMenu a - display:inline-block and it's mozilla workarounds let us declare top/bottom padding on the anchors. That padding plus the line-height gives us our 36px height, while still allowing us to play with the positioning a bit. Strip the underlines, set the font size, set some color. Easy-peasy.

    #mainMenu a:psuedo - the hover and active states we just change the color, change the background-color for images off users, and then I made a extra bit of image on the left side of mainMenu.png as a images hover state.

    .contentTop,
    .contentBottom
    - these share most of the same values, so I set them together. Float clearing is just a good idea, the IE font-size fix shouldn't be neccessary given they are 32px tall, but better safe than sorry with Win7 letting users go to 192dpi, and they both share the same image for the background. "0 0" for background-position shows the upper left 32px tall area of our image:

    http://www.cutcodedown.com/for_other...entBorders.png

    .contentBottom - sliding the background-position up 32px reveals the bottom left 32px of our 64px tall image.

    .contentSides - the position:relative helps with any depth sorting issues, the overflow and width declarations being present just to provide float wrapping. Finally we apply that same background image, but we slide it left 992px to reveal teh right half which we tile on the Y axis. All three corner images in a dynamic height area stuffed into one small file.

    #sideTabs - This just gets floated left so our content box can ride up next to it. Adding the display:inline fix stops an extra 2px oddity in IE6, but apart from that the wrapping UL is nothing fancy.

    #sideTabs li - again, I just set these to inline and pretend they don't exist. Makes IE7 behave.

    * html #sideTabs li - IE6 needs 'zoomfix' - using zoom:1 to fix something that normal haslayout triggers does not, but this seems to break IE7 - so I had to stuff it behind the classic "* html" hack to target IE6/earlier only.

    #sideTabs a - setting them to display:block puts them one atop the other, the z-index is there because, well, I'm going to overlap them with a negative margin. If you look at our image:
    http://www.cutcodedown.com/for_other...s/sideTabs.png

    You can see it's designed to overlap for the hover states - that way we don't need any of that alpha transparency nonsense. To do that we'll have to do some z-index chicanery.

    The overflow:hidden will chop off anything bigger than our wrapping anchor... We'll use that in a second. From there it's just color and stripping the underscore.

    #sideTabs a:psuedos - the hover and active states we use z-index to make sure they layer over their siblings, and I use font-weight:bold for our images off users.

    #sideTabs a span - just a bit of top padding separate from our height declaration for images off users, and a line-break that's not present when CSS is disabled.

    #sideTabs .buttonClass a - each of the buttons is slightly different from the others in terms of height and overlap. .forStudents a just gets a images off background-color, .forClubs a gets a negative top margin and a different color, .forOthers a being our most complex with a different negative top margin, a different height, and different colors.

    #sideTabs b - our gilder-levin image replacements. Absolute position it over the parent anchor. Remember that overflow I set up for width? Here's where it comes into play as we set it twice as wide - the width of our image, and the 200px of our tallest elements. This means we don't have to specifiy the exact size twice.

    #sideTabs .buttonClass b - each of them gets a different background position, sliding the image up to reveal each button's 'section'.

    [b]#sideTabs a:psuedos b - when you hover all we have to do is slide the entire nested bold tag 64px to the left. This reveals the right half of our image with the excess again cut off by our overflow state. Doing it this way means we don't have to restate the background-positions over again for each and every hover state. (which would be another ten to fifteen lines of CSS)

    #content - the content is pretty simple. I set a min-height of 480px so that it will expand to at least the height of the side tabs. The margin is again to push it in from our side elements, and of course some padding to make it pretty. I added a border on the bottom and right edges just to make it a bit more 'defined'.

    * html #content - IE has no min-height, but will incorrectly treat height as such.

    .stickyPad - Position:relative makes certain this element depth sorts over everything, fixing a bug in IE6/earlier. I float it right so that the content will wrap around this image... Which if you take a look at you'll see I used 'close enough anti-aliasing' so that should something get wrapped to close/underneath it things won't screw up. It also reduced the filesize 10%, so worth it.
    http://www.cutcodedown.com/for_other.../stickyPad.png

    The negative right margin slides it out of our #content area and over the .contentSides as desired, which is why we need the display:inline to prevent IE margin doubling.

    #content h2,
    #content p
    - just some placeholder formatting for the content.

    #footer - margin to push it in the same as the rest of the page (yers looked funny being the full wrapper width), then just padding, color and alignment.

    Pretty simple, hope this helps or that you came away with something useful from it. The bandwidth savings and ease of updating the content it brings is usually worth the effort - particularly when it opens the door to all users and not just the perfect match of user agent. It does sacrifice a number of design elements as impractical, simple fact is if you care about doing a website right, a lot of stuff you can do in photoshop is just a really BAD idea when it comes time to build a website.

    ... if nothing else, the removal of over 110k of images is proof enough of that. Oh and if you are curious, yes, I redrew most of your images from scratch.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •