JavaScript Rollover Menu

I recently updated my rollover menu. I created it myself and it is a bit different than the usual way I guess. I was just wondering if anyone could help me test to see if the rollover menu works correctly. http://armadness.no-ip.biz/sample.html If anyone would like the script for this simple rollover menu let me know and I would be glad to send you a copy.
I am currently using a version 41 of Google Chrome and it works fine. I have also tested it in IE 10 and 11. So if you do check it please let me know what browser you are using. I am using this menu on another site and I am not sure if users are having a hard time navigating. No one has sent any support messages but, the members on the site are not very active.
Anyways any help would be greatly appreciated.

 

I had to double and triple check that this wasn't a bounce of a decade old post... If you mean a hover menu, the one at the top of that page... There are a few things you should know:

1) The text seems misaligned on large font systems... this is probably because you are using fixed size images/container instead of dynamically sizing ones. It's why fixed size backgrounds mixed with dynamic fonts is an accessibility train wreck.

2) The first rollover had a delay because you aren't pre-caching the hover state.

3) This is 2015, not 1997, why are you using JavaScript for THAT? NOT that it was ever really something scripting should have been used for from the DAY CSS was introduced, but to see it being done this way now is just... what the?!??

4) Images for backgrounds on buttons like that is a waste since these days you could just do that with CSS3.

Generally speaking, your entire codebase REEKS of the WORST of 1997 development practices -- now I realize that the bleeding edge of 1997 has been made hot and trendy by halfwit garbage like jQuery and HTML 5, but really when you have tags like CENTER that have no business on any website written in over a decade and a half, little if anything resembling semantics, scripttardery destroying accessibility by screwing around shoving new windows down users throats, missing tags (like opening those TD you are closing), tables for layout, etc, etc... you REALLY might want to learn how to use HTML properly BEFORE you go diving for the scripttardery.

Though even your first line of code proudly proclaims the problem; transitional -- which quite literally means "in transition from 1997 to 1998 coding practices". Tranny is for putting new stuff into old pages, NOT for building new websites as most of the older crap it allows that aren't in 4 STRICT (much of which ALSO wasn't in 3.2) are accessibility and usability rubbish, or just plain redundant to other technologies job.

Laughably you don't even have valid HTML 4 tranny! You can't put a TD inside an anchor. That iframe nonsense isn't really winning you any points either in terms of usability or functionality.

A MODERN approach to doing what you have there would likely go something like this... it's a menu, a list of choices, so that's an unordered list. IF you want to use the pointlessly redundant HTML 5 garbage, you could put NAV around it, but if you bother using numbered headings PROPERLY on the page that really serves no purpose.

	<ul id="mainMenu">
		<li><a href="userIndex.php">SqueezePage</a></li>
		<li><a href="surf.php">Sales Letter</a></li>
		<li><a href="sites.php">Download</a></li>
		<li><a href="banners.php">Thank You</a></li>
	</ul>

Code (markup):

With this for CSS:

#mainMenu {
	list-style:none;
	text-align:center;
}

#mainMenu li {
	display:inline;
}

#mainMenu a {
	display:inline-block;
	padding:0.5em 1em;
	text-decoration:none;
	color:#FFF;
	background:#35A;
	-webkit-border-radius:0.75em;
	border-radius:0.75em;
	box-shadow:
		inset  0.5em  0.5em 0.5em rgba(255, 255, 255, 0.4),
		inset -0.5em -0.5em 0.5em rgba(  0,   0,   0, 0.4);
}

#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover {
	background:#666;
}

Code (markup):

Here's a live demo of that:
http://www.cutcodedown.com/for_others/annGilman/template.html

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

... is open for easy access to the files.

No scripttardery, no images, no delays on first hover, a fraction the total code and filesizes, auto-scales and adjust button sizes to the content, will auto-wrap properly at smaller display sizes, etc, etc, etc...

 

Wow What? I had no idea you could do that with just css. I went to school about 5 years ago and they where teaching use transitional xhtml and html. I know html 5 is out there and great but, does not work with all browsers. I guess I need to go back to school. lol. I thank you very much for the reply and help. I have saved a copy of your example so you can remove it from your server if you like. Or just keep it there for others.
Any suggestions on where to go and learn more newer techniques. I know w3schools is one place but, a lot of people say that site is garbage. Anyways thanks again your post was very helpful,
Ann

 

going back to school at this point wouls move you up to about 2009 or 2010. The educational institutions are generally 5 years or more behind with very few exceptions. Even most online training is 2 or 3 years behind. The place I generally recommend for learning is https://developer.mozilla.org/en-US/docs/Web because they have an army of volunteer editors and developers who keep everything up to date. Not the easiest place to learn, but probably the most up to date on web development topics.

 

Using images real world deployable without JS since around 1999, without images whatsoever real world deployable for probably five years now. Older browsers will get flat backgrounds without the rounded corners or shading, whoopedy freaking doo, at least it's still functional there.

... and that is why I consider mainstream education in IT to be utterly and completely worthless. @COBOLdinosaur just said 5 years, honestly it's more like a decade or more out of date. If they were teaching you transitional as what to use five years ago, they were TWELVE YEARS behind the curve in an industry where 3 years is obsolete, 5 years is the scrap heap.

Though as I keep having to explain to people what good is a four year program in an industry where 3 years is obsolete?

Degree in compsci at this point is pretty much worth less than a used sheet of bog roll.

That is the LAST thing I would suggest; since with all but the rarest of exceptions the "educators" are a decade or more behind the curve, or teaching crap that just makes it harder to do in a truly professional manner.

It also doesn's offer much in terms of real world improvements IF you understand what HTML 4 STRICT was, what it was for, and it's general intent. In fact, there are only two things in it you are likely to ACTUALLY use on a real website; AUDIO and VIDEO -- and that's JUST because it's being shoved down our throats whether we like it or not. The laugh is it promotes the vendor lock-in the W3C claims it's there to fight, and is an example of undoing the intent of STRICT since both tags are redundant to OBJECT.

4 Strict was all about removing redundancies, returning us to the semantics of pre HTML 3.2 coding, and generally simplifying things. HTML 5 basically seems to be taking those concepts and going "huh, what? Oh, forget that just go ahead and sleaze it out any old way."

Of course that stems from HTML 5's origins with the "WhatWG" where the people who created it were documenting what people were doing, not creating what they SHOULD be doing... Unfortunately what people were doing was pissing out HTML 3.2, slapping in the proprietary tags that came after and slapping 4 tranny on it. That's why HTML 5 has all the hallmarks of "semantics, what's that?" and "what do you mean this is redundant?"

Which is why IF you were to use HTML 5, my advice is to write 4 STRICT or XHTML 1.0 STRICT first, live with the validation errors for tags like AUDIO or VIDEO, and then slap the 5 doctype on it last minute.

W3Schools is indeed a very poor reference. It's actually quite hard to point people at good references as the specifications aren't written for web developers to use, it's written for browser makers to implement.

This is a VERY old reference, but HTML 4 strict hasn't seen a real change since 1998 so...

http://htmlhelp.com/reference/html40/

It is one of the few that takes the specification and turns it into plain English a "mere mortal" has even a CHANCE of understanding. That each of the sub-pages for tags includes the rules for what tags can be the parent of the one you're looking at and which tags are valid children of same is one of those things that SO many developers never learn, and then wonder why their code doesn't render as they expect and why they end up diving for CSS hacks and IE conditionals instead of just fixing the markup.

... and if an element says "deprecated" or "non-strict' -- don't use it! In fact they have a scripted bit at the top of the tag lists that says "hide non-strict elements" -- you might want to just hit that from the start.

Read every tag they document and pay attention to what the tag MEANS. If you learned transitional in a formal education setting (aka having smoke blown up your backside) one of the things you'll probably find hard to grasp is that your tags should say what things ARE, NOT what you want them to look like. Lists are for short bullet point list items, NOT showing bullets or numbers before them. Paragraphs are for grammatical paragraphs (one to three complete sentences forming a complete thought), NOT that you want gaps between sections of text or elements. Numbered headings provide document structure by marking the start of subsectiosn and what is a subsection of what -- a H1 is the heading that EVERYTHING on the page is a subsection of, H2 marks the start of a subsection of a H1, H3 marks the start of subsections of the h2 before them and so forth; they do NOT mean "text in different sizes" even if that just happens to be the default appearance in visual user-agents. HR means a section break, aka a change in topic NOT "draw a line across the screen". THAT's what semantic markup means, and it's based on professional writing norms. That's what TBL created HTML to do in the first place!

Which is why if you WERE to go back to school for something that would be useful in making websites, my advice would be some writing and language courses. FAR more useful than what the majority of schools try to pass off for web development.

Also explains why the "TLDR Twitter generation" are mentally handicapped when it comes to web development.

If you follow those rules and the intent of HTML, writing markup becomes simple, easy... ridiculously so. CSS is the hard part. Best reference I can think of for learning it is on MDN.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference

Though sitepoint (who I'm usually at odds with) has a decent reference as well. (I'm willing to set aside our differences when they make something this good)
http://reference.sitepoint.com/css

(I am FAR less impressed with their HTML reference)

Those are just references though -- finding a good CSS tutorial; I've never seen one. I had to learn it by trial and error; and really the best in the industry at it did it the same way.

Basically, HTML is easy, stop making it hard; CSS is hard, stop trying to make it easy... That latter part might sound odd, but the train wrecks vomited up every time someone tries to 'simplify' CSS just makes it worse -- see inept mouth-breathing dumbass nonsense like bootstrap, YUI, LESS, SASS or even conceptual methodologies like OOCSS.

 

Thanks a bunch Deathshadow. You have given me a lot of useful information. I remember when I was in school some of the students where saying that University of Phoenix is not on the list of approved web development/design courses. Something about most IT companies don't hire people that are not from approved colleges. Would have been great to know that before spending all that money.
When I finished school I found out the hard way that companies are very picky about who they hire. I went out and tried getting an IT job for about 3 years and had several interviews with no such luck.

That's great. I know CSS is a lot more intense than HTML and for a good reason. I just wish the browsers would not have such great differences when it comes to interpreting the code. I mean I know I should write in HTML4 strict however, sometimes I can't get elements to appear in the browser the way I want so I get lazy I guess and start using older tags like <center>. I know that is depreciated but, sometimes I just don't know what else to do. I am starting to change the way I write code so it does not include depreciated elements.
I still see people all over the place using tables for bullet points instead of just using an un-ordered list with images. And formatting pages using tables is another big no go that is still used a lot. I have at least figured out how to format the page using nothing but <div> elements. That was one thing they did teach us believe it or not.
Anyways just wanted to say thanks a bunch for taking the time to answer my question in such depth. This is a great forum no doubt about that.

 

Actually, among desktop browsers, there is little difference in rendering; at least that matters. If you use a DTD that triggers standards mode, all commonly used browsers are pretty good, now. In quirks mode, not so much, as it is designed to accommodate old, non-standard browsers and their coding.

 

Even more true if you don't care about browsers more than 5 years old, and even then the differences are negligible all the way back to IE6. 90%+ of the "problems" can be avoided by triggering an IE 'bug' called "haslayout" that actually fixes the rendering behavior, and avoiding a few minor oddball corner cases like stripping style off LI and setting their display state to inline.

Well, and avoiding a lot of the "gee ain't it neat" nonsense that has no place on websites in the first place. There's a lot of fancy stuff that the artsy folks, marketing types and scripttards get wood over that to be frank, no matter how pretty it is or how much "wow" factor it provides, it makes sites less useful, slower to load, harder to develop, and are more likely to cost you visitors than they are to retain them. Wow only last's once, "Where's the beef?!?" lasts a lifetime.