SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 28
  1. #1
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    IE6 Is killing me slowly!

    Hi guys,

    Can anyone help me? I've got a few issues with a site I'm doing in IE6, I've spent over 6 hours getting to the point it is now.

    The site can be viewed here

    If you view it on firefox, safari or chrome its o.k..

    Main issues in IE6

    • Search input text "search here" in the header top right is not vertically aligned. (it is tight to the top of the input box)
    • Submit button has a background image in the other browsers.. does not seem to work in IE6
    • the blue line div directly underneath the top navigation is alot thicker than it should be. the line is a div with a class of blue line. it has a bg color and has a height of 6px; it's more like 12 or 18 px's in IE6
    • on content pages layout is messed up.. left column is not tight to edge and has pushed everything across forcing the right column down.


    Any help on these would be great

  2. #2
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    the blue line div directly underneath the top navigation is alot thicker than it should be. the line is a div with a class of blue line. it has a bg color and has a height of 6px; it's more like 12 or 18 px's in IE6
    IE6 treats height as a minimum and when you specify a height that is less than the cuurent font-size/line-height then IE expands the height to accommodate the current line-height. You can either set font-size to zero for that element or add overflow:hidden to it. Either will work.

  3. #3
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    The search input can be centred by setting the line-height to match the height. The right part of the button needs to have a transparent background-color also.

    Code:
    #main-menu ul li.search #ajaxSearch_form .cleardefault {
        line-height:49px;
    }
    #ajaxSearch_submit {
        background-color:transparent;
    }
    You will also need to remove the pngfix from that element as it doesn't handle background-position. Look at using twinhelix if you want to support repeat and position on png images in ie6.

  4. #4
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    The right column has dropped for 2 reasons.

    There's the double margin float bug on the right column and then on the left column you haven't got rid of the default margin on the ul.

    Here are the fixes.

    Code:
    #left-col ul {
        list-style: none;
        width: 220px;
        float:left;
        padding-left: 0;
        padding-top:0;
        margin:0;
    }
    #right-bar {display:inline;}/*fixes double margin bug on floats*/

  5. #5
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Paul, that all works great!

    thanks for your help

  6. #6
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    I've just checked the top navigation again in IE6 and the hover state of the buttons are showing and top nav is broken.


    I've also found that when I go to a different page (content page) if you start to scroll down the site freezes and then crashes..

    Can anyone replicate this and see if it happens their side?

    Any help would be great

    Thanks

  7. #7
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    I'm not seeing the hover states showing until you hover in Ie6. What problems do you see?

    There are transparent png issues on that page in IE6 of course.

  8. #8
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I found that the png fix I was using was causing the odd behavior in the nav.. Once I removed that from the page it loaded as expected..

    I'm going to use the helix png fix you mentioned above..


    Thanks for the help..


  9. #9
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've just noticed that the text in the footer is slightly cut off in IE6... do I have to give the footer a specified height?

    The blue line that appears below the navigation is also missing since I gave it a line-height as mentioned above?

  10. #10
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    Remove the .blueline styles from the IE css as they are not needed.

    Just use this one in the main stylesheet.
    Code:
    .blueline {
        height: 6px;
        background-color:#0066CC;
        width:100%;
        overflow:hidden;
     clear:both;
    }

    You've set the font-size to 10px in the footer and then you set the line-height to 10px also. That wont allow room for ascenders and descenders to show and they will be cut off in IE. You need a line-height of about 1.2 minimum.

    Also remove the height from the footer and let the content dictate the height.

  11. #11
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    I'm seeing broken layouts in EVERY browser here -- from dynamic fonts blowing out of the fixed containers, to float drops on columns, to overlapping columns, to mis-placed elements... and I'm assuming the menu is broken in every browser missing the rounded edge on one side?

    I think your methodology is biting you in the backside when it comes to cross browser support... Did you test as you went applying style to each section, or did you design the whole thing for one browser and then go back later to see where it's broken? The latter approach is most always the route to failure unless you REALLY know what is going to cause problems in IE ahead of time.

    The markup isn't too bad -- only validation error being you repeated the same onfocus property twice (hence why I dislike shoving everything onto one long line -- that's how accidents like that happen)... Though there are a few things I'd clean up before even addressing the CSS -- like the title attributes that are redundant to the content of the anchors (there's no reason to EVER do that to an anchor!) all that scripting for nothing (if you need the fat bloated pile of crap known as jquery just to rotate some images, don't rotate images IMHO), two stylesheet embeds with no media types and one with (eh?!?), paragraph tags with classes on them doing HEADING's job, h1 on an element that is NOT the parent header for every heading on the page, and the typical horde of classes and ID's that shouldn't even be necessary... I'd probably pitch out about a third of your markup before even addressing the layout... but at 8k that's not a huge "OMG what did you DO!?!" like I'm used to seeing 'round these parts.

    On the CSS side, I can't make heads nor tails of that mess. (no offense) -- PX metric fonts on paragraphs (a huge no-no), font-size declared without re-declaring line-height, uncondensed font properties, no fallback family on font-family, redundant declarations like display:block on block-level elements, floats on elements that there's no reason to float, redundant image declarations and values like "scroll" that make no sense on the element, targeting each LI when there's zero reason to, etc, etc...

    I mean, just for your main menu you've got a div around it for nothing and 4 or 5k of CSS doing about 1.5k's job.

    ... and I'm not certain what "ajaxSearch" is, but it SOUNDS like a really REALLY REALLY bad idea. As in "let's load a 100k library of scripting just to avoid one page load and 4k of markup" in the name of saving bandwidth -- right.

    So first, I'd clean up the markup as one of the big rules of styling is that CSS is only as good as the markup it's applied to... which would probably go something like this (+/-5&#37

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html
    	xmlns="http://www.w3.org/1999/xhtml"
    	lang="en"
    	xml:lang="en"
    ><head>
    
    <meta
    	http-equiv="Content-Type"
    	content="text/html; charset=utf-8"
    />
    
    <meta
    	http-equiv="Content-Language"
    	content="en"
    />
    
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    />
    
    <title>
    	NHS Lincolnshire | Home
    </title>
    				
    </head><body>
    
    <div id="header">
    
    	<div class="widthWrapper">
    	
    		<h1>
    			Lincolnshire Partnership<br />
    			<small>NHS Foundation Trust</small>
    			<span></span>
    		</h1>
    		
    		<p>
    			Promoting recovery and <em class="standout1">quality of life</em>
    			through <em class="standout2">effective, innovative</em>
    			and caring mental health, <em class="standout3">social care</em>
    			and <em class="standout4">specialist community services</em>
    		</p>
    		
    		<ul>
    			<li class="singleLine"><a class="current" href="home">Home<span></span></a></li>
    			<li><a href="help-and-support">Help &amp;<br />support<span></span></a></li>
    			<li><a href="services-and-locations">Services &amp;<br />locations<span></span></a></li>
    			<li><a href="get-involved">Get<br />involved<span></span></a></li>
    			<li><a href="work-for-us">Work<br />for us<span></span></a></li>
    			<li><a href="news-and-events">News &amp;<br />events<span></span></a></li>
    			<li><a href="about-the-trust">About<br />the trust<span></span></a></li>
    			<li><a href="health-professionals">Health<br />Professionals<span></span></a></li>
    			<li class="endCap"></li>
    		</ul>
    		
    		<form action="search" method="post">
    			<fieldset>
    				<input type="hidden" name="advsearch" value="oneword" />
    				<label for="searchField">
    					<input
    						type="text"
    						name="search"
    						id="searchField"
    						onfocus="this.value=(this.value!='Search here...' ? this.value : '');"
    						onblur="this.value=!this.value ? 'Search here...' : this.value;"
    						value="Search here..."
    					/>
    				</label>
    				<input 
    					type="image"
    					src="images/searchArrow.png"
    					alt="Search"
    					class="searchArrow"
    				/>
    			</fieldset>
    		</form>
    		
    	<!-- .widthWrapper --></div>
    	
    <!-- #header --></div>
    
    <hr />
    
    <div class="widthWrapper">
    
    	<div id="showcase">
    		<div class="content">
    			<h2>Mental illness can affect anyone at any time...</h2>
    			<p>
    				Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet
    			</p>
    			<a href="/help-and-support" class="needHelp"><span>NEED HELP?</span></a>
    		</div>
    		<div id="rotator">
    			<img src="images/slider1.jpg" alt="" />
    			<img src="images/Picture1.jpg" alt="" />
    			<img src="images/slider1.jpg" alt="" />
    		</div>
    	<!-- #showcase --></div>
    	
    	<hr />
    
    	<div id="firstColumn">
    	
    		<div class="articleBrief">
    	 		<img src="images/logo.png" alt="" />
    	 		<h2>
    	 			<a href="news-and-events/news/news-article-2">
    	 				News Article 2
    	 			</a>
    	 		</h2>
    	 		<p>
    	 			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut tincidunt dui vel mi viverra aliquet. Vestibulum ut eros tellus. Proin in porttitor metus.
    	 		</p>
    	 	<!-- .articleBrief --></div>
    	 	
    	 	<div class="articleBrief">
    			<img src="images/logo.png" alt=""/>
    			<h2>
    				<a href="news-and-events/news/38">
    					Duplicate of News Article 1
    				</a>
    			</h2>
    	 		<p>
    	 			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut tincidunt dui vel mi viverra aliquet. Vestibulum ut eros tellus. Proin in porttitor metus.
    	 		</p>
    	 	<!-- .articleBrief --></div>
    	 		
    		<a href="/index.php?id=14" class="allStories">All news stories</a>
    		
    	<!-- #firstColumn --></div>
    	
    	<hr />
    
    	<div id="secondColumn">
    	
    		<div id="tagCloud">
    			<h2>I want help with</h2>
    			<ul>
    				<li><a href="/help-and-support/conditions-treatments" class="small">Dementia</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="medium">Anxiety</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="large">Depression</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="small grey">Schizophrenia</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="large">Eating disorders</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="medium">Learning difficulties</a></li>
    				<li><a href="/help-and-support/conditions-treatments" class="small grey">Personality Disorders</a></li>
    			</ul>
    		</div>
    						
    		<div class="picBox">
    			<h2>We're supporting</h2>
    			<img src="images/smallbox.png" alt="We're supporting" />
    			<a href="#">More about time to change</a>
    		</div>
    						
    		<div class="picBox secondPicBox">
    			<h2>Become a member</h2>
    			<img src="images/smallbox.png" alt="Become a member"/>
    			<a href="#">More about time to change</a>
    		</div>
    					
    	<!-- #secondSideBar --></div>
    				
    	<hr />
    
    	<div id="footer">
    		<ul>
    			<li class="first"><a href="/5/contact-us">Contact us</a></li>
    			<li><a href="/5/7">Freedom of information</a></li>
    			<li><a href="/5/8">Accessibility</a></li>
    			<li><a href="/5/privacy_terms_conditions">Privacy &amp; terms of use</a></li>
    		</ul>
    		<a href="http://www.precedent.co.uk" title="visit the designers precednt">Design by Precedent</a>
    	<!-- #footer --></div>
    
    <!-- .widthWrapper --></div>
    		
    </body></html>
    Mind you for now that's setting aside the scripted image rotator. Gets rid of all the "absolute URL's for nothing", that "blueline" div which should probably just be done as border-bottom on a element instead, axed the classes on paragraphs for nothing and turned the paragraphs that should be headings into.., headings, I swapped the source order around to make more sense when CSS is off, though that may mean resorting to absolute positioning the menu and search (boo - but increasingly I'm coming to the conclusion it makes no sense to have anything for content end up between <body> and <h1>)... basically chops it down to two-thirds the size.

    Gimme like 20 minutes and I'll belt out the CSS and remaster the images to work with that HTML 'my way'. I'll document it so you can follow along in the code and hopefully learn from my example.

    When it comes to supporting IE it's only as hard as you make it. Generally for a simple fixed width layout (boo) like yours the only things you should really need is a couple haslayout triggers, and following a few simple rules like "never declare width the same time as padding and border" there's no reason you can't have perfect support all the way back to IE 5.5, and maybe have it not even be broken in 5.01 (though I make no guarantees on that).

    I'll post back in a bit when I've got the CSS to make my above example HTML work.

  12. #12
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, took a little longer than I thought as I got carried away screwing around with the images.

    Here's what I came up with:
    http://www.cutcodedown.com/for_other.../template.html

    Mind you, I took a wild guess on the menu since the 'broken' sides just didn't look right. Likewise there are a few liberties with the layout/appearance, but I tried to stay true to the original as much as possible. As with all my examples the directory:

    http://www.cutcodedown.com/for_others/owz2004/

    is wide open for you to grab the bits and pieces -- you'll notice I redid most all of the images, dropping it from 690k in 17 images to 131k in 11 images.

    Valid XHTML 1.0 Strict, would be valid CSS 2.1 if I hadn't had to resort to a couple -moz properties to still support FF 2.x and it's kin (a lot of *nix heads still won't upgrade to 3 -- if you're gonna support IE6, take the time to support FF2).

    Tested working just fine in IE 5.01, 5.5, 6, 7, 8 and 9 Beta, FF 2 and 3.53, Opera 10.62 and the latest flavors each of Safari and Chrome.

    I'll start writing up a breakdown of the HTML first, and then I'll cover the CSS.

  13. #13
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    39,775
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    Great work Jason - I don't know where you find the time

  14. #14
    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 Paul O'B View Post
    Great work Jason - I don't know where you find the time
    I'm retired, remember? I'd rather spend my free time living on the gov't take helping people than sit around all day with my thumb up my backside

    Besides, it took me less time to code and redo the images (30-35 minutes) than it is to write up the explanations of WHY I made the choices I did. Speaking of which:

    --------------------------------

    Ok, made a .txt file copy of the markup to read along with for those too lazy to hit view>source

    http://www.cutcodedown.com/for_other...plate.html.txt

    So let's being. First up you'll notice my formatting. I use a LOT of carriage returns because I still like to obey the old '78 character' programming rule. If a line of code can be broken up and indented cleanly, and it would break 78 characters, DO IT. Just makes it easier to deal with.

    It also helps when dealing with attributes since you get a nice neat column of what attributes are declared instead of the disastrous 'monster lines' many developers sleaze along with.

    Also pay attention to the commenting method. AVOID putting comments in-between sibling elements... and avoid #DDD comments. See

    </div><!-- end of content -->

    Having it after the </div> is prone to tripping rendering errors in IE, and in very VERY rare cases even Firefux will screw the pooch. Both error instances are extremely uncommon, but when they do show up you'll be pulling your hair out screaming "WHAT'S GOING ON?!?" (like I did six years ago when I found that particular little nasty out). Dissapearing content, forced linefeed, forced block level break, double render bug -- it's a nasty list.

    Also, a </div> is the end of something?!? No, REALLY?!? Who'd have thunk it?!?

    That's why I do
    <!-- #content --></div>

    Which tells me what's being closed (an element with the ID of Content) and by putting it before the close, it can never be wedged between two sibling elements.

    Moving on, pretty much it's all the same declarations until you get to the LINK. I would never target 'all' on a page as I rarely have anything for screen I'd want for print -- notice I also target TV and projection. There are still a decent number of web TV users out there and kiosks -- and since Opera reports itself as 'projection' in Kiosk mode (still being the most popular choice to run as a kiosk) it helps to throw that one on there too. You'll notice I named it "screen.css" -- same as the media type. There's usually little legitimate excuse to have more than one CSS file on a site apart from paranoid delusions of targeting specific pages in a manner that wastes times thanks to handshakes. Likewise take note of the complete LACK of any of that IE conditional nonsense. When I call it unnecessary bull, I mean it's unnecessary bull.

    Also note how I remove the whitespace between <html><head>, </head><body> and </body></html> -- No code should EVER go in-between those elements, so I strip the white space as a reminder and to save a couple bytes (the latter being more a lucky side effect than the reason I do so!)

    Ok, on to the actual fancy ****.

    div#header - I used an extra DIV wrapper here so I can apply a bit of padding and that blue line that stretches full screen width. This will grow in height meaning we don't have to think about it much.

    div.widthWrapper -- this is used twice, once before the full-screen width divider and once after. This way we can share all the same CSS properties.

    h1 - I generally make the site title the H1 since I use it like the heading on a newspaper or book. It might appear smaller on subpages but it's ALWAYS there on every page (or in some cases every other 'page' at the start of each 'fold pair'). This makes sense since every other heading tag you use on the page is supposed to be a subsection of the h1. Making "Mental illness can affect" the h1 makes no sense, since "news article 2" or "we're supporting" aren't subsections of that section.

    You can see I divided that up with a BR to force a newline and a small tag. I will use that in the CSS to apply the same styling as your image. The empty SPAN is going to be the image replacement which I toss atop the text hiding it. This way people browsing with images disabled will still have something useful to look at. (much less search engines)

    Since H1 is supposed to be unique and only used once per page, there's no reason to put a class or ID on it -- EVER. We don't even need a parent element to target it by.

    #header p - I used EM to mark up the colored text inside it, thought he words highlighted don't make a whole lot of sense, at least compared to the words not highlighted. Left that alone for now. I personally would NEVER say a color in my markup as at that point you might as well be using a FONT tag, so I just called them 'standouts'. Ideally I'd lose the classes, mark up the words you want to rank for and make them all the same color instead of the acid trip, but that's me. Since it's the only P in #header there's no reason to be wasting a class or ID on it.

    #header ul - the main menu. Since it's the only ul in #header there's no reason to be wasting a class or ID on it.

    #header .singleLine - used to indicate this button only has one line of text.

    #header .current - indicates the current page. I would NEVER use the class "selected" for this because that's also the name of a pseudostate -- when it comes to making classes or ID's, I treat all existing namespace values (tags, attributes, psuedo's) like they were reserved words in a real programming language so as to avoid confusion -- since it would be really easy to mistake :selected for .selected

    #header .endcap - instead of putting the search in there, I'm just going to put this in to draw the little curved left edge.

    #header ul a span - will be used to draw the right side of the dynamic width rounded buttons. Yes, I switched to making those dynamic instead of having your fixed image with offsets. Means a lot less CSS since we'll not have to target each and every button with a class.

    #header form - the search form. Since this is the only form in #header, there is [i]a broken record in here...[/b]

    Inside the form you can see I got rid of the label on the submit (if you aren't going to have text, don't use a label) and added the FOR field for accessibility, with the ID for it to point at on the input[text]. Also cleaned up the scripting a bit. The submit is now a input[image] which just works better in my experience than trying to pull any sort of trickery.

    After that we close .widthwrapper and #header.

    hr -- I use horizontal rules to break up the content for people browsing with CSS disabled. For screen.css I usually hide them.

    Hey look, it's our old buddy .widthWrapper again!

    #showcase - much like you had, just with a bit less around it. Pretty much this will just be float wrapping and maybe some padding.

    #showcase .content - The content div is the floated one... We'll put the background on this, other than that it's pretty simple stuff.

    #showcase h2 - since we used our H1, this is a h2 in the grand structure of our document. Really none of your headings are subsections of others so from here on they're all sibling h2.

    #showcase p -- since it's the only P in #showcase there's no reason to put a class or ID on it...

    #showcase a.needHelp - this really isn't a paragraph, we really don't need a block level container around it... so we'll just use the anchor. Hell, since it's using a fixed width background on the final version we could probably even get rid of the span inside it!

    #rotator - a good image rotation script this should be the ONLY hook you need to make it work. If I have time tomorrow I'll toss together a better .js for you that doesn't rely on some bloated crap 100k library to STILL come up with 2k of compressed/stripped script.

    #rotator img - just dump them in there, and remember when you deploy to get some ALT text on those suckers!

    #firstColumn - well, that kinda describes itself well, doesn't it? Much like saying a color, I try to avoid saying 'left' or 'right' -- since good markup should let you arrange the columns in any order and if down the road you flip them, it wouldn't make a lot of sense. Don't tie yourself down on where things are located like that.

    .articleBrief - You had a list for these... really I tend to think of LI in the sense of how they worked on the old MENU tag, where block level elements inside them were invalid. If you are going to have multiple P or multiple LI, it's too big to be a simple 'list item' IMHO from a semantics point of view. You put a heading tag on it, you are already SAYING it's a subsection, so that should be good enough! Once HTML 5 becomes real world deployable sometime around 2018-2020, these would be an ARTICLE tag, but for now a div with a class is good enough.

    .articleBrief img - since these are the only image in .articlebrief...

    .articleBrief h2 -- you had paragaphs acting as headers. Obvious headings are obvious, so we get H2 in there. Since these are the only h2 inside .articlebrief...

    .articleBrief p -- do I have to say it?

    .allstories This is not inside any element I'm comfortable targeting to apply that styling, so that actually gets a class. There's no reason to waste a block level container around it like P or DIV.

    #secondColumn - gee, wonder what this could be?

    #tagCloud - again, simple.

    #tagCloud h2 - Another element you had as a paragraph with class="title" on it that is OBVIOUSLY a heading. Naturally since we've got a perfectly good ID on the div wrapping it, it doesn't need.. well, you know.

    #tagCloud ul - No real differences from yours here, except I deleted the 'blue' class assuming blue is the default state, that way you only have to say 'grey'.

    .picBox - you'll notice I put .picbox on both of them. So much is shared it seemed the simpler way to handle it.

    .picBox h2 - see "#tagCloud h2"

    .picBox img - see ".articleBrief img"

    .picBox a - again, do I have to say it?

    #footer - pretty obvious.

    #footer ul - you'll notice I removed the .last class as unnecessary. If you put the border on the left, you can remove the border and the left padding on just the first one. No need to even target the second one.

    #footer a CDATA='Design by Precedent' - again there's no need to waste any sort of block level container around it. Semantically there's not enough text to even qualify as a paragraph IMHO, we've got a perfectly good block level container in #footer, so no need.

    The End... Next up I'll write up a summary of the CSS, which will be a much more involved process.

  15. #15
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    ... and we're moving.

    On to the CSS, follow along with the bouncing ball.
    http://www.cutcodedown.com/for_other...004/screen.css

    First thing I do in EVERY CSS file is use a reset. Now, resets are a subject that have been beaten to death in pretty much every thread where someone uses on. I'm gonna say this quick:

    You have to Goldilocks it. There are smaller resets like the "universal reset" of "* {margin:0; padding:0;}", but that shtups form elements so stay away from it. There are larger ones like Meyer's "reset reloaded" -- but when you have 2k of CSS before you even start writing your own? Not a good thing. Frankly his is big enough to qualify as a framework since it targets elements I rarely use, or set five or six different values for across the page.

    The one I advocate is IMHO "just right". It resets just the things I need set the same across all browsers, and nothing more.

    Code:
    /* null margins and padding to give good cross-browser baseline */
    html,body,address,blockquote,div,
    form,fieldset,caption,
    h1,h2,h3,h4,h5,h6,
    hr,ul,li,ol,ul,
    table,tr,td,th,p,img {
    	margin:0;
    	padding:0;
    }
    
    img,fieldset {
    	border:none;
    }
    It's not even a quarter of a K.

    As to the people who say resets are unneccessary or wasteful, my pages work all the way back to IE 5.x with little if any extra coding. How are those broken in everything except Firefox at small fonts/96 dpi pages coming along?

    hr - as mentioned in the HTML breakdown, I use HR for CSS off users, so for 'screen' we can strip these right out. If we want them inside an area we can always set them back to display:block;

    body - first is a text align so our wrappers center in legacy IE. It's one line, big deal, safe to send to all browsers. Like most of what you are going to see in the CSS for legacy IE support altogether it's going to be less code than a conditional comment would be in the markup... Gee, send it once and have it cached in the CSS, or send it every single time the user loads a sub-page... Gee, lemme think.

    Next is my default font settings. 85% of the default 16px for 96dpi systems gives you a nice 14px, while for large font/120dpi users like myself it delivers 17px - both look pretty good. You can see I use a pretty tall default line-height, I find the default can be a bit hard to follow when long lines wrap -- much like double spacing helps on a 8.5x11 sheet, increasing the line-height can help on screen as well.

    Finally the background color, no need to explain that.

    .widthWrapper - the positon:relative is to help with positioning the menu, since we want it to render over the h1 for screen, but not in the normal document order. The text-align returns us to 'normal' after the IE 5.x centering, and finally width and auto margins.

    #header - padding is pretty obvious, as is the margin and border. Using border on this div beats the tar out of wasting an entire extra DIV on making that blue line. Because #header is around the first .widthWrapper it will render full screen width.

    #header .widthWrapper - and because it's wrapped by #header on the first one, we can target the first one. This padding pushes the h1 and paragraph down to make room for the menu and search when we position them.

    h1 - relative positioning is for the image replacement span, the float is fairly obvious as is the width. You'll notice I do NOT specify a height because I want to use top and bottom padding. Mixing height/width with padding or border in the same direction is a recipe for failure not just on the broken box model, but ocassionally if other rendering oddities crop up in browsers like Opera (see the redraw on scroll bug)... So just don't do it. I'll cover the solution in a moment.

    h1 small - smaller text, color, display:block makes it use the 16px line-height declared on it instead of the 18px of the parent h1. That's a cute little quirk in most browsers, a BR will make a newline that's got the current line-height, so if you make a shorter line-height on a display:inline element after it, you'll still get the old line-height. Display:block removes that defined line, but thankfully doesn't insert an extra line-break.

    So how do I get the 48px desired height? Simple, 7px top/bottom padding = 14 px. 14px + 18px line-heihgt + 16px 'small' line-height == 48.

    h1 span - This is called gilder-levin image replacement, or at least it's a take on it. 'real' gilder-levin puts the span first and skips saying 'top' and 'left', but I've had that break in recent builds of both firefox and Opera, and putting the span last in the markup opens the door to other techniques.

    It's pretty simple, make a span, make it big, absolute position it over the text, and load the image as the background hiding that text.

    #header p - I set the width in EM because I wanted to leave this text to dynamically size. Since there's MORE than enough room for it to grow to over 500px wide, this gives us consistent wrapping behavior without having to specify BR in the markup.

    For SOME wierd reason IE 6 is ignoring the text-align:left on .widthWrapper for the paragraphs, so I had to restate the text-align.

    From there just set the font a little bigger and set the color. You'll notice I declare the full condensed font property EVERY time. The reason I do this is omitting values on the condensed version tends to break in older versions of Gecko and Opera, and by the time you type out font-size and line-height (which you should ALWAYS do both) it's almost the same number of characters, so screw it -- say the whole thing so you can be 100% certain what's being set.

    #header em - since we're coloring the EM, we strip the italic off it. We're just implying the emphasis differently. (emphasized does NOT mean italic!). The word-wrap prevents the EM from being broken up in the middle which helps make it attractive, and I set the black color for if you add something without a color class so it will still at least stand out.

    #header .standoutn I've got four of these, it's just you colors.

    #header ul - our main menu. We absolute position it over the heading and paragraph, give it that bottom border and strip bullets.

    More complex is the overflow state and height, I use this to make the hover states. Rather than restating the background-position over and over and over, why not just relative position the buttons on hover sliding them 'up' while increasing the top padding? This will 'reveal' the lower parts of the image!

    Oh, and the background-image is for the outer-bar that the search will be positioned into.

    #header li - float 'em, pad'em. done.

    #header li.endCap - this one gets a fixed width and that rounded corner for the search area.

    #header li a - the real gruntwork goes on in the anchors. Relative position them so we can slide them around, float 'em into place, and much like I did with the h1 I use padding top and bottom with the line-height to create my total desired size.

    You'll notice I'm using PX fonts. Yes, I rage against PX fonts on CONTENT, but menus are often stuffed into crammed spaces and would break horribly if allowed to resize as %/em would, so px is the order of the day. When using PX 14 is about as low as I would EVER consider going. 12px for lf/120dpi users is just going to send them diving for the zoom, in which case you can bet they'll not visit again. (and I put more emphasis on repeat visits than I do first-time!)

    You'll notice the right padding is 2px less -- that's for the span which makes our right edge rounded corner... get to that in a moment.

    #header .singleLine a - because there's only one line we need more padding (16px total) to make it look centered top to bottom.

    #header li a span - absolute positioned inside our anchor to draw the right half of our button. This way it's dynamic-width on all of them so you don't have to customize the image just to change the menu!

    You can see it's declared REALLY tall, this is cut off by the overflow:hidden on the UL, but will reveal itself when we move the element on hover... speaking of hover:

    #header li a:psuedostates - You'll notice I trap :active, :focus and :hover. This is so keyboard navigators across all the different browsers aren't left out in the cold. In theory you might want to consider adding outline:0; here, but I leave it in. All we do to hover is slide the entire anchor up until the desired vertical slice is revealed, and pad the top to push the text back down where we want it. I also set a background-color for users with images disabled but CSS on.

    #header .singleLine a:psuedostates - the single line version just needs a taller top padding.

    #header li a.current - in every browser except IE6 we could just declare these, but 6 can be a real dipshit about specificity overrides when it comes to psuedostates, so we have to slap !important on a few of these for them to take. Much like the hover state all we do is slide it up with a negative value on 'top' and pad the top to push the text back down into place. From there it's just color. In testing IE obeys the color for some reason so it doesn't need the !important like the others. (wierd)

    #header .singleLine a.current - as before the singleLine versions need 8px more top padding.

    ... and that's the menu. The 'overflow' cutoff with sliding around a really huge anchor is a VERY handy technique for not having to say background-position over and over and over and over and over.

    #header form - the search form is also absolute positioned, in this case over the menu UL which already drew our background for it. As such we can just put the smaller 'inner' image for the INPUT there. By putting it as a background on the wrapper we can avoid all sorts of pain in the ass nonsense trying to put it on the input creates.

    #header .searchArrow - since the submit is a nice simple image, just absolute position it.

    #searchField - With the form input[text] since we had to have a ID on it for the LABEL[for], I use it instead of trying to target it off the wrapper. I avoid changing the height, padding or border-width if at all possible since cross-browser changing those values is WILDLY unpredictable. We're talking a real nightmare. As such I just make the border the same color as the background to hide it, set a width (which will vary cross browser but not enough to matter!) and use margin to just nudge it into place. It actually renders one px lower in gecko based browsers than it does in ANY other browser due to the nyetscape heritage of being a total dink and ignoring vertical-align - I don't consider 1px off to be worth diving for the hacks to correct. Oh yeah, gecko was a clean break from the Nutscrape 4 codebase, sure it was

    #showcase - I set up float wrapping behavior just in case you use a image that's smaller than the floated content box. Whenever I use overflow:hidden and a haslayout trigger, I like to put comments on them since not everyone will realize that's why they are being called.

    #showcase .content - I might use the .content class elsewhere since other things might have content. Most people will end up doing something silly like ".showcaseContent" or some such - I just target off the parent.

    Float it, width it, height it.

    #showcase h2 - as you change the content here away from the lorem-ipsum text, you'll probably want to adjust the top padding to keep it centered. There are other methods of handling that, but they are unpredictable at best and I like to keep it simple.

    Again we use PX metric fonts, again I HATE doing that, but this entire element is fixed height, so we're not left with a lot of choices. Just be warned that in most places if someone is still using the old outdated text-resize in gecko browsers where it resizes content like nyetscape 4's sweetly retarded cousin, the layout is going to have issues... Not a lot that can be done, sacrifices have to be made somewhere and it's why since 3.5 dropped that's no longer the default behavior for zooming. (though many people still set it back and then wonder why sites are broken -- duh, this isn't 1997)

    Woah, we're halfway there. Wooooaah, living on my hair...

    #showcase p - fonts, padding. nothing to write home about. Notice though that on both the P and h2 I used padding on these elements instead of margins on the wrapping div.content. Since .content has a width on it, remember what I said above. Width/height + padding or border on the same element == broken layout.

    #showcase .needHelp - I set the anchor to block so we can set top and bottom padding on it bringing us up to our desired 51px total height. Left margin serves the same purpose as the side padding on the h2 and P.. I usually avoid margins right up until I already have padding doing something... like here. Color and background-image are nothing fancy. We can't declare a background-color here since the .png has transparency (I converted it to palettized instead of the alpha you had -- which PSP7 HATED your png BTW!?!)

    #showcase .needHelp:psuedostates -- I gave it a hover state.

    #rotator - the relative positoning is so the images can be layered one atop the other making whatever .js it ends up with have a easier time of it. Too many of these things don't take the time to leverage CSS to do their gruntwork. The left margin makes 100% sure it always is pushed off the float. (the IMG tag can be a bit unpredictable at times)

    #rotator img - and then we absolute position the images. I force the width, but leave the height alone so aspect will be preserved.

    Oh, and I resaved those as .jpg since 300+k apiece was just a little ridiculous. Just one of those images was 2.5 times larger than I usually allow as the upper limit for a PAGE on a site (as in images + markup + css + scripts!)

    #firstColumn - float it, width it, pad it, give it that gradient background. I made both columns equal width which made things a lot easier to style/caclulate. 960px-16px padding for the gap between the columns == 944px. 944/2==472.

    .articleBrief - float wrapping because of the floated image, margin since using padding would break it in legacy IE, and using width as the haslayout trigger since zoom is invalid CSS and height would be obeyed thanks to the overflow. I use the actual px instead of auto for the centering since IE 5 ignores auto and I don't feel like messing with text-align:center on it's parent.

    .articleBrief img - float it. Oooh, impressive.

    .articleBrief h2 - the left margin makes certain if it wraps it will not wrap under the image. the padding is to make room for the arrow image, and then it's just a matter of setting the font. FINALLY we have a content section using %/em fonts so it's not a total accessibility /FAIL/ like that banner area.

    .articleBrief h2 a,
    .allStories,
    .picBox a
    - all of these pretty much end up styled the same, so I put them together. turn off underlines, set the color. I would NOT set that globally as normal link behavior in large content ares is something you should NOT be messing with. On headings or 'read more' links sure, but you get a link in the middle of a real paragraph of text, leave it the *** alone or at least TRY to preserve the behavior.

    .articleBrief h2 a:psuedostates,
    .allStories:psuedostates,
    .picBox a:psuedostates
    - mess of code just to set up the targeted hover behavior of restoring the underline. It's ugly, but whaddayagonnadoaboutit?

    .articleBrief p - padding, margin to avoid the floated image and if long text wraps, not wrap under the image, color.

    .allStories - this 'readmore' link just gets some side padding, as the natural padding and margins around it work out just fine. display:block makes sure it behaves how we want, and again we use margin to push it in since the left padding is being used to make room for the arrow image.

    #secondColumn - float it, width it...

    #tagCloud - pad it, margin the bottom, and I centered everything in it because it looked nicer to me that way. Instead of having two images for each columns rounded corner gradient, I just re-used the one from the first column now that they're the same width. Why waste making an extra image when you don't have to? Besides, it gives it a more consistent appearance.

    #tagCloud h2 - padding, font-size, nothing fancy.

    #tagCloud ul - ooh look, strip the bullets and do NOTHING else.

    #tagCloud li - display inline so they all end up on one line with normal word-wrap behavior.

    #tagCloud li a - I set inline-block on these (with the -moz workaround for legacy gecko) so we can set some horizontal padding. Many tag clouds try to stuff everything in as tight as possible, making it hard to read and useless as a nagivation aid. I like to add a bit of padding and use a consistent line-height so it's clearer what's what. (can you tell I hate the stupid overlapping animooted ones?)

    I also set them all to 'blue'... the .grey class can override that later.

    #tagCloud li a:psuedostates - underline on hover.

    #tagCloud .small,
    #tagCloud .medium,
    #tagCloud .large
    - 80%/100%/120% size gives a nice even spread, though I put bold on large. The real trick is the line-height. 150% of 80% and 100% of 120% both equal 120% of 100% -- so all our line-heights end up equal! This is something people using %/em heights often don't accomplish.

    #tagCloud .grey -- it's... grey.

    .picBox - float, display:inline normally prevents IE margin doubling. While technically only the second box needs it, there's no harm in sending it to both and who knows, just in case. Again the width is easy - 472px - 16px padidng between columns == 456. 456/2 == 288. Sad part is because it's all multiples of 2/4/8/16, I can do it in my head... Though a bit of advice -- when possible keep your images and columns multiples of 4 or 8. Since computers work in binary, direct exponents of two and multiples of 2, 4, 8 and 16 can actually be processed faster by the machine... and it makes the math a lot simpler to do in your head.

    Oh, I also set text-align to center again because I thought it looked nicer.

    .secondPicBox - The left margin gives us the space between the columns, while the negative right margin prevents IE from having 'float drop' when our width is 'exactly right'. It's a sneaky trick but it works -- in a LOT of cases it's easier to make your columns with everything floated the same direction, so knowing that trick is important.

    .picBox h2 - padding, font size. Impressive -- not.

    .picBox img - the display:block prevents it's inline behavior from adding or removing oddball paddings around it, but then we need to use margin:auto to center it as it's now ignoring the text-align in standards compliant browsers (but not in legacy IE)

    .picBox a - the inline-block is there to let us set top and bottom padding without wasting a block-level container around it. I fixed the font-size on this because it looked really silly when LF/120dpi made it big enough to wrap.

    Are we there yet Papa Smurf?

    #footer - clear the two floated columns as we don't have a parent element around them to apply self clearing to, pad the top and bottom to space it out a bit, and... text-align right? Yup, that way that anchor after the floated list will appear on the right without any extra wrappers! This won't effect the UL since it's FLOATED.

    #footer a - since they all got the grey, let's set them all to grey.

    #footer ul - turn off the bullets, float it.

    #footer li - you'll notice I set LI to display:inline a LOT. Generally unless you are really lucky they're more hassle than they're worth on lists like these, so just inline them to basically strip their behaviors clean off 'em.

    #footer ul a - float 'em, pad 'em, border-em on the left.

    #footer ul .first a - the first one we strip the left padding and border, since it doesn't need them. Since we only set this on one side, we don't need a .last class.

    ... and that's it in a nutshell.

    Hope this helps and you were able to glean some useful bits from it. Any questions feel free to fire away.

  16. #16
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    first, let me state what i've stated before: you are a man to learn from. that is to say i'm giving you the full respect you deserve for your knowledge.

    all my commenting is not to be taken as an attempt to paint your knowledge in a different colour. i'm only expressing my opinion.

    i don't express it in an absolute manner, but i'm prepared to show support for it. prove me wrong and i'll accept it and thank you for teaching me something. and you are one person i've said thanks to

    Quote Originally Posted by deathshadow60 View Post
    Any questions feel free to fire away.
    is this applying to all of us or just the OP? well, i'm gonna do it anyway. hope you don't mind.

    Quote Originally Posted by deathshadow60 View Post
    [...] but when you have 2k of CSS before you even start writing your own? Not a good thing.
    leaving the need for a reset aside, is this not you contradicting you a little bit? ok, your reset may be 0.0002k. there are bigger resets and there are smaller resets.

    what about the cache? whether you cache 0.0002k or 2k, you still are saving and you still have 0.0002k or 2k before you start your own.

    how big or small the reset you're using is may depend upon requirements or personal preferences. the same goes about js.



    also, you gave me a hard time in this thread, but you show different options here:

    Quote Originally Posted by deathshadow60 View Post
    Also note how I remove the whitespace between <html><head>, </head><body> and </body></html> -- No code should EVER go in-between those elements, so I strip the white space as a reminder and to save a couple bytes (the latter being more a lucky side effect than the reason I do so!)

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Notice I said the latter is a side effect, NOT the reason to do so. I'm using the removal as a reminder NOT to ever put code there. That's the real reason. It's like putting </tr><tr> on the same line when formatting. That it saves a few bytes just makes it nicer, but isn't the real reason to do it.

    As to the sizes, anything that is going to be almost 20&#37; of your code before you start writing code... that's bad. I mean, my resulting code is 7k, using the big resets it would be 8.75k - that's hefty growth.

    Funny thing is, if I remove the reset and declare those values everywhere I need them? The page would likely grow more than the 250 bytes the reset uses -- that's WHY the quarter of a K is alright while the 2k one is not... A 2k reset that replaces 1k of code is a bad thing. A 250 byte reset that replaces 1k of code on the other hand...

    Well, let's see. My original is 7.4k with the reset in it... remove the reset and set the values manually every time you need it on a item, that would add... to existing elements about 50 margin declarations, 30 padding declarations or edits to existing ones, and two border removals (ballpark figures) we'll be nice and say that's 12 characters each with the linefeed (padding is one more than that), so that's 984 bytes added to existing properties, but there are all the values I don't have element declarations for in the CSS that you'd have to add like say, HTML and FIELDSET, bringing it up to around that 1k figure easily.

    In a lot of ways, and you might like this comparison... What's the rule of thumb when you allocate memory to a pointer or even just declare a new varaible? NEVER assume they've been initalized to zero or some other default value. Think of CSS that way. All a reset is doing is variable initialization so that you have a common baseline on all browsers. If you don't, you end up having to declare it every time you use one of those values which actually ends up more code and if you forget -- it's going to be broken somewhere.

    Basically though - it's not about the overall percent of the code that makes a reset good or bad, it's how much code it is being used INSTEAD of.

    Hell, if it didn't completely shtup form elements I'd be all over * {margin:0; padding:0} -- but since no two browser makers handle form elements the same way you can count that right out. You set them to display:block they don't behave like display:block, you set them to display:inline-block they don't behave like inline-block... well, except in Opera

  18. #18
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ok

    first thing: no word on caching

    a bigger reset would be cached? would a little reset be cached also? would jQuery be cached? i don't address the opportunity of their use. but the reason for not using them, that are big in regards to the actual content, is it still valid if caching comes along?



    second thought: you count every bit of char: "My original is 7.4k with the reset in it... remove the reset [...]".

    i do too. that's why i don't let comments in my production code. that's why i cut down the names for classes and ids in my production code. that's why i minify. i do this using a method not yet perfected. but is a need and a natural step for html, css.

    js already has this, name shortening. ScallioXTX said that it makes perfect sense for js because of the names for functions and variables. i say it also makes perfect sense for html and css with their long "for readability" class and id names. yes, you don't gain much on whitespace. but you do after name shortening. using your own above calculations

    if the outcome after these steps is different in function, you don't blame the "compile" concept. in one of those steps something went wrong. find it and fix it.

    if you lose the easy readable and understandable source code that's because you are incompetent. if the client doesn't have it, he has to pay for its own mistakes. or force the source code out of the original developer, based on the contract they had, if possible.



    a third and somewhat unrelated thought: internet is also compiled. there are web related technologies (even PHP) where you have bytecode, which is more then uncompiled simple text.

  19. #19
    SitePoint Addict skunkbad's Avatar
    Join Date
    Apr 2008
    Location
    Temecula, CA
    Posts
    272
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm seeing issues with the current version of Firefox on Windows7 x64. The tabbed border at the top of the page is missing the left sides of the inactive tabs. Also, the text/links of these tabs looks like they needs padding or margins applied.

  20. #20
    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 noonnope View Post
    ok
    first thing: no word on caching
    Caching helps -- on subsequent loads, but you still have to keep firstload in mind. This is where your minification actually does something, this is where my using a reset to reduce code helps, and it's where minimalist semantic markup with separation of presentation from content helps by moving as much out of the markup and into the CSS as possible. Much less advanced techniques like handshake reduction through image recombination and not going nuts with the "use ten javascripts to do CSS' job and ten separate stylesheets without even a media type present" that it often seems other developers have a raging chodo for.

    Never forget the chance to make a first impression. If the page takes more than 10 seconds to load on first visit on a broadband connect, you've blown it.

    It's a balancing act, picking and choosing the optimizations that deliver on their promises in a meaningful manner.

    Though with the reset, again caching is just a nice side effect and not the real reason to do it -- cross browser support and easier development are more important and the real reason for it's use.

    Again, it's part of HOW I make pages that work all the way back to IE 5.5 (and sometimes even 5.01) with little or no extra effort. I spent more time on writing the explanation of the CSS above than I did writing the CSS thanks to the techniques I advocate for development. Said pages maintain lean code to content ratios even with the formatting and comments left in that usually beat other people's stuff in terms of leveraging the caching models and on bandwidth/handshakes.

  21. #21
    SitePoint Addict Owz2004's Avatar
    Join Date
    Mar 2004
    Location
    U.K (Wales)
    Posts
    213
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    WoW!!!!

    I'm blown away by your efforts.. Gonna have a long hard look over this tonight and will post something when I've had a chance to run over this..

    To be honest.. With regards to the project.. I've taken it on 95% of the way through.. and the person who built it all was a backend developer who recently left. I was asked just to come in and make it work across browsers..

    Thanks again for taking the time out to look at this..

  22. #22
    SitePoint Member
    Join Date
    Sep 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    who is still using IE 6 ? Highly suggest to upgrade to IE 7, I always ask customer upgrade to IE 7 for security reasons. IE 6 is very slow and got problems with CSS and the html 2.0

  23. #23
    Mouse catcher silver trophy
    Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,820
    Mentioned
    110 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by grado View Post
    who is still using IE 6 ? Highly suggest to upgrade to IE 7, I always ask customer upgrade to IE 7 for security reasons. IE 6 is very slow and got problems with CSS and the html 2.0
    About 5% of the browsing population is still using IE6, and more in some countries. Many of those people are on corporate networks and have no say over what browser they use. If you want to arbitrarily exclude 5% of people that's your call, but it isn't a call that I would make. It doesn't matter what browser your customers are using - you aren't designing a website for them to use, you are designing one for their customers to use, and you don't know who they are or what browser they are using, so your job is to make sure that it works whatever they are using.

  24. #24
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i suspect numbers are smaller.

    most people in corporate networks usually don't have permission to access resources outside their intranet: no internet access to be blunt. their ie use is dictated and restricted to inside corporation apps and servers. it' a bit of a "myth" this one.

    but you are supposed to provide quality browsing experience for the remaining ie6 visitors. and you usually know your client target customers. it's unrealistic to believe you will always code a site with worldwide audience.

  25. #25
    Mouse catcher silver trophy
    Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,820
    Mentioned
    110 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by noonnope View Post
    i suspect numbers are smaller.
    I'm using the logs from my site on AWStats, which show a shade under 5% of users on IE6. I am sure that for sites like this one that appeal to a techie audience, that figure would be lower, but I doubt that my site has a much higher proportion of IE6 users than the country as a whole.
    most people in corporate networks usually don't have permission to access resources outside their intranet: no internet access to be blunt. their ie use is dictated and restricted to inside corporation apps and servers. it' a bit of a "myth" this one.
    Not a myth at all. Like many other branches of UK national and local government, the office where I work has only one browser available on the network, and that is IE6. While certain websites like Facebook, warez, pr0n etc are blocked, we have unrestricted browsing apart from that.
    but you are supposed to provide quality browsing experience for the remaining ie6 visitors. and you usually know your client target customers. it's unrealistic to believe you will always code a site with worldwide audience.
    I'm not saying that it needs to function the same in IE6 as in a modern browser, but you have to make sure it does work and that all essential sections and functions of the site are accessible in IE6.

    How do I know my client's target customers? They are people, out there. Hundreds of them, thousands of them. They come from all walks of life, they have all sorts of different backgrounds, profiles, needs and wants. Some of them, I have no doubt, will use IE6.


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
  •