Hadien

because "undefined" doesn't have properties. it's just simply... undefined. Go pick up any random book. a book is an "object", it has a collection of data, or pages, full of letters. You can go to page 32 and tell me the 1st letter on that page. and you can follow along cause I told you to pick up any random book. but now lets say I want you to pick up "the" book, and tell me the last letter on page 52. Well, I never told you what "the" book was so how can you possibly know that page 52 even exists and that it even has any letters on it at all? You don't know where to start because the next step of instructions can't be followed because a previous step failed; obtaining "the" book. All following steps are moot, because it all depends on that first step. In this case, page 52 is not strictly a "undefined" value, its a value that cannot be determined. You can't know if it is even undefined, if it even exists. and Javascript doesn't know how to handle that. On the other hand, "cannot access property of undefined", is far more informational in finding buggy code than just simply having it return "undefined"

I would recommend that for images that can constantly change you should use the background-image in css. Have numerous classes each with their own background-image. the benefit is that it should cache the images on the clients PC so that the image isn't "re-downloaded" everytime the user zooms in. when the page loads you can make a loop that cycles through all possible images while its still hidden so that the browser caches the images for the user. Then, when you want to zoom in, you simply just change the css class in the element and the images change instantly. You can take a look at this webpage (inside the iframe) that I've written recently where I follow this procedure. I didn't program in a preloader for the images (for certain reasons) on this page. So when you first play through the gallery, you can noticeably see the images loading. But when the galley loops back to the beginning and plays again, they update instantly. you can even spam clicks on the forward/backward button and the browser has no trouble keeping up and there's no undue stress on the server.

try and look at Justsomeguy's code step-by-step. work by each indent level of the code and ignore all other code on other indents, per step.so the 1st indent is: actLinks[i].onclick = (function(el) { ........})(actLinks[i]); Notice that he defined the entire function inside parenthesis. Doing so puts the function in a scope that no one can use after the semi-colon. This is for good reason as this "wrapper function" is never needed anywhere else and would just pollute the namespace. second benefit of wrapping it in parenthesis is that you can instantly call the function. And that is what the 2nd set of parenthesis is for. It tells the javascript interpreter to immediately run the function that was just defined with the 2nd parenthesis holding the parameter for the function (meaning that actLinks will become el). Its basically the same as this code... actLinks[i].onclick = function(el) { return function(){ showPic(el); return false; }}actLinks[i].onclick = actLinks[i].onclick(actLinks[i]); They both basically do the same thing. Yet JustsomeGuys is more straightforward and concise, and doesn't write and rewrite the onclick handler multiple times.

I think you want to use .parent(), not .parents(). I can't say for sure as I don't know what your html is. as for stopPropagation(). the click handler should pass a single argument and you'll chain stopPropagation() on that. Jquery will pass the event object by default into the handler if said handler accepts a single argument. Refer to it's documentation for an example on it's use. you also might want to look into queuing the animations. since the setTimeouts from the header can easily still be running when the user clicks something. run a search keyword for "queue" or look up some related functions like finish, and see how it meets your needs

You mean like this? <p id="lol">ahoj</p> var inner = ["ahoj","cau","hi"],int_ID; function startCycle(){ var i=0, self = this, looper = function(){ i= (++i%inner.length); self.innerHTML = inner[i]; }; int_ID = setInterval(looper,1000);} function endCycle(){ this.innerHTML = inner[0]; clearInterval(int_ID); } window.onload = function(){ var x=document.getElementById("lol"); x.onmouseover = startCycle; x.onmouseout = endCycle;};

as I said, use webstorage. its recommended over Cookies especially in HTML 5. and you don't have to worry about such headaches. Back then, Cookies weren't designed to be used the way everyone uses them today, which is why its such a pain to get everything right.

varName, which is basically the method i used in my earlier post was merely a way to show how you can use closures. funcName, won't work at all. unless it is either a helper function to something else inside the onload or the function is actually assigned while still inside the onload. but by itself it won't work You are failing to understand what is actually available before the page fully loads. Functions are available before onload runs (even before javascript actually executes any code). Javascript is available before the page even fully loads. but pretty much anything you get by using "document" and it's functions... that has to wait until after the page loads. "function" doesn't need to be inside the window.onload handler, but things like "document.getElementById()" do. both methods can work just fine, its just that you're doing one of them wrong.

You're seriously trying to re-intent the wheel. people out there have already gone through the trouble so that you can work smart, not hard. There are so many browsers that are so different there's no point for you to try and figure out how to make them all work by yourself, when someone has already made it their job to do that for you. Frameworks like jQuery exist to handle the exact requirements you're looking for. There shouldn't be any reason that you are blacklisting jQuery when you're basically trying to accomplish exactly what it was built to do: Providing cross-browser functionality while also implementing a highly simplistic interface to the programmer. You'll actually end up with less code onsite simply using jQuery (and linking to jQuery from google's servers). With jQuery you could do everything you're trying to do with just this: $(".hideShowLabel").onclick(function(){$(".hideShowButton",this).toggleClass("hide");}); And it works in pretty much every browser. AND is a simple 1-liner. You need to face it. Without jQuery, cross-browser functionality will NOT be simple. There are times that you need to realize that a requirement is simply unfeasible.

in the jsfiddle you wrote window.onload code with the "onload" option in the jsfiddle dropdown. this meant that all that javascript you've written got wrapped inside another fucntion to be called when the page loaded, and after the page load then your code gets assigned to the onload and thus doesn't even run. I always select the "No wrap - in <head>" option as thats the most intuitive for others to follow along (i don't know why that's not the default option) also "createCookie(div117006704, true, 1);" needs to have the name wrapped in quotes to work, as "createCookie('div117006704', true, 1);". theres a number of other things that you can fix but using JShint and Tidy can really clean up the code. Here is my update of the code. Also move away from using cookies and start using Webstorage instead. its alot easier to deal with when you're not having to worry about splicing out cookie arrays, it preserving datatypes, being able to store more and run faster,more secure, etc. etc.

A ) Its actually better to keep HTML and Javascript as separate as possible. Its one of those things about having lower coupling (less things you have to connect via static code). using more and more inline javascript means that if you change the function name, or you need to write a new html element, you'll be writing and changing more and more code in the end. There is no practical reason why you should write javascript inside the HTML instead in the script tag. B ) Closures implies providing implicit access of one scope while in another and that is most often accomplished by using "return". In any event you need to provide some sort of way to bridge the 2 scopes together. without using return you have to do something like in this jsfiddle, where I initialize the identifier for the function in the global space... but I wait to actually define it inside the onload. So while the function exists in the global scope, it was defined in another scope. thus it knows about and can access the "cnt" variable despite being a global function. C ) Dave's code is actually valid and it works from what I can see. you are likely misinterpreting his code. Remember to format your code. use indents. every time you make curly braces. all that extra white space may seem wasteful or may make your code appear lacking in content, but it really helps everyone in finding the problem and the extra white space actually encourages people to actually read it. I've said this before. And you can clearly see where one code block begins and another ends. Plus in the end you can use a minifier to actually compress your code into a nice, tiny, space-efficient block of algorithm (just remember to keep a human-readable copy). I believe this is likely what is confusing you here as you seem to think the onclick handler was assigned outside the onload handler, when it isn't.

let me see if I understand this correctly. You're randomly choosing a number of 0 to 99. when you find a number that is within 1~30 (check your code conditions), you want to "mark" a table cell orange while at the same time writing out the selected cell's contents. my only guess as to why you're randomly choosing from a pool of 100 numbers is so that you want only a 30% chance of a cell being selected. and this chance will diminish by 1% every time an unmarked cell is selected.theres also a good number of logic errors in your code. for example, you only need to write the name of the color function inside the setInterval, since color doesn't return any useful info for setInterval. Take a look at this jsfiddle demo see if this is along the lines of what you're looking for. I changed the numbers around a bit in the demo as 0~99 every 1000 milliseconds slows down considerably

If the 2nd Div was INSIDE the first it would work. As when you hover over the 1st then move to the second you're still inside the 1st div and the 2nd div would still show through bubbling. I recall I helped someone else on this forum do something similar and wrote up an entire jQuery UI widget nesttip. While these divs were technically children of their parents I was using positioning to move them out of the boundaries of their parents (which meant leaving the parent to the child would actually prompt the onmouseout) and then used a setTimeout in the onmouseout that was to be canceled if the child was entered by a given timeframe. I've never used the <ol>/<ul> before for this but I have seen it used effectively.

Nearly all of the syntax inside a for loop is optional. Even the curly braces are optional, and only necessary if the looping code is of multiple lines. this is fully explained on sites that go into detail of the language itself, like MDN. See in the link when it mentions the for syntax that there are square braces, that generally means (when explaining syntax) that this secton of code is optional. the semi-colons, the "for" reserved word, and the parenthesis are all required however. You can even go so far as an empty code block,though there are few reasons to do that. That being said never create infinite for loops inside javascript, especially (and most annoyingly) with alerts. Javascript wasn't designed for you to do polling via for loops and there are far better alternatives to this in javascript. And if you do this it will only succeed at bringing the computer running the code to a screeching halt. infinite loops with alerts are even worse as the common end-user at least has only two ways of stopping the pop ups. One is to bring up their task manager and forcibly end their browser's process. the other is to restart their PC, neither gives you a happy user. Many a modern browser has some safeguards to prevent this now, but all the same never do this.

When you typed list:{...} and populated the lines inside those curly braces with statements, not properties you basically created a "control structure" and not an "object" and then called it "list". When the interpreter came across "break list;" it told itself that it will not even look at the rest of the code inside the "list" control structure that you've created. so it instantly jumped to where the closing curly brace was and just continued from there. there is no real benefit to creating your own control structure like this. It is valid code and works like a charm... but it merely makes your code obfuscated, ambiguous, confusing. It is better to simply use functions instead as then you have more control of the scope and it is far easier to re-execute the code this way. Plus far more people will be able to follow along. It is of no use to anyone if you intentionally make obfuscated code and then ask help from others to understanding how or why it works, at worse you would only be wasting other's time. If you ever intend to work in a collaboration with other people you need to make your code easy to digest because if an event comes along that a problem arises, and you could not be contacted, AND people could not fix the problem because they could not understand your code, then you or even the entire project at hand could be canned. Don't go looking for trouble (as in coding complexly) , especially at the expense of others. Do so only if really necessary (and fully document why you did it and how). Simplicity is a virtue in programming, and the world just turns a lot better when more people can follow along. The same can be said about properly formatting your code. don't write comment on the same line as functioning code. And properly indent and space out your code. The best of us can and will forget this from time to time, but problems can be solved much sooner if people who are debugging aren't having so much trouble just reading the code. Back to the point, labels exist in javascript as an option. They have their uses as I mentioned previously. But more often than not, its better to try and avoid using them when possible as usually there are better ways of doing something without scratching people's heads.

"list:" is whats called a label. its a reference point for various control structures (mostly loops) when they come across a break or continue. say that you have 2 nested loops and you come to a condition inside the inner loop where you want to skip the rest of the current iteration of the outer loop. you can say "continue" but without a label javascript will assume that you want to skip the rest of the iteration of the INNER loop and not the outer loop; Actually, simply using break in this case will work, but only if there is no code after the inside loop. I could have written the logic in this example better if I were to actually use this code, but this should be good enough to illustrate how it's used outer:for(var tens = 0, text; tens<10;tens++,console.log(text)){ text=""; inner: for(var ones = 0; ones< 10;ones++){ if((tens*10+ones)%33===0) continue outer; text += (""+tens+ones+" "); } } I labeled (a.k.a. named) the outside loop as "outer" so whenever I use the break or continue word and the "outer" label javascript will know that I'm referring to that loop and not the wrong one. I also labeled the inside loop, but only for completeness, I never use the label. what should happen here is that the two loops should count through 100 numbers (00 to 99), with each tens on a separate line. and when it hits a number divisible by 33 it skips the rest of the numbers one the line and works on the next group of tens. so the console should print out 10 11 12 13 14 15 16 17 18 1920 21 22 23 24 25 26 27 28 2930 31 3240 41 42 43 44 45 46 47 48 4950 51 52 53 54 55 56 57 58 5960 61 62 63 64 6570 71 72 73 74 75 76 77 78 7980 81 82 83 84 85 86 87 88 8990 91 92 93 94 95 96 97 98 the 1st line is completely skipped because the loop starts at zero and zero is fully divisible by 33 (0/33 = 0)the 30's stop at 32 since 33 is divisible and so the rest of the line is skippedsame for the 60's and 66. and the 90's and 99.As said before I could have simply used "break;" instead of "continue outer;" since in this example I have no code after the inner loop thus both will actually perform the same thing. however if I place the console.log() after the inner loop instead and used break.... outer:for(var tens = 0, text; tens<10;tens++){ text=""; inner: for(var ones = 0; ones< 10;ones++){ if((tens*10+ones)%33===0) break; text += (""+tens+ones+" "); } console.log(text) } this should print the same output, but now code after the inner loop is also executed. when javascript see the "break;" and see no label with it, it instanty assumes the break is for the closest looping structure. If instead you said "break outer;" NOTHING will print as 00 is the very 1st number which is also divisible by 33 and thus breaks out of the entire operation

remember. the '=' sign is an assignment operator. you need to use it if you want to assign a value or actually change something. Saying... element.nextSibling; ...only tells you about the next sibling of the element (or returns null if the element WAS the last sibling). You need to write element = element.nextSibling; to assign the current element to it's next sibling. Also. You should consider another possible terminator if there is no div at all in the current sibling collection. If that loop reaches the last sibling and doesn't find a 'div', it's just gonna throw an error since element will become null, and won't understand how to get the property "nextSibling" from null. In any case, the way I would write a toggle script would be in one of 2 ways, assuming I'm writing without jQuery. Depending on how involved I want it to be. and how related they would be. A: write a stand-alone function that has a id reference to the element to be hidden. This approach is simple, straightforward, and pretty easy to follow. and no need to traverse the DOM function toggle(tEle){ tEle = document.getElementById(tEle); if(tEle.style.display == "none"){ tEle.style.display == "block"; this.innerHTML = "hide" }else{ tEle.style.display == "none"; this.innerHTML= "show" } } <!--html example--> <button onclick="toggle(this,'divToggle1')">hide</button> <div id="divToggle1"><p>this is the a section of hidable content</p> </div> B: create an object on initialization that will 1st identify involved elements and then delegate control of the toggled objects like in this jsfiddle. I prefer this approach more as the javascript isn't written inline inside the html, at all. Also I like to avoid recalling document functions like getElementById inside event handlers. Personal preference of mine that when an event is running the function already knows what it needs to deal with before hand. I prefer that a piece of code only needs to do it once if it can (I haven't tested this cross-browser, so might not work in IE 6, but I would likely only have to work on the for loop at the bottom) both options benefit from the fact that the linked elements do not need to know their relationship to each other. so they don't even have to be siblings (as shown for example in the jsfiddle). Also I would look into some posted polyfills for addeventslisteners on the web. if you really want cross browser support in your scripts, polyfills are simple written scripts that provide support for browsers that would in one case or another wouldn't have the function. For example addEventListener is whats used in IE 9+ while earlier versions used attachEvent. As well as other browsers prefering other methods to connect event handlers to their elements. You can grab a polyfill for addEventListener so that script that you write will work with using that function regardless of the browser. Even better I would recommend looking into using javascript libraries like jQuery or dojo. This way you can have the library worry about making sure your script will work in all viable browsers, while you worry about the site itself.

I looked at your jquery code, and a lot of it is repetitive. you don't need to define a clickToggle function. and you don't need to individually map an onclick to each and every a tag like you did. You've created far too many unique possible states in that code that I didn't even try to bother with what exactly is going wrong. I simply rewrote it using far less code. take a look at this update the simple thing to do is to first run the "deselect" animation on everything (even if they are already deselected, even on the element that you DID select). and then go back and run the "select" animation on the clicked one. regardless of the combination of clicks, the code just has 2 simple rules to follow then. I changed the settings too by setting queue to false, so that all animations (both deselect and select) run at the same time.

its because myD.style.backgroundColor == "", not "coral". Console.dir is your friend Javascript doesn't automatically populate the current computed CSS for any element, unless it made the change in the 1st place. You'd have to use window.getComputedStyle(myD) for it to load the current backgroundColor from that internal CSS. Even then it wouldn't always say "coral". Depending on the Browser it may decide to convert it to an rgb function like "rgb(255, 127, 80)". Often its much less of a headache to simply make an extra CSS class and use javascript to change the classes an element has, rather than manually changing every single style in each element. its also much more cross-browser friendly.

If you want to make image rollovers, I'd advise not to use javascript, or img tags for that matter. Just HTML Div and Css:hover backgrounds like in this example. When you use javascript the browser has to constantly reload both pictures every single time. But when using CSS, both images get cached so the server only needs to send each image once and doesn't have to constantly use up more and more bandwidth. it also runs faster client-side and theres far less code to worry about.

Pay attention to the indents here... they help show the different scopes: /** Global Scope. everything defined at this indent is accessible here and higher indents**/ var object = { /** Object Scope. can access anything inside this scope and lower scopes, like Global **/ } function myFunction(){ /** function Scope. can access lower indent scopes and it's own scope **/ var myClosure = { /** Another object Scope... but how I'll use it makes it a closure scope **/ } return myClosure; // returns a closure scope } (function(){ /** anonymous function scope not visible on the global scope. code written in these parenths are worked on but varibles aren't automatically set to any other scope unless specifically told to do so **/ })() in my example Closure Scopes, when returned, will have direct access to itself and global scopes. and yet it can also indirectly access the function scope, but only if a function was defined inside that closure scope. You can use this to your advantage by writing private variables/functions inside the function scope, and public variables/functions in the closure scope. Anonymous scopes are useful when you want to run a function only once and immediately when its defined. The function isn't registered anywhere so no one can recall it. the "this" keyword isn't defined in the global scope when an event runs, but in that very, very, local scope between the quotes in the html's onclick. So, as Ingolme says, you need to pass "this" to another scope via a function argument or setting "this" to a pre-defined global variable

When an event triggers, javascript automatically defines 2 variables in the scope (between the quotes in the HTML attribute) this: refers the the DOMelement that the event has fired from event: connects to the event object that is current running The event object has all sorts of info relevant the the event currently being fired. for example it has info on the exact coordinates that the mouse was when you fire the onclick event. In the onkeypress, onkeydown, and onkeyup events, it would have the info describing exactly which keys were pressed. event.target basically refers the the element that fired the event, just like the this reference. In most cases this and event.target will both point to the exact same thing. <!DOCTYPE html><html><head><script type="text/javascript">function pass(val){ alert("I have been called via a function.n It was a "+ val.tagName + " that triggered this function."); alert("oh and it's id was:"+val.id);}</script ></head><body><button id="myButton" onclick="alert(this.id)">Click me!</button><!-- should make a popup saying "myButton"--><button id="middleman" onclick="alert(event.target.id)">Me too!</button><!-- should make a popup saying "middleman"--><button id="pattycake" onclick="pass(this)">Me three!</button><!-- should make a couple popups with some info on this button However, this popup is delegated to another function--> </body></html> Here is an example of me doing the same thing 3 different ways. Notice the id I've set for each button... as I refer to each one inside the alerts. In my function the argument I use is val. I simply decided to use val instead of e just on a whim. Inside my pass function I say that the this keyword which was passed into it in the 3rd button shall now be known as val. And that's all that is going on in your myFunction. Someone is simply calling the event object just e while it is being used inside that function. e is commonly used to refer to events in many scripts, even though it is not a reserved word. I should say that its also used a lot in exception handling with try/catch blocks. In which case, e would refer to the passed exception.

http://jsfiddle.net/UBdJU/1/ I added in a background and commented the code. And I wrapped a few lines of code into functions to reduce on the code duplication. I started with the background, then the "reflection" and finally the actual shape. If you don't really want the background you can easily remove it you were close to the answer, you simply needed to change the fill style to a gradient when rendering the text, instead of pure black. using transparency colors forces the stroke to bleed through. I don't know of way to prevent the bleeding while using transparency. Best guess is to fool around with: ctx.globalCompositeOperation

I've done some work on this... http://jsfiddle.net/cAtFu/9/ I believe this is what you are looking for. I'm not 100% sure either as you aren't completely clear, but I think I nailed it. I changed a few things here: 1) removed the iframes, we don't need to be working with them to understand this exercise, and it really bottlenecks the loading times on my end. 2) changed from using visibility to using display, I think this is why you began to mess with positions when you didn't need to 3) you don't need to use anchor tag's href attribute to run javascript, its not 1997 and no one uses Netscape anymore. Present-day browsers are far more flexible so you can have pretty much any element run javascript via specific events. 4) cleaned up the css to help illustrate which divs are which.

If you have a Link I would check it out, but I'm not seeing the whole picture here so there's not much I can go on with just what you presented. I've already tested the little snippets you had, and looked up the Slidedown documentation. but in my tests Slidedown is behaving as expected, the cause to your problem has to do with something you haven't posted. That css file doesn't help me much cause I still don't know which css the parent element is using. I was asking because I have a hypothesis that the parent element is forcing child elements to align to the bottom and the animation of slidedown could have given the illusion that everything was sliding up.

I don't see anything wrong with what you've posted, must be from something else in the file. What is the CSS of the parent element?