A life in the day

3/31/2007

Overlabel with JQuery

Filed under:

Programming

— Scott Sauyet @ 2:24 pm

I’ve been playing with JQuery lately, and when I found a need to use the wonderful little accessible compact form script by Mike Brittain, I thought I’d try to duplicate it with JQuery’s simpler syntax. This is my first attempt at anything close to a JQuery plugin. It works for me, as you can see on the test page.

Here’s the code I wrote (Update: There is an updated version in the comments.)

jQuery.fn.overlabel = function() {
    this.each(function(index) {
        var label = $(this); var field;
        var id = this.htmlFor || label.attr('for');
        if (id && (field = document.getElementById(id))) {
            var control = $(field);
            label.addClass("overlabel-apply");
            if (field.value !== '') {
                label.css("text-indent", "-1000px");
            }
            control.focus(function () {label.css("text-indent", "-1000px");}).blur(function () {
                if (this.value === '') {
                    label.css("text-indent", "0px");
                }
            });
            label.click(function() {
                var label = $(this); var field;
                var id = this.htmlFor || label.attr('for');
                if (id && (field = document.getElementById(id))) {
                    field.focus();
                }
            });
        }
    });
};

And it would be called like this:

1
2
3

$(document).ready(function() {
    $("label.overlabel").overlabel();
});

I’m wondering whether there are some simplifications to this that a more experienced JQuery user could explain, though. I feel as though it’s still too wordy, and that it spends too much time switching between the DOM elements and the JQuery ones.

In any case, if you are interested in this (public domain) plugin, you can grab a zip here, or just go straight to the Javascript source.

86 Responses to “Overlabel with JQuery”

Abba Says:
April 1st, 2007 at 4:12 pm
Nice work. Just so you know the comment box on your site breaks the faux columns in ff 1.5 at least.
Scott Sauyet Says:
April 3rd, 2007 at 10:43 am
Oops. Just upgraded to Wordpress 2 and didn’t even notice that the stylesheet is no longer working. Ugggh.

Thanks. Gotta find a few minutes…
Jon Lesser Says:
May 9th, 2007 at 3:50 am
This is just what I was looking for. Thanks!
Scott Sauyet Says:
May 9th, 2007 at 7:59 am
Glad you could use it. If you grab the code from the demo page rather than what’s displayed in the post you will get something that plays better with non-JQuery libraries. (”$” is not used in the global scope.)

Dave Methvin Says:
July 4th, 2007 at 9:22 am

Hey Scott, here’s a thought on another way to write it. I can’t say it would be faster, but it gets you thinking about how jQuery chaining can be your friend when it comes to brevity. (Wordpress may mangle this…)

(function($){
$.fn.overlabel = function() {
    this.each(function(){
        var label = $(this);
	$("#"+(this.htmlFor || label.attr('for') || "ID-NOT-FOUND"))
		.focus(function(){ label.css("text-indent", "-1000px"); })
		.blur(function(){ this.value || label.css("text-indent", "0px"); })
		.trigger("focus").trigger("blur")
		.length && 
			label.addClass("overlabel-apply");
    });
}
})(jQuery);

Scott Sauyet Says:
July 5th, 2007 at 7:50 am
Yes, that’s exactly the sort of clean-up I expected more experienced JQuery users could supply. I haven’t tested it yet, but it looks very succinct and will add at least one technique to my personal Javascript repertoire.

I have one question, though. Why this bit:
9 10
.length && label.addClass("overlabel-apply");
instead of just calling addClass() directly. Is there some performance hit?

Thanks,

— Scott
Dave Methvin Says:
July 5th, 2007 at 12:17 pm
I assumed you only wanted the overlabel-apply class on labels that had
matching form elements, so I had the selector default to #ID-NOT-FOUND if
the FOR attribute wasn’t present or the ID mentioned in it didn’t exist. The
selector won’t select anything for that case, the .length will be 0 and the
chained methods (focus, blur, triggger) won’t apply to any elements. By
making the addClass dependent on the length being non-zero (it will either
be 0 or 1 since we’re selecting an ID) the class is only added if there was
an element matching the ID in the FOR attribute.

One other thing I should have mentioned is that the trigger of focus/blur on
each element might interact with fancy form handling such as validators, so
you’d probably want to do overlabel early in your .ready() handler before
initializing those kind of functions.

Thanks for translating this idea to jQuery by the way, I found it in a
search because I needed this functionality.
Scott Sauyet Says:
July 5th, 2007 at 12:21 pm
Oh of course, I see. It’s exactly the same technique that I hadn’t used
before being applied again, but I missed it this time. The technique
I’ve never used is simply to replace a simple “if” clause with an “||”,
e.g. replacing this:

if (this.value === ”) {
label.css(”text-indent”, “0px”);
}

with

this.value || label.css(”text-indent”, “0px”);

One other thing I should have mentioned is that the trigger of focus/blur on each element might interact with fancy form handling such as validators, so you’d probably want to do overlabel early in your .ready() handler before initializing those kind of functions.

I haven’t used it in that environment yet, but will probably do so this
month, so thanks for the heads-up.

Thanks for translating this idea to jQuery by the way, I found it in a search because I needed this functionality.

The translation was pretty easy. But when I went searching, I couldn’t
find anything. When I posted this entry, several people pointed me to
other implementations of similar ideas. Google really is only so much
help…

Thanks again.
Dave Methvin Says:
July 5th, 2007 at 12:22 pm
I love Javascript’s || and && operators. First of all, they are
short-circuit so that they stop as soon as they get a non-false answer, and
they return the actual value rather than a simple true/false the way C++
does for example.

For the purposes of determining truth, a false value is (undefined), (NaN),
boolean false, numeric 0, or the empty string. No conversion is done on the
value before checking, so “false” or “0″ do not evaluate to false because
they are non-empty strings.

That rewrite above takes advantage of both of those things. At the point
where it’s run, we know it’s working with a form element such as a text box.
That means this.value will always be a string, so it will only evaluate to
false if the string is empty. That means it has to evaluate the label.css()
to see if the entire statement is true or false, which is just what we want
for the case where the string is empty.
Scott Sauyet Says:
July 5th, 2007 at 12:23 pm
Fans of functional languages might run screaming at this use of side effects in a conjunction, but it makes a great deal of sense for shortening up code.

I use the short-circuited nature of || and && all the time, but I’m coming from a Java background, and often forget the broader nature of true/false in JS. It’s a very nice technique.
Zach Leatherman Says:
July 26th, 2007 at 11:18 am
Great plugin!

You might want to add a textarea to your examples just to comfort the end user that it does indeed work with textareas as well.

I made a small modification to this script to make it work with JSF-compatible id’s, a la formId:formFieldId, which is supported using the escaping features built into jQuery 1.1.3.

Use
var id = this.htmlFor || label.attr(’for’) || “ID-NOT-FOUND”;
$(”#”+id.replace(/\:/,’\\:’))

instead of

$(”#”+(this.htmlFor || label.attr(’for’) || “ID-NOT-FOUND”))

Hope that helps someone.
ZAP Says:
August 26th, 2007 at 9:05 pm
Very nice script! Simple, useful, and efficient. Thanks for sharing!

Question: Is there an easy way to remove the overlabels of specific form fields? I have a form with billing and shipping address sections and a “Ship to Billing” checkbox that calls a JavaScript function that copies the billing info to the shipping fields and disables those fields. This doesn’t cause the overlabels to register that there is now content in each of those fields, however, so the label text stays there and makes the form data very hard to read.
Scott Sauyet Says:
August 27th, 2007 at 7:52 am
Very nice script! Simple, useful, and efficient. Thanks for sharing!

Thanks. I haven’t thought much about this since I wrote it, and the variation proposed by another poster might be a better bet.

Question: Is there an easy way to remove the overlabels of specific form fields?

This wasn’t built to be removed, but if your Javascript function can be easily altered then you can simply call focus() then blur() on the form field. In the demo, for instance, you might do
1
$("#username-field").val("Fred").focus().blur();
That should work. If you can’t change the JS function, let me know and we’ll see something can be added…
ZAP Says:
August 28th, 2007 at 3:37 pm
The original version you created is working fine for me, so I’m happy with that. And your suggestion to focus and blur each field worked like a charm. I was even able to chain disabling of each form field after changing the value and removing the overlabel like so: $(”#s1_Name”).val(frm.Name.value).focus().blur().attr(”disabled”,”disabled”);
Scott Sauyet Says:
August 28th, 2007 at 3:59 pm
Great! I’m glad this worked for you.

Please let me know if you run into any problems with it.
Scott Sauyet Says:
September 6th, 2007 at 8:38 am
Thanks. I can’t really claim much credit, just the conversion of someone else’s technique to jQuery. But I’m glad you like it.

Aristotle Pagaltzis Says:
September 19th, 2007 at 4:44 am

Thanks for providing a model to work from. Here’s my version:

( function($) {
    $.fn.overlabel = function() {
        this.filter('label[for]').each( function() {
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if(!field) return;
 
            label.addClass('overlabel-apply');
 
            var hide_label = function() { label.css('text-indent', '-1000px') };
            var show_label = function() { this.value || label.css('text-indent', '0px') };
 
            $( field ).focus( hide_label ).blur( show_label ).each( show_label );
 
            return;
        } );
    };
} )(jQuery);

In contrast to Dave Methvin’s variant, this code works without falling back on made-up bogus ID values and is, I believe, much more readable.

The major win was when it occurred to me that I could remove the duplication between conditionally showing the label right now and conditionally showing the label in the blur handler by using each, because each invokes its function with field assigned to this, thus making the same code reusable for both cases. (Assigning the other closure to hide_label is not necessary, but makes the whole thing read more nicely and look more symmetric.)

Another minor improvement is the use of filter to avoid manual checks for whether there is a for attribute on the label.

This is tested and works for me.

My clean-ups don’t have much to do with jQuery-specific experience, btw – I don’t even have a whole lot of it. I just obsessed over each and every line of code until the last trace of loathsome complexity was gone.

Scott Sauyet Says:
September 19th, 2007 at 7:53 am
Perfect!

This was written because I needed it for a project and didn’t want the overhead of the original technique when I was using JQuery to otherwise simplify my Javascript. It was a naive port of the original, and I was never happy with the code, but I haven’t gone back to clean it up. Although I like Dave Methvin’s shortening of the code, and I learned something from it, I haven’t adopted it in my own use, because it still came across as mysterious.

Yours is very clean, and I’m very impressed. I think I’ll adopt it for my own use. Is it okay if I post it as the official plug-in version?

Thanks for sharing it.
Aristotle Pagaltzis Says:
September 19th, 2007 at 10:42 am
Yeah, “mysterious” is the first thing I thought about his code too… I just didn’t want to be that forward, heh.

It’s fine to post mine as the official version – I’d just ask to be credited, since this is essentially a rewrite. But I wouldn’t have gotten to the same place without working off your version, so I’m not going to claim it’s all mine. I dunno – choose a way to handle this that you feel is fair.

Btw, here’s a jQuery experience issue: turns out that this:
1 2 3 4 5
( function($) { $.fn.overlabel = function() { // ... }; } )(jQuery);
… is better written as this:
1 2 3 4 5
jQuery.fn.extend( { overlabel: function() { // ... } } );
Scott Sauyet Says:
September 19th, 2007 at 11:36 am
It’s fine to post mine as the official version – I’d just ask to be credited, since this is essentially a rewrite.

I certainly wouldn’t do it without giving full credit. The only question to me was whether this excellent rewrite should simply replace my plug-in or whether you would prefer to post an entirely separate one. Either is fine, but I think it’s worth having this version listed on the plug-in page.

So what is the advantage of the “.extend()” version above?
Aristotle Pagaltzis Says:
September 20th, 2007 at 1:06 am
I would post the rewrite separately, to preserve the context for the comments on this post, and then point the plug-in page to the new post, so people looking for such a plug-in aren’t given a choice of two versions when one of them is universally preferable.

As forextend, mostly it’s just the idiomatic way for jQuery plugins. It does have a small objective advantage in that it’s more declarative. But it forgot that I have $( this ) and $( field ) in the function, and these would have to be written as jQuery( ... ) instead, so I wouldn’t change the style after all.
Scott Sauyet Says:
September 20th, 2007 at 7:45 am
I guess the question is whether you would like to post a new plug-in to replace http://jquery.com/plugins/project/overlabel or would prefer that I simply point that one to the code you’ve written. Since I’m going to switch to this code, I don’t see any need to maintain the original version.
Aristotle Pagaltzis Says:
September 21st, 2007 at 6:13 am
I could make a page on my site for the plug-in if you think that’s OK?
Scott Sauyet Says:
September 21st, 2007 at 8:22 am
Of course. Let me know when it’s done, and I’ll point people there. Perhaps we can simply replace the links on the plug-in page to point there.

Guy Fraser Says:
September 25th, 2007 at 11:27 pm

Hi All,

I’ve been fiddling around with the short “chained” version of this script and come up with a new version as follows:

(function($){
$.fn.overlabel = function() {
    this.each(function(){
        var label = $(this);
        var id = this.htmlFor || label.attr('for') || "NO-ID";
        $("#"+id.replace(/\:/,'\\:'))
                .parent().addClass("overlabel-wrapper").end()
		.focus(function(){ label.css("text-indent", "-1000px"); })
		.blur(function(){ this.value || label.css("text-indent", "0px"); })
		.trigger("focus").trigger("blur")
		.length && 
			label.addClass("overlabel-apply");
    });
}
})(jQuery);

So, what have I done?

a) I’ve included the compatibility hack for JSF forms as per Zach’s suggesion - it’s still fast and just extends compatibility with markup used in existing forms.

b) I’ve replaced “ID-NOT-FOUND” with “NO-ID” - still obvious what it does, but shorter so saves electrons.

c) Automatically add a class to the element that contains the label/input (which no longer has to be a div) so that the raw HTML doesn’t need to have the class defined.

This just makes working with some existing forms a lot easier, especially those that place each field in an li or span, etc.

The CSS becomes:

.overlabel-apply {
  color:#999;
  cursor:text;
  left:5px;
  position:absolute;
  top:1px; /* I use bold labels hence only 1px, normal weight labels would use 3px */
  z-index:1;
}
.overlabel-wrapper {
 position: relative;
}

Note: I’ve not floated the wrappers as per the original example just to keep the CSS small. To get the single line form as per the original example, just change the wrapper css to the following:

.overlabel-wrapper {
  float:left;
  margin-right:3px;
  position:relative;
}

c) You will no doubt have noticed that I’ve put the styles and their properties in alphabetical order - I find this improves readability when you are in a rush to do something at 5am (as it is here in the UK) and are wading through a HUGE CSS file heh.

d) With this approach we can remove the “overlabel” class from the labels and the id’s from the divs (which also no longer need to be divs).

I know the code isn’t as readable to anyone who doesn’t do a lot of chaining, but it’s fast and compact. For projects that need lots of JS, having each component part as compact as possible is really important IMHO.

You could still include the “overlabel” class on labels if you wanted to use a selector like:

1
2
3

jQuery(function(){
 jQuery("label.overlabel").overlabel();
});

But if you’re working with existing form markup you would probably use something more like:

1
2
3

jQuery(function(){
 jQuery("form.myForm label").overlabel();
});

So, where next…

We’ll obviously I’d like to see the chained version become the official version. It’s more compact and more flexible at the same time.

It might be interesting to see if the formatting of the labels could be based on the formatting of the input/textarea - eg. the font properties, line height and padding could all be taken from the input/textarea and the only thing that the developer would need to change is the colour of the label.

Comments?

Aristotle Pagaltzis Says:
September 27th, 2007 at 6:29 am

How is the chained version “more” flexible? There is nothing about those improvements that makes them hard to incorporate into the clean version:

( function( $ ) {
    $.fn.overlabel = function() {
        this.filter( 'label[for]' ).each( function() {
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id ) ||
                document.getElementById( id.replace( /\:/, '\\:' ) ); // hack for JSF forms
 
            if(!field) return;
 
            label.addClass( 'overlabel-apply' );
 
            var hide_label = function() { label.css( 'text-indent', '-1000px' ) };
            var show_label = function() { this.value || label.css( 'text-indent', '0px' ) };
 
            $( field ).
                parent().addClass( 'overlabel-wrapper' ).end().
                focus( hide_label ).blur( show_label ).each( show_label );
 
            return;
        } );
    };
} )( jQuery );

I improved upon the JSF hack here because there’s certainly perfectly good markup that’s not generated by JSF but has colons in IDs; so if the code is to actually “extend compatibility with markup used in existing forms,” it needs to deal with both cases. I also commented the hack so someone who looks at it two years from now will know what the heck that cruft is for.

Scott Sauyet Says:
September 27th, 2007 at 7:58 am
I don’t think the “JSF hack” is necessary here. Isn’t that just a workaround for jQuery’s other use of the (perfectly legal) colon character in an id? That is, jQuery would recognize $("#my-id:first-child") as pointing to the element with id “my-id” but only if it is the first child element of its parent. But if you have an element with the id “my-id:first-child”, which is legal XHTML, jQuery’s call above wouldn’t find it. Instead you need to escape the colon with a backslash, and in order to do that in a JS string you need a second backslash escaping the first one. A bit ugly, but at least it leaves us with the flexibility to have CSS-like selectors. But won’t document.getElementById("my-id:first-child") fetch the item with exactly that id anyway without any sort of hack?

BTW, Aristotle, have you set up your plug-in somewhere yet? I’d really like to point mine to it.

— Scott
Aristotle Pagaltzis Says:
September 27th, 2007 at 12:29 pm
Oh! I completely misread what the hack was for. I read it as saying that JSF outputs IDs where the colons are backslashed in the markup – please don’t ask what made me think that, because I have no idea. So yeah, the hack is unnecessary in my version.

I don’t have a page yet! Sorry. I think I’ll go make one right now, or else it will slip below the fold of my backlog again…
Guy Fraser Says:
October 1st, 2007 at 12:11 pm
OK, I like the revised readable version more than my updated chained version. It’s far easier to read and understand. Great work Aristotle!

P.S. Did you spot my “cursor: text” style setting for the label - it ensures that when you mouse over the search box the cursor will be the same as when the box is focussed (just “feels” nicer IMHO).
Guy Fraser Says:
October 1st, 2007 at 12:16 pm
I forgot to mention - would it be possible to return the jQuery object - this would allow chaining, eg. I might want to do something like this:

jQuery(”#form3 label”).overlabel().css(”color”,”green”);

Ideally the jQuery object returned by overlabel() would only include the labels that have actually been processed.
Scott Sauyet Says:
October 1st, 2007 at 1:18 pm
Ideally the jQuery object returned by overlabel() would only include the labels that have actually been processed.

Are there other plug-ins that work like this? This would violate my basic assumption that the jQuery object returned is the same one I’ve chosen with my selectors. But I agree that it would be best to return the jQuery object.
Guy Fraser Says:
October 1st, 2007 at 2:05 pm
Well, there are two options…

1. Make it clear in docs that returned jQuery obj is filtered to just those labels that are processed. The return would be:
```
    return this.filter("label.overlabel-apply");
```
(or maybe just build a new list within the .each()…?)

To apply stuff to just the processed labels, the developer could:
```
    $(whatever).overlabel().whatever();
```
The developer could call .end().end() to undo the two filters (label[for] and label.overlabel-apply), eg:
```
    $(whatever).overlabel().end().end().whatever();
```
2. Return the original list prior to any filteres, eg:
```
    return this.end(); // undo the label[for] filter
```
With this option the developer could
```
    $(whatever).overlabel().filter("label.overlabel-apply").whatever();
```
—-

I’m not sure which would be best. Option 2 would lead to more transparent code, albeit a little wasteful due to the extra filter.

Note: My example of setting colour to green was terrible because you’d just do that using the CSS for .overlabel-apply heh.

Aristotle Pagaltzis Says:
October 3rd, 2007 at 6:23 pm

Scott: I’m actually reluctant to make a page yet because you have comments on your site and I don’t (yet)! And the discussion here keeps turning up interesting bits. Returning the jQuery object is actually something I thought I should add. But I hadn’t thought about returning a list of only the processed elements, and that is a handy option! As for whether to return the selection filtered or unfiltered – how about letting the user choose?

( function( $ ) {
    $.fn.overlabel = function( do_return_filtered ) {
        var selection = this.filter( 'label[for]' ).map( function() {
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if(!field) return;
 
            label.addClass( 'overlabel-apply' );
 
            var hide_label = function() { label.css( 'text-indent', '-10000px' ) };
            var show_label = function() { this.value || label.css( 'text-indent', '0px' ) };
 
            $( field ).
                parent().addClass( 'overlabel-wrapper' ).end().
                focus( hide_label ).blur( show_label ).each( show_label );
 
            return this;
        } );
 
        return do_return_filtered ? selection : selection.end();
    };
} )( jQuery );

This way you can pass an optional true argument to the function. If you do, the object you get will contain just the processed nodes; if you call the method without parameters or with a false parameter, the selection remains the same. (All it took to achieve this is changing each() to map() and changing return to return this at the end of the anonymous function.)

Actually, now that I think about it, there’s some more control we could give the user:

( function( $ ) {
    $.fn.overlabel = function( arg ) {
        var opt = {
            label_class:   'overlabel-apply',
            wrapper_class: 'overlabel-wrapper',
            hide_css:      { 'text-indent': '-10000px' },
            show_css:      { 'text-indent': '0px' },
            filter:        false
        };
 
        if( 'Object' == typeof arg )
            for( key in arg ) opt[ key ] = arg[ key ];
        else
            opt.filter = !!arg;
 
        var selection = this.filter( 'label[for]' ).map( function() {
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if(!field) return;
 
            label.addClass( opt.label_class );
 
            var hide_label = function() { label.css( opt.hide_css ) };
            var show_label = function() { this.value || label.css( opt.show_css ) };
 
            $( field ).
                parent().addClass( opt.wrapper_class ).end().
                focus( hide_label ).blur( show_label ).each( show_label );
 
            return this;
        } );
 
        return opt.filter ? selection : selection.end();
    };
} )( jQuery );

Now the user can either pass true to get back the filtered selection, or false (or just nothing) to get back the original selection – or pass a parameter object to customise any part of the CSS to taste.

Scott Sauyet Says:
October 4th, 2007 at 8:31 am
I’d been thinking along the same lines as the last one, adding configuration parameters.

I don’t personally find any need for the filtered return, but I like the added flexibility for those who do. (My own comment in response to Guy’s last one disappeared — my own damn blog!) I don’t see any good reason to overload the args variable, though. The filter parameter could simply be an attribute of args. That would chop off a few lines and make it easier to document.

Aristotle Pagaltzis Says:
October 5th, 2007 at 1:22 am

Hmm, you are right, there isn’t much reason to overload it. The config object should just be another optional parameter, and I shouldn’t have put the filtering flag in there at all. Then I can also unbork the variable names:

$.fn.overlabel = function( do_return_filtered, override ) {
    var config = {
        label_class:   'overlabel-apply',
        wrapper_class: 'overlabel-wrapper',
        hide_css:      { 'text-indent': '-10000px' },
        show_css:      { 'text-indent': '0px' },
        filter:        false
    };
 
    if( override ) for( key in override ) config[ key ] = override[ key ];

The rest of the references to opt must be changed, of course, as must the name of the flag variable on the return line. Much nicer.

It does mean that if you want to pass a config hash, you must say whether you want your selection filtered or not, but if you pass a config hash you’re already taking a verbosity hit anyway, so the extra positional parameter is not a big burden.

Benjam Says:
October 11th, 2007 at 5:07 pm
You both are having great ideas with this, but one thing I would like to see is an updated demo page.

I am having difficulties getting this little function to work on my page.

One thing I noticed, is that one must replace all instances of opt. with config. when using the latest version (posted by Aristotle on 2007-10-05).

Also, what is the wrapper_class for, and what would be a suitable CSS declaration that would enable this to work?
Benjam Says:
October 11th, 2007 at 5:11 pm
Oops, forgot to read the rest of that last comment before posting, forgive my config. to opt. statment.

One other thing I noticed, is that the filter part of the config object is moot now, isn’t it? Due to the do_return_filtered argument?

Anywho… let me know when I can view an updated demo page.

Thanks.
Guy Fraser Says:
October 11th, 2007 at 6:51 pm
The recommended way to do default settings is shown on a jQuery tutorial:
1 2 3 4 5
jQuery.fn.foobar = function(options) { var settings = jQuery.extend({ value: 5, name: "pete", bar: 655 }, options); };
http://docs.jquery.com/Tutorials:Getting_Started_with_jQuery

Whilst Aristotle’s settings will do much the same thing (and probably be faster) it might be worth sticking to the documented method as more people will be familiar with it….?
Scott Sauyet Says:
October 12th, 2007 at 7:28 am
I will try to create an updated version over the weekend. I’ve been letting this play out as Aristotle said he’d be creating a new plugin page for it. At this point, though, even with Aristotle’s rewrite, the whole thing has become a group effort. I will combine all the ideas listed above and create a simple demo.
Damir Secki Says:
October 12th, 2007 at 3:30 pm
Hello folks!
great team work!

I’ve done something on my own but it’s not even remotely similar and useful as what you’ve done boys. I have only one problem with this whole approach…

If I use this On my log-in form firefox (or the browser) wont be able to remember the values of the fields for me, to log in next time… so next time instead of having already filled fields with my user name and password the fields will be filled with overlabel values… and this is not a very big deal… but its a setback to write the login data all over again…

are there any workarounds this?
Damir Secki Says:
October 12th, 2007 at 3:33 pm
ups, never mind… it seems I’ve spoken too soon
Scott Sauyet Says:
October 12th, 2007 at 3:41 pm
Although I never really considered this, it seems to just work, at least the original version. I’ll keep it in mind when I try to put all this together this weekend. But as far as I can tell, that shouldn’t be an issue at all. Firefox puts a value in this field before any of our manipulation. And that manipulation always checks for a value. I’ll have to check if it works in other browsers too.

Have you tested somewhere and found this not working?
Scott Sauyet Says:
October 12th, 2007 at 3:42 pm
And I’ve responded too soon!

Glad it’s working.
Guy Fraser Says:
October 12th, 2007 at 6:57 pm
Don’t forget the cursor:text in the css for processed labels
Scott Sauyet Says:
October 15th, 2007 at 7:49 am
I’m afraid I didn’t find the time this weekend to do an update. I will do it as soon as I can find a spare hour or two.

Guy Fraser Says:
October 30th, 2007 at 10:48 pm

Just been reading this: http://www.learningjquery.com/2007/10/a-plugin-development-pattern

So the plugin could become something like:

( function( $ ) {
 
    // plugin definition
    $.fn.overlabel = function( options ) {
 
        // calculate main options (without metadata)
        var main_opts = $.extend( {}, $.fn.overlabel.defaults, options );
 
        var selection = this.filter( 'label[for]' ).map( function() {
 
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if ( !field ) return;
 
            // if metadata is present, extend main_opts
            var opts = $.meta ? $.extend( {}, main_opts, label.data() ) : main_opts;
 
            label.addClass( opts.label_class );
 
            var hide_label = function() { label.css( opts.hide_css ) };
            var show_label = function() { this.value || label.css( opts.show_css ) };
 
            $( field ).
                 parent().addClass( opts.wrapper_class ).end().
                 focus( hide_label ).blur( show_label ).each( show_label );
 
            return this;
 
        } );
 
        return opts.filter ? selection : selection.end();
    };
 
    // publicly accessible defaults
    $.fn.overlabel.defaults = {
 
        label_class:   'overlabel-apply',
        wrapper_class: 'overlabel-wrapper',
        hide_css:      { 'text-indent': '-10000px' },
        show_css:      { 'text-indent': '0px', 'cursor': 'text' },
        filter:        false
 
    };
 
} )( jQuery );

Things I’ve done:

1. Non-destructively determine settings (main_opts) when the overlabel function is called, before entering the map() block.

2. If metadata plugin is available, non-destructively extend main_opts to include element-level settings

3. Made default settings publicly accessible - you can now easily override the settings via $.fn.overlabel.defaults

4. Added cursor:text to the show_css to ensure good usability :p

NB: I’ve not tested the updates heh.

Scott Sauyet Says:
October 31st, 2007 at 7:52 am
I’m glad I haven’t found the time to put all this together! This is looking just about perfect.

By the way, I know that there is no obvious way to format code. This is a mostly unused blog, but when I get some time, I’ll see if I can document how to do it. For now, you might try what I do, which is to add:
1 2 3
<blockquote style="font-size: 125%;"><pre lang="javascript" line="1"> // code here < /pre>< /blockquote>

Guy Fraser Says:
October 31st, 2007 at 9:59 am

Found a slight bug and made another tweak based on feedback elsewhere…

( function( $ ) {
 
    // plugin definition
    $.fn.overlabel = function( options ) {
 
        // build main options before element iteration
        var opts = $.extend( {}, $.fn.overlabel.defaults, options );
 
        var selection = this.filter( 'label[for]' ).map( function() {
 
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if ( !field ) return;
 
            // build element specific options
            var o = $.meta ? $.extend( {}, opts, label.data() ) : opts;
 
            label.addClass( o.label_class );
 
            var hide_label = function() { label.css( o.hide_css ) };
            var show_label = function() { this.value || label.css( o.show_css ) };
 
            $( field ).
                 parent().addClass( o.wrapper_class ).end().
                 focus( hide_label ).blur( show_label ).each( show_label );
 
            return this;
 
        } );
 
        return opts.filter ? selection : selection.end();
    };
 
    // publicly accessible defaults
    $.fn.overlabel.defaults = {
 
        label_class:   'overlabel-apply',
        wrapper_class: 'overlabel-wrapper',
        hide_css:      { 'text-indent': '-10000px' },
        show_css:      { 'text-indent': '0px', 'cursor': 'text' },
        filter:        false
 
    };
 
} )( jQuery );

1. Renamed “main_opts” to just “opts” - this also fixed a bug on the “return …” line.

2. Renamed the element-specific opts to “o” - shorter and also seems more visually distinct from the main “opts”

Guy Fraser Says:
November 8th, 2007 at 9:20 am

One final mod (I hope!) for readability:

25
26
27

            $( field ).
                 parent().addClass( o.wrapper_class ).end().
                 focus( hide_label ).blur( show_label ).each( show_label );

Becomes:

25
26
27

            $( field )
                 .parent().addClass( o.wrapper_class ).end()
                 .focus( hide_label ).blur( show_label ).each( show_label );

I’ve moved the .’s to make it clearer that parent() and focus() aren’t global functions for anyone doing a cursory glance through the code. Having the “.” at the start of those two lines (rather than the end of the preceding line) just makes it more obvious that it’s a continuation of the chain IMHO.

Guy Fraser Says:
November 14th, 2007 at 10:34 pm
Hi Scott,

Did you ever get chance to push this in to SVN and release?
Scott Sauyet Says:
November 14th, 2007 at 10:56 pm
Hi Guy,

I don’t have a public SVN server to push this to. I’ve been a bit out of touch with JQuery for the last two months, so I don’t know what’s going on. Is there an SVN server I can use for posting non-official plug-ins?

But no, I haven’t had any time at all in the last few weeks.

— Scott
Guy Fraser Says:
November 15th, 2007 at 10:35 pm
I believe the jQuery site has one (plus associated bug tracker, etc.), but no idea how to use it :s
Mark Montague Says:
November 28th, 2007 at 3:35 pm
I’ve been trying out the final version of this script, and it works pretty well but seems to have the following bug: if the text field begins with some text in it, the overlabel is shown on top of the text. I can’t quite see how to fix that; anyone else?

Scott Sauyet Says:
November 29th, 2007 at 5:08 am

Yes, this looks like a regression. This should fix it:

25
26
27

            $( field )
                 .parent().addClass( o.wrapper_class ).end()
                 .focus( hide_label ).blur( show_label ).each( hide_label ).each( show_label      );

Mark Montague Says:
November 29th, 2007 at 8:38 am
That did fix it - great! I’m having one further problem with this script, and it seems like a harder one: in Safari 2 (but not Safari 3), if you click on the text of the overlabel, nothing happens. If you click in the blank space next to it, the overlabel disappears and the text input area receives focus, as it should. So it seems that somehow the overlabel is catching the click event instead of the text field. Any ideas?
Scott Sauyet Says:
December 3rd, 2007 at 8:34 am
Unfortunately, with no Mac to test on, I’m not sure how to chase this down. I have a Win32 version of Safari, but it’s version 3, and everything seems to work there. I wonder if we could create a test case using only CSS and ask the good folks on the CSS-Discuss list…
Guy Fraser Says:
December 17th, 2007 at 4:27 pm
I’m guessing that the event is not bubbling or for some reason the label is swallowing the click.
Aristotle Pagaltzis Says:
December 19th, 2007 at 3:51 am
Aha, that’s why the original function added an onclick handler to the label element. I removed that in my refactor because keeping it made things messier and I didn’t understand what purpose it might possibly serve, seeing as clicking the label should focus the form element anyway. I guess it needs to be added back in… oh well.
Ellen Says:
January 6th, 2008 at 3:43 pm
I’m a little confused after reading all this … have all the rewrites been incorporated into the plugin? What is the final code that I am supposed to use?

Thank you

Scott Sauyet Says:
January 7th, 2008 at 9:32 am

I’m sorry, I never seem to get back to putting together a decent demo. I think the current state of play is the following:

( function( $ ) {
 
    // plugin definition
    $.fn.overlabel = function( options ) {
 
        // build main options before element iteration
        var opts = $.extend( {}, $.fn.overlabel.defaults, options );
 
        var selection = this.filter( 'label[for]' ).map( function() {
 
            var label = $( this );
            var id = label.attr( 'for' );
            var field = document.getElementById( id );
 
            if ( !field ) return;
 
            // build element specific options
            var o = $.meta ? $.extend( {}, opts, label.data() ) : opts;
 
            label.addClass( o.label_class );
 
            var hide_label = function() { label.css( o.hide_css ) };
            var show_label = function() { this.value || label.css( o.show_css ) };
 
            $( field )
                 .parent().addClass( o.wrapper_class ).end()
                 .focus( hide_label ).blur( show_label ).each( hide_label ).each( show_label );
 
            return this;
 
        } );
 
        return opts.filter ? selection : selection.end();
    };
 
    // publicly accessible defaults
    $.fn.overlabel.defaults = {
 
        label_class:   'overlabel-apply',
        wrapper_class: 'overlabel-wrapper',
        hide_css:      { 'text-indent': '-10000px' },
        show_css:      { 'text-indent': '0px', 'cursor': 'text' },
        filter:        false
 
    };
 
} )( jQuery );

Please let me know if that doesn’t work for you.

Mike Brittain Says:
August 14th, 2008 at 9:01 am
Well done! I’m glad you’re finding good use for it, and extending this technique further than I have.
Nick Carroll Says:
August 31st, 2008 at 7:59 am
Hey Scott,

I fixed the bug that Mark Montague (Comment #55) raised. Safari seems to fire off the form Autofill event after the JQuery ready event. So if you call the overlabel function with:

$(document).ready(function() {
$(”label.overlabel”).overlabel();
});

Then in Safari, since the Autofill hasn’t added any text to the form input field, the overlabel plugin will think the input fields are empty and display the labels over them. Then Safari triggers the Autofill event and adds the previously entered text (eg username and password) into the form fields. This gives the undesirable effect of overlapping text in the form field.

To get around this problem you have to call the overlabel plugin with the following:

$(window).load(function() {
$(”label.overlabel”).overlabel();
})

This waits until the page is fully loaded and Safari’s Autofill event finishes before calling the overlabel plugin.

Cheers,
Nick.
Ian Bryce Says:
August 31st, 2008 at 3:48 pm
I was having trouble with the Label overlapping each other. i’ve over come this by removing in the CSS left:3px and replacing this with padding:0 0 0 3px

This fixed the problem for both IE and FF whilst using the blueprint CSS framework.
Scott Sauyet Says:
September 2nd, 2008 at 5:39 am
@Nick, that makes sense. I’ll change it as soon as I get a free moment.

@Ian, I haven’t seen that issue, but I’ll take a look. It’s certainly a clear enough solution.
Wayne Elgin Says:
October 20th, 2008 at 11:48 am
Nice work.

Have you thought about extending this so that implicit labels also work?
http://www.w3.org/TR/html401/interact/forms.html#idx-label-1

I also second the need for a clarifying post or just updating the jQuery plugin page with an up-to-date download link for the script. Parsing through all of the comments confuses me about which direction the current code went.

-Wayne
Ryan Says:
October 22nd, 2008 at 12:51 pm
To everyone: Thanks for all the hard work. I look forward to using this script.

I’m using the version from comment #60 and having some problems getting it to work (labels appearing in the top left corner of my screen).

Would be awesome to have a demo that shows not only the latest version of the script, but also the appropriate markup and css to use.

Thanks!
Phil Says:
November 6th, 2008 at 1:10 pm
Nice work everyone

One thought though - it seems as though the assumption has been made that the label will be in the same container as the textbox, so the wrapper is applied to the textbox’s parent rather than the labels parent.

I’m a bit of a jQuery novice so I won’t get my hands dirty - just my throwing my 2 cents in!
Tim Büthe Says:
November 9th, 2008 at 10:07 am
Hi,

the zip download link (http://scott.sauyet.com/Javascript/Demo/Overlabel/Overlabel.zip) gives a 404

regards,
Tim
Nikon Says:
November 24th, 2008 at 4:27 am
I would like to see is an updated demo page.
Riad Marrakech Says:
May 24th, 2009 at 4:56 am
awesome plugin
Evan Carroll Says:
June 8th, 2009 at 6:14 pm
Man i wish there was a working demo of the new version.. this isn’t working for me at all.
Evan Carroll Says:
June 8th, 2009 at 6:19 pm
scratch that the demo is up to date just not the original post
huseyin Says:
August 15th, 2009 at 3:55 pm
thanxx
Aurélien Geron Says:
September 18th, 2009 at 11:05 am
Hi,

I just wanted to let you know that I wrote a very similar plugin also based on the overlabel technique, but based on the prototype framework instead of jquery.

You can download it here:
http://github.com/ageron/labelinput/

Cheers!
Aaron Says:
October 17th, 2009 at 2:10 pm
Great plugin! I’m having one issue though. When you have multiple logins saved for a site and Firefox autofills one of the logins, the overlabel continues to display over the filled-in password. As far as I know, the autofill doesn’t trigger any events on the fields. Anyone know of any good fixes?

The workaround I’m using right now is to tie to the focus event of the username field and start a check every second for a value in the password field. If it finds one it hides the label. When the username is blurred the check stops. It works but I wish there was a better solution.
Scott Sauyet Says:
October 24th, 2009 at 3:52 pm
Do you have an example url? I can’t duplicate this. Perhaps at start a call to $(”selector”).focus().blur() in a timeout on startup would do…

Craig Says:
December 3rd, 2009 at 12:21 am

I looked and what you did and wrote a plugin that’s does the exact same thing in a slightly different way. Instead of moving the label over the input, I chose to hide the label and copy the html() into the input’s value attribute.

Here’s my version:

(function($) {
    $.fn.overlabel = function() {
        this.filter('label[for]').each(function() {
            var $label = $(this);
            var $field = $('input[id="' + $(this).attr('for') + '"]');
 
            if(!$field) return;
 
            var hide_label = function() { 
            	if ($field.val() == $label.html() || $field.val() == "")
            	{
            		$field.val(""); 
            		$field.removeClass('overlabel_shown');
            	}
            };
            var show_label = function() {
            	if ($field.val() == $label.html() || $field.val() == "")
            	{
            		$field.val($label.html());
            		$field.addClass('overlabel_shown') 
            	}
            };
 
            $label.hide();
 
            $field.focus(hide_label).blur(show_label).each(show_label);
 
            return;
        });
    };
})(jQuery);

GouMs Says:
December 8th, 2009 at 5:45 pm
Hi Guys,

Nice discussion about best ways to do a watermark using jQuery !
I’m using a similar pluggin that I wrote myself, and was looking around the web to find a fix for my problem wich is the same than Aaron (post #75).

Reproduce it as easy as this:
- Make a login form with overlabel (email + password).
- Log in and allow firefox to remember your email and password.
- Log out
- Reload the page
- Type the begining of your email address, and select it in the list that firefox is showing.
–> The password field is automaticaly filled and the label stay over the input value !

I can’t find the event to use to fix that :s

Is anyone having an idea?

Cheers
GouMs Says:
December 8th, 2009 at 6:29 pm
About my last comment:

I tried to hang arround with “DOMAttrModified” but I figured out that the value of an input field is actually not a DOM attribute. The actual is only use to set the default value, and is not change when a user or a script update the value of the field.

So I tried with “DOMControlValueChanged” but nothing conclusive.. I don’t know if this event is really working yet in the common browsers… Does anyone know about it?

Regards.
Scott Sauyet Says:
December 9th, 2009 at 3:07 pm
@Craig: This is an interesting alternative. It is slightly simpler, which is nice, but it has one minor hole that I can see: If the user wants to type the same value as is displayed in the label, she’s not going to see it as an entered value but as an overlabeled-style field. This is not a big deal, I imagine, but it could be disconcerting.
Scott Sauyet Says:
December 9th, 2009 at 3:08 pm
@GouMS: Yes, I see what you’re talking about too. I haven’t found a solution yet, but I’ll keep looking.
GouMs Says:
December 9th, 2009 at 5:55 pm
@Craig: I haven’t tried your script, but is it working with password fields? I know that it’s one of the major concern about watermark that are not using the overlabel method…

@Scott: Thanks, let me know if you find anything. By the way it’s very nice to see that more than 2 years after posting this thread, you are still updating the script and helping people to handle it!

Cheers
Scott Sauyet Says:
December 14th, 2009 at 10:26 pm
@GouMs: Well, I don’t get to follow the jQuery group regularly; I figure this fairly minor plug-in is at least one way I can give back to the community.
Cheryl Says:
December 21st, 2009 at 7:36 am
This is an excellent help to me, looks very stylish and nice. I’m also having the problem with autofilled-passwords causing a label overlap. Could any of you gentlemen give me some kind of workaround here? I just want the labels to disappear when the fields are filled in. I work with PHP (and only cut-and-paste with Jquery and javascript), so some of your posts are kinda over my head. Any help would be appreciated.
Scott Sauyet Says:
December 27th, 2009 at 9:38 pm
@Cheryl: Is that happening only in Firefox? And only when there are several passwords stored for the field? If so, that’s the issue that several people have pointed out and it’s one for which no one has yet found a solution. We’ll keep looking, though. Sorry.
sada Says:
January 18th, 2010 at 4:50 am
asd

3/31/2007

Overlabel with JQuery

86 Responses to “Overlabel with JQuery”

Leave a Reply

Links

March 2007
S	M	T	W	T	F	S
« Feb				Apr »
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31