Jump to content

Html Elements That Require Return Values From Their Action Fields


nachumk
 Share

Recommended Posts

I am trying to learn HTML/PHP/JS. I have been reading through documentation and one thing which I can't find documented in the standard is which HTML elements require or use the return value from their action fields. I understand that onSubmit won't submit a form if the return value is false (which is used when submitting the form through javascript). Where can I find this behavior documented in the W3 standards, and of course documenting all other elements behavior in regards to return values?I found some pages that list this information but I would like to see the official documentation to be sure that I'm programming it correctly.Thank you,Nachum Kanovsky

Edited by nachumk
Link to comment
Share on other sites

It's not really an HTML thing. The values of event attributes fall under the Javascript category.If a user has Javascript disabled, adding onsubmit="return false" will not prevent the form from being sent.

Link to comment
Share on other sites

One of the difficulties here is that the thing we casually call JavaScript is a combination of things.1. ECMAScript, which is the core of JavaScript and has very little to do with the Web. For this reason, it has implementations for non-web purposes also.2. HTML DOM Level 0 methods, which were developed as an interface to HTML by various vendors before the language was standardized. Implementation of these is pretty constant, but there can be variations, especially between IE and everyone else. The non-standard bits of this tend to be documented by the individual browser-makers only. For example, IE has a document.all property that's been around forever and which it continues to support. It's not part of anyone's standard but their own, and no one else uses it.3. The modern DOM API. That is, methods by which JavaScript interacts with (X)HTML documents. getElementById() is perhaps the most familiar of these. This stuff can be found in the W3C HTML specifications, and there will be some big changes whenever HTML 5 becomes the standard. The number of possible form elements will about double, for example, and the events they register will include a bunch of new stuff also.I am not aware of a single online repository for all this information, but you might come closest at the Mozilla site: https://developer.mozilla.org/en/JavaScript. Obviously, the W3C site has the HTML specs, which include the DOM interface methods.After that, a bound version of The JavaScript Bible might be your most thorough reference.One of the reasons for hanging around a board like this one is that the best repository for practical JavaScript knowledge is the collective mind-space of developers. You can learn a lot more being an active participant here for a year or so than you can by Googling yourself silly for the same amount of time. (On the other hand, reading about a concept here first and then Googling it is an excellent habit.) Writing code is a craft and art like any other. Dancers and stone masons learn more from each other than they do from books. The fact that code CAN be referenced in text doesn't mean that reading references is the best or only way to learn about it.Just to put that concept into perspective, know that I am a tenured college professor with an advanced degree. Book learning is how I got where I am professionally. But learning from my peers in a less formal context has taught me a lot more. A LOT more.And then there's plain old hands-on experimentation . . . It's hard to beat that.

Edited by Deirdre's Dad
Link to comment
Share on other sites

Thank you all for your responses. I guess there's no good place to look to find the information I'm seeking.On the same topic - you say that returning false stops an event from being passed on... Where is there a description of which events "pass on" and which don't? I can make assumptions, but of course I'd like to be sure. For example - onsubmit gets passed on and can therefore be disabled, but what about onclick, onkeyup, onfocus, and the rest of them? On which elements? Should I pass true for all elements just to be sure? Compatibility??Also why do you say that this is part of the javascript standard? Is it javascript that's letting onsubmit continue?? I would assume that this is wholly an HTML decision.

Link to comment
Share on other sites

It's not HTML exactly. HTML is just a standard for marking up pages. Browsers use HTML (and other things) to create a document object, which is conceptually different from the markup that creates it.It is the document object model (DOM) that triggers and responds to events. Unless the developer has other plans, the DOM will register, process, or ignore events as it sees fit. But the DOM has methods that allow JavaScript (and potentially any other scripting language) to interact with the DOM.So JavaScript and the DOM working together give you the OPTION of capturing events and then releasing or canceling them. You only need to be concerned with events that you are deliberately capturing. All other events can be ignored.Unlike most functions, the default return value for an event handler is true. (At least, the DOM responds as if that were the case.) So if you grab an event and don't return anything at all, the document will do whatever processing you asked it to do, and then the DOM will handle the event as it normally would if you had not captured it. If you capture a keydown or keypress, you could animate something, remove an element from the DOM, etc., but only if you return false will the event's propagation be canceled. For this reason, I like to write handlers that explicitly return true if that is the behavior I expect. The code is easier to understand. But it's not required. There are three reasons for this: (1) DOM 0 event handlers were typically written as short snippets of inline code (in the element tag), life was simpler in 1994, and no one expected designers to understand "sophisticated" concepts like return values, so (2) it's legacy behavior for backward compatibility, and (3) if the handling function throws an error and stops, the event won't be lost: the document will handle the event itself, which is more graceful behavior.Let me put that as clearly as possible. The following will happen when you terminate an event handler according to the following:return false ==> cancels the eventreturn true ==> releases the eventno return value ==> releases the eventThis is true of all events and event handlers.

Edited by Deirdre's Dad
Link to comment
Share on other sites

I got that returning false releases the event, what I'm still unclear of is how could that affect an event like onkeyup? Is there another level of event propagation possible after the running of javascript that a false return value could stop from happening?Let me put it another way:<input type="text", name="test", onkeyup="runFunc(); return false;"/>What could be the effect of return false vs return true for such an element?

Link to comment
Share on other sites

Did you try it? I did. As I expected, there was no noticeable effect. But you really could have guessed that, since a normal keyup has no noticeable effect anyway. I'm struggling to imagine a situation where something different might happen, and I'm unable to.You might think a mouseup would be similar, but that's not true. Mouseups are typically used to identify mouse location in drag-and-drop behavior. Internally, the system uses them to see if you decided in mid-click not to click something after all.I don't think you can cancel an onload event. As near as I can figure, when a thing loads, it's loaded. The "event" is more like a notification. Likewise an unload event. You get an opportunity to respond, but it's the user's choice to close a window, and you cannot stop that (except maybe by hanging the script with an infinite loop, but even that will get caught.) Same thing seems to be true with an onchange event. You can't undo the change by returning false. (Whereas you could prevent the change from happening by capturing a click or keydown.)Off the top of my head, it seems that events can be classified as (1) primary responses to user behavior (click, keydown/press, submit, maybe 1-2 others) and (2) secondary events, which could be called notification events: a thing happened, you can respond to it, but you can't undo it.:) I never thought about this before, except intuitively. Maybe someone has it written up somewhere, but I don't remember seeing it.

Edited by Deirdre's Dad
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...