I am looking to collect email addresses with my site. On my input elements, when the user clicks on it, I want to change the value attribute to blank (make the "your e-mail" disappear when the user clicks on the input element). Is JavaScript used for this?

system
—
2011-10-22T21:44:24Z —
#2

You can put an onclick event handler on the element which is called when the user clicks on the element. The event handler then simply changes the value attribute of the element to null or an empty string. This can all be done using javascript.

etidd
—
2011-10-22T22:36:40Z —
#3

Hey, thanks for the post! One more question. Would you recommend putting the script in a separate file, or should I just put it at the bottom of my HTML file?

system
—
2011-10-23T01:34:41Z —
#4

it depends on how much other javascript you have for the page.

Paul_Wilkins
—
2011-10-23T01:38:49Z —
#5

etidd said:

Hey, thanks for the post! One more question. Would you recommend putting the script in a separate file, or should I just put it at the bottom of my HTML file?

You should do both.

Put the script in a separate file so that it can be easily edited by you, as well as being easily cached by the browser.Refer to that script file from the end of your body, just before the </body> tag, so that your script can easily work with content on your page before it has finished loading.

etidd
—
2011-10-23T03:15:34Z —
#6

Good suggestion, Paul. I know that I'm gonna be using JS for a little bit more than just this input form function, so I need to start a separate file.

I've been searching the internet for a while now for help on making the correct statement that will change the value of the value attribute. This is the closest guess I have, and it doesn't work.

name = oForm.elements["name"].value;

where

oForm = document.forms[index];

I don't even understand what the 2nd statement means, mainly because of that parameter, [index].What JS method should I use?& Where's the JS api library?

felgall
—
2011-10-23T03:20:56Z —
#7

Give the field an id and reference it using document.getElementById - you need an id to attach the label anyway. The name is for use on the server after the form is submitted.

Paul_Wilkins
—
2011-10-23T03:36:25Z —
#8

etidd said:

This is the closest guess I have, and it doesn't work.

`

name = oForm.elements["name"].value;

`

where

`

oForm = document.forms[index];

`

I don't even understand what the 2nd statement means, mainly because of that parameter, [index].What JS method should I use?

The one that people seem to prefer starting off with is jQuery, but it's not required. If you are learning JavaScript, it's better if you learn what JavaScript can do first, before doing anything with other API's.

etidd
—
2011-10-24T03:36:50Z —
#9

I think I have a pretty good image of what JavaScript can do now. It's THE tool for actively updating HTML/CSS code in real-time for a web visitor amongst other things (animation, website layout, etc.).

Although, today if it's any form more complex than a search form (who only has a single input + submit), I have labels built in.

Javascript, if enabled, would then move the labels offscreen and adds in the placeholder text. This way, users without JS get the slightly-ugly (in some designers' view) page but fully functional/accessible.

Ralph's is good in that it's generic: it loops through all the form (text) inputs. However it requires that the placeholder text sits in the HTML. This means users without JS get text they have to remove first. So you could use the option I have above where instead of actually setting values to empty string, you could just have defaultValue highlighted. Users can then remove everything with a single backspace (sometimes some browsers will do this automatically on focus but not all, not all the time).

BTW there's also an HTML5 attribute called placeholder. It doesn't work in browsers who don't know it, is recommended NOT to replace labels (labels really should always be in the markup, with the sometimes exception of simple search fields), and it's generally not styleable without loads of JS. But something to be aware of for the future.

ralphm
—
2011-10-24T09:53:31Z —
#13

Stomme_poes said:

Ralph's is good in that it's generic: it loops through all the form (text) inputs. However it requires that the placeholder text sits in the HTML.

Yes, that's the one thing I don't like about it. It's from Jeremy Keith's Dom Scripting book, BTW. When I get good enough at JS, my aim is to rewrite it so that JS puts the values in and takes them out again.

Yes, that's the one thing I don't like about it. It's from Jeremy Keith's Dom Scripting book, BTW. When I get good enough at JS, my aim is to rewrite it so that JS puts the values in and takes them out again.

You know, it is becoming more and more appropriate these days to use HTML5 techniques, so that javascript-based solutions don't need to be used at all.

The HTML5 technique being to use a placeholder attribute, and potentially a required attribute to indicate that the field must be filled in before submitting.

You know, it is becoming more and more appropriate these days to use HTML5 techniques

Yes, it will be nice when that is widely supported.

Paul_Wilkins
—
2011-10-24T10:27:48Z —
#17

ralph_m said:

Yes, it will be nice when that is widely supported.

Yes, you would want a [polyfill of some kind, perhaps [url="https://github.com/dciccale/placeholder-enhanced"]polyfill enhanced for it to work in Internet Explorer, which results in [url="http://caniuse.com/#search=placeholder"]pretty much all web browsers supporting placeholder](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills) except for a few mobile browsers, Opera Mini and Android.

Yep, although don't they just depend of JS anyway? Makes me kind of suspicious, but I haven't gotten my head around them yet.

Paul_Wilkins
—
2011-10-24T12:33:29Z —
#19

ralph_m said:

Yep, although don't they just depend of JS anyway? Makes me kind of suspicious, but I haven't gotten my head around them yet.

That's the current way of things, until a few years have passed, the HTML5 standard goes from Draft to a Specification, and certain web browsers have achieved better support for non-scripted techniques.

There are a couple of different paths that we can take in the upcoming years.

Remain with the HTML4/XHTML techniques

Implement HTML5 as and where practical, with the support of JavaScript for less capable web browsers

Exclusively use HTML5 exclusively to the detriment of less capable web browsers.

Currently, I find myself in the middle ground there.

ralphm
—
2011-10-24T14:19:20Z —
#20

I'm happy to use JS fallbacks for non-critical stuff, but am not convinced about it for essential / structural elements. Seems premature to me.