Hacking at 0300

Updated 2011-02-28; minor bug fix. Thanks, brian!

Every time I create or use a jQuery plugin, I realize that the assigning of behaviors to elements on the page is a design decision, not a programming one, and one that should be made by the guy in charge of the CSS, not the guy in charge of the javascript. Even when I'm the same guy, I want to wear each hat separately. But these presentational enhancements are written in javascript and applied in javascript. So my "presentational" code is in two different files:

style.css

.gallery a { border: 1px solid green }

style.js

$('.gallery a').lightbox({overlayBgColor: '#ddd'});

I could put the presentational javascript in the HTML with $.metadata but while that's fine for quick-and-dirty pages, it's evil in production since it completely violates the separation of data/structure/presentation/behavior.

As I and others have noted before, the application of these plugins belongs in the stylesheet, and I finally got it to work:

style.css

.gallery a {
  border: 1px solid green;
  -jquery-lightbox: {overlayBgColor: '#ddd'};
}

and a single call to start it off: $(document).parsecss($.parsecss.jquery) .

Download the code.

See the demo.

I was playing with Brandon Aaron's gradient plugin (based on Steven Slayer's gradient) and started adding options and playing with it, so now you can use named colors, percent sizes, and animation.

Download the code.

See the demo page.

Last modified 2011-10-28; added box option

The Hebrew pop-up keyboard on the YI site search box was always hard-coded and kind of obtrusive, so I wanted to make a jQuery plugin to add a keyboard to any input type="text" or textarea. To make it more flexible, I factored it into a general-purpose popup widget and the keyboard itself.

Download the code.

With the support for HTML5 data- attributes in jQuery 1.4.3 this plugin is largely obsolete.

Metadata

I put the idea that the metadata plugin should be extensible out on the jquery discussion group, but it got no attention, so I'm documenting it here.

This page is obsolete (it uses jQuery UI 1.5). Please see the updated page.

OK, this is the final update to the widget subclassing. Rather than creating a new method, $.widget.subclass, I created a single base widget $.ui.widget that does nothing but includes the Aspect-Oriented-Programming code and a subclassing method. I put everything in the $.ui namespace (since namespacing plugins doesn't work anyway, all plugin names need to be globally unique). I removed the callSuper method, since this.callSuper('ui.widget', 'method', args) is no better than just doing it straight, $.ui.widget.prototype.method.apply(this, args).

Without further ado, here's the code (download):

This post is obsolete. Please see the updated post.

The phone pad below is messed up in Internet Explorer. I know. I don't care anymore. The plugin, however, works.

	$('div.test input:button').click(function(){
		$('.output').sendkeys($('div.test input:text').val());
	});
	$('.phonepad input').click(function(){
		$('.output').sendkeys(this.name || this.value);
	});
	$('.output:first').bind('keypress', function(evt){
		$('#keypress').text($('#keypress').text()+' '+evt.which);
	}).bind('sendkeys', function(evt){
		$('#sendkeys').text($('#sendkeys').text()+' '+evt.which);
	});

<div>
<textarea class="output"></textarea>
<br/>
<input type="text" class="output" />
<div class="phonepad"><input type="button" name="{leftarrow}" value="&larr;"/><input type="button" name="{rightarrow}" value="&rarr;"/><input type="button" name="{backspace}" value="BS"/><input type="button" value="7" /><input type="button" value="8" /><input type="button" value="9" /><input type="button" value="4" /><input type="button" value="5" /><input type="button" value="6" /><input type="button" value="1" /><input type="button" value="2" /><input type="button" value="3" /><input type="button" value="*" /><input type="button" value="0" /><input type="button" value="#" /></div>
<div class="test"><input type="text" /><input type="button" value="test"/></div>
<div id="keypress">keypress event.which:</div>
<div id="sendkeys">sendkeys event.which:</div>
</div>

The $.fn.sendkeys Plugin

I wanted to make a general-purpose onscreen keypad, and wasted a huge amount of time trying to find a way to simulate a keypress. $(element).trigger("keypress",...) won't work. Neither will keyup or keydown. For security reasons, I guess, you can't tell an element to pretend a key was pressed. The browser is too worried that you will access menus or something.

So I wrote my own plugin and named it after Microsoft's sendkeys which does similar things. For any element elem that is a <textarea> or <input type="text">, $(elem).sendkeys(string) inserts string at the insertion point or selection. It's the insertion point sensitivity that makes it more sophisticated than elem.value += string.

Downloads

Download $.fn.sendkeys.

I added some potentially dangerous code to automatically turn code examples (things in <code> elements with class demo into actual HTML or javascript that are added to the post. The javascript part works; I used it in the last post; here's testing the HTML insertion:

  <div style="background: purple; margin: 2px">This is a test</div>

And more testing:

  <div style="background: #080; margin: 2px">This is a test</div>

This page is obsolete (it uses jQuery UI 1.5). Please see the updated page.

This is an updated version of a tutorial I wrote a bit back, improved thanks to conversations with Scott Gonzalez of the jQuery UI team. Thanks!

Avoiding Bloat in Widgets

A while back, Justin Palmer wrote an excellent article on "Avoiding Bloat in Widgets." The basic premise (no suprise to anyone whose ever dealt with object-oriented programming) is that your widgets should not do everything possible; they should do one thing well but be flexible enough to allow others to modify them.

He describes two ways of extending objects: subclassing and aspect-oriented programming (AOP). Subclassing creates new classes, while AOP modfies the methods of a single object. Both can be useful.

Update: I no longer (2012-08-05) use Chili; I've switched to Prism.

I like the idea of syntax coloring, so let's see if Chili works:

alert('Hello, world');

and another: <div>Hello, <em>world</em></div>

I'm trying to be as HTML5-compliant as possible, at least in the sense of using their standards rather than making up my own, so the Chili setup I'm using is:

    $.extend(ChiliBook, {
        automatic: false,
        codeLanguage: function(el){
            // use the HTML5 language class
            var recipeName = /language-(\S+)/.exec(el.className);
            return recipeName ? recipeName[1] : '';
        }
    });
    $(function(){
        $('code[class*=language-]').not($('pre code')).chili({lineNumbers: false})
                                  .otherwise().chili({lineNumbers: true});
    });

 

Sweet! The idea of the above code is to look for a class that starts with "language-" and use that as the recipe for Chili (rather than Chili's built-in way of taking the entire className). It also assumes that any code in a pre element should have line numbers, and anything else should not. It uses the cute and brilliant otherwise plugin from http://groups.google.com/group/jquery-en/browse_thread/thread/6be2a127822a108d.

Update: It looks like line numbering works only intermittently. Oh well; I won't fix it.

jQuery encourages using namespaces for methods in the $ namespace, like $.foo.bar() rather than $.bar(). This works for $ because methods don't expect this to refer to anything specific, and the way javascript works is to assign this to the last-named object, so in $.foo.bar(), this refers to $.foo.

This idea fails for plugins, however, since plugins expect this to refer to the jQuery object that started the chain. If I define $.fn.bar = function(){}, then when $(...).bar() is called, this refers to $(...), just as we want. But if I define $.fn.foo.bar = function(){}, then when $(...).foo.bar() is called, this refers to $(...).foo, which is an object that knows nothing about jQuery. There's no way to make an object reference return something else.

But all is not lost. We can define a function that returns an object, and that function can use this to set the returned object to be just like a jQuery object, but with the desired namespaced methods in it. The inefficient way to do that is to copy the new methods into the jQuery object, but if we can manipulate the prototype chain directly (as we can in Firefox) we can add our new methods to the chain without copying.