Code Snippets: Posts

I released a lot of code today including a bug fix that was probably pestering any of you with r87.

• product.picker.js now has no picklets; these are in the implementations/picklets directory
• ProductPicker now detects if there is no doctyp and, if not, sets the position of the picker to be fixed (no IE6 support)
• small docs update in element.cnet.js
• added new picklet: CNETProductPicker_PricePath
• added new picklet: NewsStoryPicker_Path
• new file: clipboard.js (allows you to insert text into the OS clipboard)
• new file: html.table.js (automates building html tables)
• new file: element.forms.js (for managing text inputs - get selected text information, insert content around selection, etc.)
• fixed an error in stickyWinHTML (ie reserves “class” for member names)
• converted window.onDomReady references to window.addEvent(’domready’..
• updated css for stickyWin.js to avoid namespace conflicts with the css class “clearfix”

| Read the rest »

Bas Wenneker has a nice little article over at solutoire.com on sorting javascript arrays. The docs over at Mozilla on Array.sort demonstrate the same stuff, but Bas's article is a quick read that's worth it if you ever see yourself working with data this way.

Here's a little Mootools extension that you might find useful. I'm using it my StickyWin classes to allow the user to "pin" it in place so it won't move if they scroll.

PLAIN TEXT

JavaScript:

$('fxTarget').pin()

$('fxTarget').pin()

Execute the example, then scroll. That's it. You can unpin it if you like:

PLAIN TEXT

JavaScript:

$('fxTarget').unpin()

$('fxTarget').unpin()

(note, in this example because of the way my little fxTarget helper works, unpin will break the drag behavior, but that won't happen in other instances).

I've added .pin and .unpin to StickyWin, too.

UPDATE: This code is now in the plugins directory of the mootools library as Hash.Cookie.

Over on Ajaxian there was a recent post about a little Prototype.js dependent class called CookieJar.

Lalit Patel has created a JavaScript Library to use JSON to store data in cookies. JSON Cookies is built on top of Prototype and gives you a simple API to put and get JSON values into cookies

I liked the idea, so I wrote a version for Mootools. The Mootools version is a little different and adds some functionality (for merging data) and it stores its info a little differently, but it's basically the same concept. | Read the rest »

Internet Explorer's behavior sometimes really, really makes me angry.

We recently rolled out a copy of our javascript libraries after much testing and, a few hours later, discovered a page on our site that IE was barfing on. Specifically, the page would load about half way and then announce that it could not load the page (despite the fact that it's clearly loaded behind the error message) and then present you with its generic "page not found" content.

I've seen this behavior before and generally know what to look for, but it's a huge pain because the page is gone and your only method for debugging it is to slowly remove code, line by line, until it stops doing it. Then you put things back bit by bit until you narrow it down to the offending line. It's painstaking work and the constant error popping up begins to really grate.

So why does IE do this?

Perhaps I should use "when" instead of "why" in that header, because I don't really know why the developers of IE would do this.

Update: Bit thanks to Jon in the comments for turning me on to this MSFT support page about this topic. I've updated this article here to more accurately describe the problem. More detail can be found in the MSFT article.

IE does this when you attempt to modify a DOM element before it is closed. This means that if you try and append a child element to another and that other element (like the document.body) is still loading, you'll get this error. This will occur if you use .appendChild (which in Mootools includes .adopt, .injectInside, .injectBefore, etc.) or if you use Element.innerHTML = "" (or in Mootools, the .setHTML method). | Read the rest »

Helping out our CMS group today I hacked out a new little widget class called "Confirmer" that handles notifying the user when something they've done on the page requires some sort of notice. An auto-save, or the failure to auto-save, or any other sort of message.

It's designed to be unobtrusive so it doesn't annoy the user too much if it happens a lot. You can have the prompt inline in the page or floating over it. The message just fades in and then back out. It comes with default styles that can easily be overridden, the message displayed can be changed every time you call it, and its easy to position it relative to an element or at the edge of the screen.

Quick example:

PLAIN TEXT

JavaScript:

new Confirmer().prompt(); //watch the upper right of your screen

new Confirmer().prompt(); //watch the upper right of your screen

More examples and details in the wikitorial.

Over at Ajaxian today they have a post on miniajax.com which describes itself as "a showroom of nice looking simple downloadable DHTML and Ajax scripts".

I'm not sure if they authored these scripts or if they just collected them all into slick looking examples. Some of the items link to other sites, but some they seem to host.

Some of these things I think would do well to write as plugins for the Mootools library but if Valerio (the gatekeeper for Mootools) doesn't want it I think some of them would do well to be added to the CNET Library.

This goes hand-in-hand with the patterns project that we're trying to kick off here. I think this page could really help inform that work...

Over at Ajaxian today they have a short post on whatshouldisay.com and their crafty use of effects and whatnot. Check out the visual sorting on this page. I think this type of thing makes a page so much more fun to play with. They seem to be using the Y!UI for this.

Update: I went ahead and did my own version of this slick sorting: Fx.Sort.

Via Ajaxian is this post revising the age-old window.onload problem. I tried to write a dom polling method that would re-evaluate the dom every few milliseconds maybe 3 or 4 months ago but got distracted. Here's the work of smarter and less easily distracted people than I, and it's worth reading (even if you skip to the end). Maybe we'll work this into Mootools.

Peter Michaux has written a detailed post on the window.onload problem:

The goal of unobtrusive JavaScript programming it to separate the JavaScript behavior from from the HTML content and is analogous to the goal of unobtrusive CSS design to separate the CSS presentation from the HTML content. Separation of presentation and content has been possible for years but there is one wrinkle standing in the way of completely separating the behavior. This article is about previously suggested techniques to enable this separation, their problems and a new option that combines the strengths of the current techniques with an extra bonus into a new robust solution.

| Read the rest »