Gmail feature

Quote:

---

Originally Posted by Twey

It can't, really. That # will irritate users no end; it's still not what the OP actually asked for; and javascript: really shouldn't be parsed in event handlers (although it is error-corrected and ignored).

---

So should all inline event handlers always be followed by a return false?

No, only if you want to cancel the default action (in this case, flicking to the top of the page).

Quote:

---

Originally Posted by Twey

No, only if you want to cancel the default action (in this case, flicking to the top of the page).

---

Are their better alternatives to inline event handlers?

Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"

Quote:

---

Are their better alternatives to inline event handlers?

---

That's a matter of what you're doing and your personal taste. It is generally considered neater to assign the event handlers in the onload event if possible (thus separating the script from the markup as much as possible), but this isn't always a plausible option.

Quote:

---

Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"

---

Yes.

Quote:

---

Originally Posted by Twey

This one has more support for obsolete browsers.

---

To a degree, but that support may as well be provided by the server-side that should be afforded to unscriptable browsers.

Quote:

---

However, it can be condensed:

---

Indeed. There's no need to call the method (or access a collection) twice. Feature detection should also be added for the style object.

Quote:

---

that # will wreak havoc if you don't return false

---

If an empty fragment is used as the value of a href attribute, then it is doubtful that the element is really an anchor, and, in that case, a button should be considered instead. This is one of those cases.

Quote:

---

... or, even better, use javascript:void(0)

---

That is hardly better. Not only may it have negative effects in IE, but it would be considered an error (an unrecognised URI scheme) in unscriptable browsers.

Quote:

---

<input> elements must be in a form.

---

An input element that is to be submitted needs to be a descendant of a form element, but I'm sure the OP knows that already.

Quote:

---

javascript: really shouldn't be parsed in event handlers (although it is error-corrected and ignored).

---

No, it isn't. There's nothing invalid about it: it should be parsed as a label. However, it is almost always pointless. The exception is in IE where using VBScript can change the assumed scripting language, but using VBScript is rarely, if ever, necessary.

Mike

Quote:

---

Originally Posted by mwinter

Not only may it [javascript:void(0);] have negative effects in IE

---

Would you expand on that?

Quote:

---

but it would be considered an error (an unrecognised URI scheme) in unscriptable browsers.

---

I was under the impression that ignoring it was something of a convention.

Quote:

---

Originally Posted by Twey

Quote:

---

Originally Posted by mwinter

Not only may it [javascript:void(0);] have negative effects in IE

---

Would you expand on that?

---

First of all, it's the javascript pseudo-scheme itself that's at issue, not just the void(0) 'path'.

IE - quite reasonably, in my opinion - expects that when the user activates a source anchor, a navigation operation will result. As such, it stops performing certain actions in preparation for replacing the document. Examples can include a pending "meta refresh", animating GIF images, and the downloading of external resources (images, etc.). They may include other effects, such as informing plugins like Flash or Java applets that they may stop running (that's from a third-party source), and making the swapping of images (in rollovers, for example) unreliable.

The full extent of the issues may not be possible to ascertain, but it's irrelevant really: there are problems, but they are easily avoided by using the javascript pseudo-scheme for only it's original intention. That is, replacing a document with the result of evaluating an expression (and that in itself is a very rare usage).

Quote:

---

I was under the impression that ignoring it was something of a convention.

---

Some browsers with scripting disabled might, but there's no reason why an unscriptable browser should; it's a (pseudo-)scheme that the user agent doesn't know how to handle, so the user should be informed.

Mike

Interesting. Thank you.

Not that it's particularly relevant to the thread, but wouldn't showing the user an error message saying "You cannot do this because you do not have Javascript" or similar a better idea than letting the increasingly frustrated user continue clicking on a button and wondering why it isn't doing anything?