Navigation issue

HTML & CSS
21

For the most part correct, though really STRICT is about the separation of presentation from content and getting HTML back to what it’s supposed to be for - saying what the content IS NOT how it is going to appear.

You look at what’s ‘deprecated’ and what’s ‘obsolete’ in 4 Strict / X1.0 Strict, and most of it is presentation:

TAGS you shouldn’t be using:
APPLET, BASEFONT, CENTER, DIR, FONT, FRAME, FRAMESET, IFRAME, ISINDEX, MENU, S, STRIKE and U

Of those six are presentational - they say how something appears, APPLET is redundant to OBJECT, You want frames use a FRAMESET doctype…

More interesting are the attributes that are invalid as this really shows the stuff that has NO BUSINESS being in the markup.

alink, align, background, border, color, compact, face, height, language, link, name, noshade, nowrap, size, start, text, value, version, vlink and width.

Of those, all but TWO are stuff CSS is supposed to be handling. (though I disagree on START being deprecated on OL’s - to me the starting number IS content!)

STRICT goes hand in hand with the concept of separation of presentation from content - an entirely different way of looking at building a page from the train wreck of outdated techniques developed at the peak of the browser wars. It’s a simpler and cleaner way of doing things… Kind of what pisses me off about HTML5; It’s UNDOING a lot of the progress that STRICT brought us… STRICT was less tags, condensing redundant tags down (the next gen was even supposed to deprecate IMG in favor of OBJECT) - it makes it simpler and better structured if you learn how to use heading tags properly. Adding all these new PRESENTATIONAL tags to the specification is NOT a good direction.

As it sits right now most developers cannot be ‘bothered’ to write STRICT, much less use heading tags properly and remain blissfully unaware of tags like LEGEND, CAPTION, LABEL, FIELDSET, TH, THEAD, TBODY, etc, etc… Throwing even more tags at these same developers? NOT a good idea.

It’s like HTML5 has been hijacked by gaming munchkins and the people who never got the point of STRICT in the first place. Needless to say, I think I’m going to keep on using XHTML 1.0 Strict for a LONG time to come.

22

I think I have solved the spacing problem. I am not sure about the cross-browser thing though, I have uploaded the new version, so maybe someone can have a look and see.

23

Thanks, RyanReese for your help. I have done that, and am onto another problem.

The new problem is the spacing between each navigation link isn’t right. My client wants to be able to add other pages to his website later on, so the spacing between each link not only needs to be equal, there needs to be space between the last navigation link and the end of the navigation bar, for the new pages to be added. I have uploaded the new problem to the link above. I will add the link to this reply, please see below for the link.

HTML and CSS

I must mention that the css must be cross-browser.

Does anyone know of a good drop down menu, which I can use the product range navigation link?

24

If I might make a few suggestions:

  1. This is a new page, right? What are you working in tranny for? Transitional is for supporting old/outdated/half-assed coding practices, not for building new websites.

  2. never trust the default line-height. You change the font-size, set the line height.

  3. NEVER set a PX line-height on body, it prevents %/em from working properly on your content - and your content should ALWAYS be dynamic off the browser default.

  4. Use a reset to null margins and padding once, instead of dicking around saying it on every element.

  5. AVOID specifying height on your elements for no reason.

  6. AVOID styling LI to anything more than display:inline if you don’t have to.

  7. Ever heard of sliding doors? You are using three images to do the job of ONE… if you add hover states and a active state you are looking at NINE images to do the job of one.

  8. Ditch the nonbeaking-space LI - those aren’t actual items. You want that styling, handle it via padding, or by using a couple little tricks I’ll show you in a moment.

  9. Lose the DIV that’s around that UL for no good reason - particularly on a fixed width layout.

  10. there is NO reason to ever put a title attribute on an anchor that is identical to it’s content.

Taking all that into account, I suspect this is probably better for you:
http://www.cutcodedown.com/for_others/cturner01/template.html

as with all my examples the directory
http://www.cutcodedown.com/for_others/cturner01/

Is unlocked for ease of access to the bits and pieces. Valid XHMTL 1.0 strict, valid CSS 2.1, works in most every browser all the way back to IE 5.5.

Uses just one image for ALL the states:
http://www.cutcodedown.com/for_others/cturner01/images/mainMenu.png

That image is only 200 bytes larger than your three separate ones were, despite also containing the hover and current page states. That 200 bytes I guarantee will take less time and less bandwidth than the http response headers and server filesystem seek for two more file requests.

As you can see I first cut down the markup to what’s actually needed:


  <ul id="mainMenu">
    <li class="current"><a href="index.htm">Home</a></li>
    <li><a href="about.htm">About</a></li>
    <li><a href="services.htm">Services</a></li>
    <li><a href="product-range.htm">Product Range</a></li>
    <li><a href="contact.htm">Contact</a></li>
    <li><a href="sitemap.htm">Sitemap</a></li>  
  </ul>

In the CSS we have a reset, the page wrapping element is pretty much unchanged…

#mainMenu - The overflow wraps the floats, and I used the holly hack to trip haslayout so legacy IE will wrap floats. Since #pageWrapper has no explicit height on it, that will change to height:auto automatically everywhere making it safe to send to all browsers.

You seemed to want a top padding, so here you go, we just use background-position to slide the background down to match the top padding. The side padding pushes the LI and anchors in past the rounded edges.

Since there is a image interaction it’s ‘safest’ to use PX on the menu - just so long as the page content stays dynamic (%/em). I consider 12px the minimum if forced to use PX in this manner, and I’d seriously consider upping it to 14px or forcing it to text-transform:uppercase;

#mainMenu li - LI are a pain in the ass cross-browser. Assuming you don’t need dropdown menus there’s little reason to do anything more with these than just set them to display:inline to get them out of the way.

#mainMenu a - float 'em, pad 'em, style 'em. The background image we just slide to the left so that the rounded left corner isn’t shown. We don’t have to worry about the opposite corner since it’s unlikely any of your buttons are going to be wider than the UL containing them! You’ll notice I put a background-color on them so that images off the layout will still be usable.

#mainMenu .current a - we just slide the background up 60px to reveal the bottom 30px, and again background-color for images off.

#mainMenu a:psuedo - the hover/keyboard states also just slide the image up and set a images-off background-color.

You’ll also notice I avoid specifiying an actual height that would be obeyed - line-height plus padding lets it all add up automatically making it easier to deal with… oh, and I made them 30px instead of 29px since that’s means even top/bottom padding on the anchors, and it’s easier to think 30/60/90 on the background-position than it is 29/58/87… usually I work in multiples of 8, but 10’s are just as good. When doing top/bottom padding and font-sizes, I try to stick to even numbers since browsers tend to round-off fractions and calculate odd-numbered line-heights differently.

Pretty simple.

25

Just remove the top padding on “.topnav”

Since you have the image set to repeat (default) it will go up and down repeating until the entire width/height is filled. The padding is just part of the image :slight_smile: