Hi, Everybody: I've been having a compatibility issue with IE8 for my midterm project website (http://student.berkeleycc.org/rcheung/). The problem is that IE8 doesn't seem to recognized the selectors that I designated for the <li> element in the top nav bar for that specific page that I'm on. The selectors for this <li> element is (.topnav li.onpg a:link ,.topnav li.onpg a.visited). The a.hover, a.active, and a.focus works as they were suppose to. The .topnav is the class for the <ul> element, and the .onpg is the class for the specific <li> that I'm designating. Everything works with Firefox. Please help me out! Thanks! supra411
Note that you have errors in your html markup and one, possibly problematic, css error. http://jigsaw.w3.org/css-validator/validator?profile=css3&warning=0&uri=http://student.berkeleycc.org/rcheung/ http://validator.w3.org/check?verbose=1&uri=http://student.berkeleycc.org/rcheung/ You should fix these errors before attempting to debug. cheers, gary
Well, hope you're not paying for this education if this is how they're teaching you how to code. DIV around the H1 for nothing, P on text that should be part of the h1, div around the menu UL for nothing, P+STRONG doing H2's job, H4 without h3 or h2 preceeding it, attributes like TARGET and ALIGN that have no business being used on any website written after 1997, an H5 I'm pretty sure is not a subsection of the H4 preceding it... The gibberish/nonsensical use of heading tags and use of P+STRONG for what are quite obviously headings is a real head scratcher. Even funnier one of your H4 likely SHOULD be P+STRONG, since it's not the start of a subsection and as such isn't even a heading!!! ... and that's just the markup. CSS is filled with redundancies for such a simple layout. Especially with the crappy fixed width pissing on it's accessibility. (No offense, I call 'em as I see 'em) As to IE8 ignoring it, the multiple spaces between the li.class and a:visited could be a cause, though whitespace is supposed to be whitespace. Of course with everything having it's width fixed... much less the endless/pointless/redundant declarations. Gimme a bit, I'm gonna do a rewrite to show you the 'right way', and while at it I'll take a stab at fixing some of the accessibility issues too... Then I'll write you up one of my nice long section by section explanations of the how/why it works.
,... and here's the rewrite: http://www.cutcodedown.com/for_others/supra411/template.html as with all my examples the directory: http://www.cutcodedown.com/for_others/supra411/ is open for easy access to the bits and pieces. Redid it as content-first columns, semi-fluid elastic responsive layout (yes, all three), and fixed the semantics. I'm out the door for a bit, but when I get back I'll toss together an explanation of the how/why/what on the new markup and CSS.
Hi: Thanks deathshadow and kk5st for your suggestions! Regarding the coding: That was my fault! I just started doing web design, and I didn't want to have CSS get into the way of messing with the design of the layout, etc., so I just created a new rule anytime I got bogged down by my lack of knowledge of CSS and HTML. I started to noticed as well during the weekend, and it's definitely something I need to look for in my final project. Thank you for pointing out the importance of this, though. Thanks again! supfa411
Well, that's where my code breakdown/explanation comes in, so you can learn from it. So lets start off with the markup: The first change is moving it to a STRICT doctype. Tranny is for supporting old/outdated 1997 style code, NOT for writing modern websites. Language encodings are also important, and unlike HTML 5 halfwits let's include the http-equiv for local testing or in case you end up on a server that fails to transmit those values. (NOTE the server still has to be told to send UTF-8 as the mime-type on deployment) The META[viewport] I include is to make mobile browsers realize it's actually designed FOR mobile. There's a second instance of this in the CSS. The CSS Link includes MEDIA TARGETS. There's no sense sending your screen layout to print or screen readers. I suggest "screen,tv,projection" as a common target for screen layout as there are still webTV type devices in use who will only see "tv", and many kiosks (Opera and FF based) use projection instead of screen. I have an outer container as you did for setting the width, I call mine pageWrapper since just 'wrapper' or 'container' is a bit... vague. The H1 is a single heading -- heading orders seemed to be your major weak spot, so let's cover that. Headings, by definition, are the start of a section... So why do we have numbered headings? To indicate the start of a subsection of the 'higher order' (lower numbered) heading preceeding it. H2's are the START of a subsection of the H1, H3's are the start of subsections of the H2 before it, etc, etc... This is why your H4's made no sense as there were no H2 or H3 for them to be subsections of... and I'm pretty sure the H5 "References" is not a subsection of "Amazed Yet?"... That "Amazed Yet" H4 making no sense as it has no content after it; it's not the start of a subsection so why is it a heading? H1 (prior to the HTML 5 garbage) is "special" -- as the highest order heading EVERYTHING on the page is a subsection of it. Think of a newspaper or book (this torques off the people who use them wrong, as it hijacks their argument), what's at the top of EVERY page? The title of the paper or book. It might be bigger on the front page or cover -- but it's still the topmost heading for each page underwhich everything on the page is part. That's H1's job and why pages should only have one H1. Likewise, while the headline on the front page of a newspaper might be bigger and 'more important' in terms of import, it is STRUCTURALLY no more or less important than the headings around it nor are any of the other headings on the page typically a subsection of it. For example "Man mugged on Emerald Street" and "K-6 get new building" are not subsections of "MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE!" -- or at least we hope not as that would be one twisted town. They are structurally all H2 -- JUST because they're presented different doesn't make them structurally different. ... and that's really the part most people starting out making websites have trouble getting; the point of HTML is to say what things ARE structurally, NOT what they look like. If you are choosing your tags that have meanings (paragraphs, numbered headings, lists) because of what they look like by default, you are likely choosing all the wrong tags for all the wrong reasons. What it looks like has NO BUSINESS in your HTML, really in any form. That's also why the 'meaningless' containers are tricky -- DIV and SPAN... likewise for classes. Wherever possible you should avoid adding DIV or SPAN, and if you do use them, avoid saying what the appearance is and instead say what it is they are wrapping with the classes. The main reason for said approach is that what has one appearance on one CSS media target might have an entirely different meaning on another... "LeftColumn" might not be a column on the left on mobile once you have responsive layout kick in. What's "red" on screen might be bold on print. That's why presentational classnames (and therein most CSS frameworks) are nonsense. Finally, it helps to know what elements are block level containers -- which brings us back to the H1. H1 is a perfectly good block-level container, generally speaking there isn't anything you can do to a DIV you can't do to any other block-level tag. This is why my rewrite doesn't need a DIV around the H1 or UL -- nothing is being done there I can't do to the tags inside. Without the screen presentation that initial text is all one sentence -- you shouldn't split up sentences with block level tags (H1, H2, P, DIV), that's inline-level tags. The semantically neutral/meaningless SPAN doesn't change the meaning of the text -- so it's ideal to say "this is going to be treated different" -- I don't say HOW it's treated different. Big bonus there, since there should only ever be one H1 on a page, we don't need ID/classes on either the h1 or the span inside it. The menu UL is the same deal, though it does get an ID. The reason I use ID's instead of classes on major elements is later on one may want to add a 'jumpTo' or 'accesskeys' menu, or directly link to certain areas of the page with a hash. template.html #mainMenu skips to the menu just as template.html#content for example would jump to <div id="content"> I also use a bit less vague a class for the 'current' page... current. 'onpg' is... well... vague. I don't like vague in my markup DIV#columnWrapper is used to apply the background behind both columns, clear any floats, and pad in the two columns when columns are present. The double-wrapping DIV #contentWrapper and #content are there to provide a simple/reliable content first column. There is a technique called "Holy grail" that uses just one DIV, but I find it unreliable at best, hack filled nonsense at worst. We'll cover how this works once we get to the CSS, for now just know it's how the content ends up first in the multi-column layout while still being 'fluid' in width. Why is moving the content first so important? Logical document structure, non screen.css users, and so that it's first when media queries strip off the columns. The contents of the main/widest/auto-adjusting column should be the most important thing on the page -- as such it should be as close to the top below the H1 and primary navigation as possible so that on things like screen readers, column-less mobile, even search engines, it's right there up top. I moved the picture into the markup as a .trailingPlate (a plate that when possible should be to the right of the content, but does not HAVE to be so) and 'scaleAsNeeded' meaning we can adjust it to fit instead of keeping it a fixed size. It's easier to do this with a IMG than CSS, and really I think this image qualifies as content given it's size and placement. #content H2 - all these headings are kin to each-other. You want different appearance on them say why with a class, apart from that they are not subsections to each-other. #content P - no real changes there... TARGET attribute -- notice I killed these off compared to your original. First off target has NO business being used on any website written after 1997; do NOT shove new windows down the users throat and they have no place on frameset-less pages. That said even if you were using them, "_same" is the default behavior so there's no reason to ever say that. EVER. P+STRONG instead of H4 -- you want it bigger add a class to target it, but this just wasn't the start of a new section of content, if anything it's the end. STRONG provides "more emphasis" which seemed appropriate to that text. That's something I suggest you research is the difference between B, I, EM and STRONG -- the first two are semantically neutral and only say "this would be bold or italic when printed like a book or company name", the latter two mean "emphasis" and "more emphasis". B and I are NOT deprecated despite wild claims to the contrary, nor is their use discouraged unless adding emphasis is the intent. There's an example a friend came up with I always use that makes the difference clear as a bell. <i>GURPS</i>, <b>Steve Jackson Games'</b> flagship roleplaying game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows</i>. However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS,</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong> It's important to know which ones to use in which case! I put a DIV around references so that if desired you could add that border to the H2. Any time a 'section' is going to have elements styled different from the rest, I group that section in a DIV... also adding a ID to a wrapper makes it easier to target with #. While I didn't implement it in the CSS, if you made all "#content h2 {text-align:center;}" you could target "#content #references h2 { text-align:left; }" -- while ID's are unique, you need it in this declaration so legacy IE will pay attention and actually override the parent ID. (pain in the arse). So closing out the content area, we come to: DIV#extras -- the 'extra' content that gets put in a sidebar. I've stopped calling them sidebars since with responsive layout or other media targets it may not be a sidebar. This gets a simple single DIV wrapper for all content going to the side. (and no HTML 5-tards, it's not a Section, it's a DIV since there's no semantic meaning to apply). Closing the column wrapper you'll see a lonely HR. Horizontal rules indicate a change in topic when using semantic markup (even HTML 5 which I piss on from orbit agrees with this! One of the few good things I have to say about 5)... Basically it means you should treat them as a content-less H2, <strong>NOT for drawing a horizontal line on the display!</strong> (see what I did there?). In this case it's saying the content in the footer is NOT a subsection of <h2>Have a Question?</h2> since again, all those block level DIV do NOT provide that meaning. If we don't want the line in our screen presentation, we hide the element since it's not there for screen/tv/projection users anyways! DIV#footer is a simple single wrapper. I moved the right content first in a classless DIV to make it easy to position, since the order in the footer really doesn't make a difference -- and it makes the text 'topic-less' instead of needing another HR after the last UL. Naturally both the headings get heading tags, and the list of choices go into ... a list. When you have a list, make it a list! Then close out the document. Oh, you might notice my commenting style. If a comment ends up between sibling positioned, negative margined or floated elements IE and some builds of FF can wig-out and cause two rather nasty bugs -- disappearing content and double render -- both of which are EXACTLY what they sound like -- large sections of text just failing to show up on screen, or worse the same text being rendered a second time in some oddball/unexpected location. Since FF 4 it's not really an issue on firefox, but with legacy IE still heavily in circulation and the bug even tripping as recently as IE8, it's a problem. Solution? Put the comment before closing tags instead of after. If it's before a closing tag it can never end up between sibling elements. Also notice I don't say "end" -- of course it's the end, that's what </div> means -- and I use a period or number sign to indicate if it's a ID or class just like in CSS. So that's the markup. Gimme a bit and I'll breakdown the CSS in the same way so you can follow along and grasp the how/what/why of what I was doing.
Alright, let's review the CSS -- for the crowd feel free to follow along: http://www.cutcodedown.com/for_others/supra411/screen.css First thing I do on every page I write is call a reset. There are larger resets like Eric Meyer's "Reset Reloaded" -- but 90% of what it does is just code bloat for me, and it treads into almost being a framework. Basically "Reset Reloaded" is the one that gives resets a bad name. There's the much smaller "* { margin:0; padding:0; }" -- aka the "universal reset" but I've found that can cause problems cross-browser with form elements since Microsoft and Mozilla still need to pull their heads out of their backsides about form element dimensions. (I like how Opera treats them -- the same as inline-block!) HR - As mentioned, HR are for non-screen.css targets and semantic markup. Generally I hide them for screen users and if a 'line' is desired, I use border with padding and margin. Gives you better control and is more consistent cross-browser. @media (max-width:480px) -- this media query tells mobile browsers NOT to auto-adjust the text size to their display preferences, because we're using auto-adjusting fonts in the first place. We have to query it since sending the -webkit one to desktop safari breaks it's zoom.... Which is... really stupid when iOS Safari doesn't have that problem. body - 85% font size = 14px off default 96 and 17px off 120. Your 90% returns the same for 96, but gives 18px which feels a little large. color, background -- nothing to write home about. You'll notice across the page I always declare the entire condensed font property. WHENEVER you change font-size you should change line-height, and by the time you have a font-weight thrown in it's as many characters to say them separately as it is to say the whole stack. It's also nice to be able to see at a glance EXACTLY what's being set for fonts when there's a change. #pageWrapper -- the width constraining element, the min-width is for non media-query capable browsers (IE 7 and 8), the max-width is to prevent lines of text from getting hard to follow on really big displays. (Like my 2560 wide 27"), and then a percentage width to show a little bit of body background at the sides at intermediate resolutions... This is called a "semi-fluid layout" in case you've not heard of it. Both min and max are stated in EM's, so that when the default font size is different the min/max adjust to match -- this is called "elastic layout"... So we have an elastic semi-fluid design... which until media queries came along was the 'king' of accessible layout. (anything else -- like fixed widths -- being garbage). h1 -- pad the top and bottom, align the text right, make the text big and bold, and apply the background image. You'll notice I cropped the image down to the part that actually had content, discarding the rest. h1 span -- display:block puts the text on it's own line, then just shrink the text and again, restate the line-height so it's properly obeyed. #mainMenu -- the relative positioning fixes some cross-browser bugs on reporting width to it's children, the zoom:1; trips "haslayout", which is a IE specific condition that fixes some other errors. The absurdly small font-size cuts down on the space between inline-block elements, and of course center/strip bullets. #mainMenu li -- setting these to display:inline basically strips styling off them; avoiding a nasty IE8 bug called the "staircase effect", and letting us use the anchors inside them to do the grunt-work. #mainMenu a -- inline-block means they'll appear on one line centered, but we can set width and height (and top/bottom padding/border) on them. I padded the top and bottom and put black borders in place so that all we have to do on hover is change the border-color. The massive font-size is just there to undo the whitespace scaling font-size on #mainMenu. We can only reliably go to 33.1% thanks to some browsers still insisting on making things wider. Really the 'all of them equal width' across a page is NOT something I would do on a website in the first place; I'd really consider axing that as a design concept. #mainMenu a:psuedo -- the hover states. Notice I don't have to say :visited or :link becuase A hits all of them. That's something you had in yours as a redundancy in that you were stating the values for :link and :visited together, then the keyboard/hover together, when you could have just hit A nabbing everything they share, and then only change what needs to be changed on the pseudo-states. #mainMenu .current a -- enlarging the font 125% (adjusted 100% more for the #mainMenu declaration) makes it easy to keep border and padding the same size... 0.5 / 1.25 == 0.4 exactly. Color the bottom border, done with the menu. #columnWrapper -- top margin pushes away from the menu, padding pushes in the columns, overflow:hidden wraps floats, zoom:1 trips haslayout so floats are wrapped in older versions of IE, and then the coloration. #contentWrapper -- This is where the magic begins. This element is floated right with 100% width, leaving 0 px free for anything else to fit. #content -- the content just gets pushed in the width of the column plus any extra desired padding (I added 1 em) making a blank spot for the column to sit over. We'll skip over the elements inside #content since those are nothing fancy, just paddings, colors, etc. #extras -- relative positioning makes it depth-sort over any siblings that aren't positioned -- like #contentWrapper. We float it right, set the width to 15em, but then set a negative right margin of that same width... What does this do? Basically there are 'two' boxes a browser keeps track of for every element. The "flow" box which is how it is sized in relation to other elements, and the "render" box which is what it looks like. It is possible to change the position of the render box independantly of the flow box using position:relative with top/left/bottom or Right... but you can also change the size of the flow box by changing it's margins, including going negative. Bottom line, a negative right margin equal to the element's width makes it zero width in flow, hanging to the right. You know how above I said there were 0px left for a float to fit next to #contentWrapper? Well, this element is now 0 width in flow so what's it do? It pops into position next to and over it! It's a sneaky trick that works in pretty much every browser, and is the cornerstone of most reliable content first semi-fluid or fluid layouts. Powerful technique, common practice, but a bit wonky to explain or grasp at first. (If my explanation didn't cover it well enough, ask). BTW, "Flow box" and "render box" oversimplifies and it ain't quite right, but for purposes here it will have to do as I ain't got the time to explain it to you. Because it has to be a perfect width it's impractical to try and declare border on it, so I used box-shadow. IE8/lower won't get the white inset line, OH WELL. Again we'll skip past the elements that really shouldn't need any explaining, and get right to: #footer -- set up float wrapping behavior, pad the top for the gradient image, pad the bottom to be pretty, apply the gradient as a background. You'll notice I recreated the image as grayscale in a much smaller file and then let the browser do the heavy lifting of repeating it. #footer div -- floated right, align text inside it right, pad it on one side so the text on the left doesn't run right into it, and set the line-height taller to account for extra padding we'll be adding, with a negative top margin to make that line up properly. #footer h2 -- I'm floating both of these to let the UL remain block-level. Older IE can't do inline-block on a H2, and inline doesn't give us proper multi-line. (we'd have to add extra BR to the markup). To make sure they don't "ride up" on each-other we'll clear left side floats on both (though only the second one really needs it, it's often easier and harmless to set it on both). Font size adjustment is again part of the whole "say what they are, not what they look like" #footer ul -- strip bullets, add some bottom padding. 0.5em bottom padding + 1.2em line-height == the 1.7em I declared on the DIV. #footer li -- again, set this to inline to get it out of the way in IE8. #footer li a -- I add the LI so we aren't targeting ALL anchors in the footer, just incase you want to add styling to other anchors in say.. the DIV. Inline-block makes them accept dimensions if desired (and makes the entire thing instead of just the text clickable in all browsers)... padding, line-height, color... and instead of using vertical-break characters, I use border. #footer li:first-child a -- kill the border in modern browsers. Legacy IE will show the extra border, OH WELL. (I'm no longer bending myself over the table to be 100% perfect in IE7/lower) #footer li a:pseudo -- strip text-decoration on hover, nothing fancy. That's the primary template... I toss in a few standard classes I use on most sites. .trailingPlate, .leadingPlate, .plate -- the standard 'plate types'. You can pretty much figure those out. .scaleAsNeeded -- sets a 40% max-width so as the screen gets narrower the image shrinks leaving room for the text around it. Then the media queries to adjust the layout as things get narrower. @media (max-width:48em) -- this query simply strips the % widths off the menu and pads them instead. It becomes too 'fragile' to try and use % widths this narrow with such massive menu texts. @media (max-width:44em) -- adjust the menu even narrower. @media (max-width:40em) -- sets a new min-width for query aware browsers right down to the narrowest handheld size we should bother supporting and setting the width to auto so as much screen as possible is given to the layout. The H1 loses the image and is centered with new margins and padding, the menu items are put on single lines with border all-around, and then the columns are stripped off by killing all the floats and margins. Likewise the floats in the footer are stripped and that too is switched to centered text. @media (max-width:30em) -- even smaller we decrease the paddings, change .scaleAsNeeded to an even smaller size with a min-width to at least make it usable, and shrink the heading texts so they're not sucking down the entire display by themselves. That's it... any questions, fire away. The reason I do these rewrites is so I can go through them with posts like these to explain it -- that way you can learn from the example.
Thanks for the lengthy lesson, deathshadow! Please give me a while to absorb it all. Thanks! supra411
Thanks again deathshadow! I read through your lesson. Your headings lesson is extremely useful, in regards to when I should use them, and the fact that they are block elements, and I'll try to make sure that I organize the headings better for my final project (the proposal already due next Mon!!!) However, the naming of div tags, structure of the pages, use of class instead of id for the main div tags, and the neglect of mobile devices, are done because of the assignment requirements, and the fact that the instructors taught us (the class) to use Dreamweaver. Thanks again deathshadow! I'm new at this, so I'll take whatever I can get! supra411
Now, don't take this the wrong way... Well, at least they give you toilet paper in the form of your report cards and diploma when they're done teaching you how to take a dump and call it a website -- and people wonder why I consider formal education in IT to be utter and complete trash that you basically have to unlearn to do a blasted thing properly. But then I have about as much tolerance for "educators" as I do bigots, sexists, doctors, lawyers and people of faith... which is to say none whatsoever!