Images not displaying correctly

[tstmuge]

Not sure if this is the right place to post this but the images display correctly through viewing it locally(offline) but when I uploaded my website they did not display correctly. I have a code so when I hover over images it show the buttons sinking in:

<img style="border: 0px solid ; width: 193px; height: 65px;" alt=""
 src="[COLOR="#B22222"]http://x10hosting.com/forums/[/COLOR]images/mainbox.png"
 onmouseover="this.src='images/mainboxover.png';"
 onmouseout="this.src='images/mainbox.png';">

Why doesn't work, is it something this website doesn't support.
P.S. I apologize it's my first time ever creating a website from html coding and I'm not too familiar with everything.

Not included in the code:http://x10hosting.com/forums/

 

[essellar]

This really belongs in the "Scripts, 3rd Party Apps, and Programming" sub-forum, but since one of the questions here is "is this supported?", the answer is "yes". A better answer would be "yes, but you should pretend it isn't".

There is at least one huge problem with doing mouseover effects this way, and that is latency. When you are working on your local machine, it takes almost no time at all for the browser to get a file from your local hard drive. Now you're taking it to the web, where it's going to take at least a few milliseconds to send a request to the server. That request may spend some time in a queue, waiting for other requests to be completed (yours is not the only web site on your server; you're sharing with thousands of other people). Finally, after some time has elapsed, the server may send the new image source file — assuming that the request has not timed out.

In the meantime, your JavaScript on the web page is synchronous. That means, essentially, that nothing else on the page can happen until the JS runs. Even though all you're doing is touching the DOM to change the src attribute of the image tag, that takes time to happen. And that means that the mouseout event might not be caught and handled if it happens during the time that the mmouseover event code is changing the DOM (the memory structure that represents your HTML in the browser). So the image can wind up "flipping" on you and getting stuck on the mouseover source.

Using JavaScript and the mouse events for image rollovers has been considered very bad practice since around 2003 or so (when Netscape Navigator 4.whatever was finally dead and buried). We've been using CSS to handle hover state since then. That fixes the "stuck in the wrong state" problem, but it doesn't fix the latency problem by itself; you can still wind up with an element that doesn't react quickly enough to what's happening in the UI, especially on a page the user has never visited before. CSS sprites can solve that problem. That essentially puts all of the images you want to use into a single image file, then shifts that image around so that only the part you want to use is visible through the "window" that your HTML element produces. There is an excellent article/tutorial at CSS-Tricks.com: http://css-tricks.com/css-sprites/

That leaves one other major niggle: the <img> tag is for content images, not for buttons. If you want an element on the page to "do stuff", then you should be using an element that is designed to "do stuff", like a <button>, an <input> or a link (<a>). Again, the CSS-Tricks.com tutorial can walk you through part of that, and don't forget that you can always ask questions here (in the correct forum, of course) to ask what is best to use in a given circumstance, and how best to code it.

 

[tstmuge]

Alright thanks, I have a lot of learning to do, I guess not ever mouseover effects are not as simple as I thought.

 

[essellar]

Don't worry; you'll find that they're actually simpler than you thought. Simpler to write, simpler to maintain, and simpler to change when you want to change it. But relying on old information won't help a lot, and a lot of the tutorials out there are just copying old information without understanding anything.

In the case of the web, using ten-year-old information is like trying to do modern pharmaceutical chemistry with a 12th-century alchemy guidebook. There's nothing "simple" about the alchemy book, but most of it is wrong, and even if you do manage to make the Philosophers' Stone, it won't cure the common cold. There were a lot of things we had to do in Ye Olde Tymes because there was no other way to do it, or at least no other way that was safe to use across all browsers. Most of the everyday stuff has "just worked" for years now. But there is another language in the mix — trying to write a web page or application without a grasp of CSS will be an exercise in futility. And to make JavaScript really work, you need to get the heck away from the code we used to write in the Jurassic, before many of us really understood the language. (There is an old saying among programmers: "You can write FORTRAN in any language." That's what we were doing.) JavaScript is actually a marvellous little language (with, admittedly, a few "bad parts" that can safely be ignored once they're understood) that most "web developers" have never bothered learning because it "looks like" languages they're familiar with (Java, C/C++, PHP). If you have nothing to unlearn from other curly-brace-and-semicolon languages, it'll be easier for you.