i want to be able to hide a div ten seconds after clicking on a link 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Test</title>
<style type="text/css">
html {font:81.25%/1.5 Verdana,sans-serif}
</style>
</head>
<body>
<p><a href="#" onclick="setTimeout(function () {document.getElementById('foo').style.display='none'}, 10000); return false">Hide</a>
<div id="foo">
<p>Hello, World!</p>
</div>
</body>
</html>
Thank You Very Much
Can we please move away from inline event tags?
<body>
<div id="foo">
<p>Hello, World!</p>
</div>
<script type="text/javascript" src="js/script.js"></script>
</body>
Because the link only makes sense when scripting can occur, it really shouldnât be on the page unless scripting is available. As such, the link is a good candidate for being created from the script itself.
js/script.js
var p = document.createElement('p');
p.innerHTML = '<a href="#">Hide</a>';
p.onclick = function () {
setTimeout(function () {
document.getElementById('foo').style.display='none';
}, 10000);
return false;
};
var el = document.getElementById('foo');
el.parentNode.insertBefore(p, el);
You know Iâd never use them in a real-world situation, Paul. Itâs just a quick and easy way to show the fundamental principle (use setTimeout() and set .style.display='none') without getting bogged down in the minutiae. And, of course, unobtrusive scripting goes without saying in a production environment.
Yep, I used to do that that too, then realised that people are using our posts here as an example of how JavaScript should be used.
Agreed. Thatâs always a risk.
In this case I was in a bit of a hurry (didnât even give manu0701 a proper welcome to SitePoint! 
), so I just put something together quickly so that I could go home and have a semla (a traditional Swedish dish eaten on this particular day).
And, of course, unobtrusive scripting goes without saying in a production environment.
then [I] realised that people are using our posts here as an example of how JavaScript should be used.
When I go looking for example scripts, most of the time I find stuff that belongs to 1998, which for whatever reason get very high google search results : ( The 5% of the time I find something modern, itâs over my head : )
[ot]
so I just put something together quickly so that I could go home and have a semla
In Michigan theyâre called âpastiesâ and are a staple Yooper food (lotsa Swedes and Finns up there).[/ot]
I hope my example wasnât too far over your head. Apart from placing the script in an external file, the other thing that was achieved is that non-scripting browsers wonât end up with a link on the page that wonât work for them.
I find that if you start with just the HTML, move on to the CSS, and then only after that use JavaScript to improve the user experience, that the page will work well for a majority of people and devices.
No, Paul, yours was good (itâs a simple one, thatâs why, lawlz). I havenât gotten around to setInterval yet (Iâve only heard a little bit of The Bad about itâŚ) but for instance Simon Willison and Dustin Diaz are two places I see script that I know is Good that does what I want or need⌠but I canât read at that level yet.
[ot]
Iâll get there, but itâs going unexpectedly slowly for me.[/ot]
I find that if you start with just the HTML, move on to the CSS, and then only after that use JavaScript to improve the user experience, that the page will work well for a majority of people and devices.
Something I agree with, esp as a surfer without JS and sometimes without images or CSS.
Actually, I wondered about it the first time I read it, but looking againâŚ
is it safe to do p.onclick?
I know events can bubble up but shouldnât we try to do onclick on elements who can be clicked (the anchor)? For non-mousers?
I donât think so. The bubble-up nature of things is a very compatible technique, and becomes incredibly useful when you want to catch an event from lots of elements at the same time, such as a group of links.
The onclick event on paragraphs is a fully valid event that is supported by many other elements as well.
Iâve read before that you can put onclick on many things, but if you canât focus on the element, how can you click it with a keyboard?
The click event on the link naturally bubbles up to its parent, commonly a paragraph, and on upwards until itâs either caught and cancelled, or it reaches the top, whereupon it then floats down again and can be captured at will.
Itâs incredibly complex and you can read all about it at quirksmodeâs introduction to events page, but essentially you can place an onclick event on any block element and capture the events that occur within it.
Ok, thanks for the clarification⌠I had indeed read ppkâs JS pages and that page there was too much for me at the time, esp the IE differences⌠and even then it wasnât clear what would work without mice and what wouldnât. Thanks.
If it helps to clear up some confusion, the onclick event fires both for the primary mouse click, and for keyboard activation of a link.
Since your example (and Tommyâs) has an anchor inside the clicked p, thatâs cool. Itâs just that, in general, mice can click on anything, while keyboards canât. So I thought originally that onclick events were safest on things who can receive focus, and now if I have it correctly, I really only need to make sure thereâs a focussable element in the hierarchy, because of bubbling and capturing (except in IE).
For what weâre using it for, the onclick event behaves in just the same way, regardless of whether IE or modern web browsers are being used.
In this case, âpâ is an element that you have just created dynamically. The risk of conflict with another script is, therefore, so small as to be non-existent.
That wasnât the issue, for me.
The issue was, pâs cannot be clicked normally by a keyboard. Thatâs what I had been asking.