Hopefully, HTML5 will ease this behavior through the placeholder attribute (currently implemented in WebKit browsers).

The label approach also has problems with positioning, since every browser has different margins/paddings for the input elements. But that can be solved with enough determination :)

Another problem is that some browsers keep the focus upon page reload/back/forward – which means that you also need to double check the hasFocus upon init to avoid changing the value of the field when the user is already about to start typing.

http://code.dominykas.com/js/hasFocus.html – focus on the input, F5 in IE. (The actual code, I think, has a bug for activeElement – can’t remember if I fixed it)

placeholder=”" is implemented in WebKit for a long time (which means Safari and Chrome); for others you’d then rely on JavaScript to create a [label] and use your CSS positioning trick (which I concur is the best solution, compared to changing the value=”" attribute’s value). To style the placeholder, you can use the ::-webkit-input-placeholder pseudo-element (input::-webkit-input-placeholder).

…and to detect whether placeholder=”" is implemented, see http://diveintohtml5.org/detect.html#input-placeholder

The only “issue” with placeholder=”" is that it isn’t meant to replace [label], which you seem do be doing here: http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute

Also, just wondering, couldn’t you position the [label] *below* the [input] and dynamically changing the [input]’s background (from transparent to white) instead of moving the [label] around? the only drawback that I can see is that as soon as you style the background you no longer have the “platform” styling (thin blue border on Windows for instance) and you have to style the border too.

It turned out, though, that I ended up spending more time dealing with the field auto fill. It turns out that domready is too early for some browsers. It is likely working in your case because YUI 3’s async module loading spans the time before the window’s onload event.

What I found was that some browsers fill the value before domready, others before window onload, and Opera (tested in 9.6, not in 10 yet) auto filled just *after* window onload. The end result was that to reliably deal with all A grade browsers’ value recall, the init code needed to be executed via a short setTimeout from a window.onload subscriber. It made me sad.

The result is here for reference: http://lucassmith.name/pub/field_default.html

This has the advantage that you can define the hint as independent of the label text.

I also tested and rejected whitespace only values, but that may be a little ott.