Archive for April, 2007

A little Friday fun for you all. Via Boingboing:

AOL’s beta site looks like Yahoo

(Click on thumbnails for enlargement)

AOL’s new beta site looks just a teensy bit like Yahoo’s home page, wouldn’t you say? (Thanks, Patrick!)

posted by Mark Frauenfelder at 03:16:17 PM permalink | blogs’ comments

We're working on an internal build system here at CNET that is a mixture of things like Mootools download builder and Dean Edward's /packer/ so that we can quickly include just the javascript that's needed on a page.

Today's post at Ajaxian shows that we're not the only ones working on such a thing. Our solution though will likely be very specific to our application development, so I don't know if we'll be able to release it. In the comments of the post below, I also found a link to packtag, which seems to be an open source Java version of this very same functionality.

Via ajaxian:

We love to play with the plumbing don't we. jscsscomp is the latest compressor that uses Nicolas Martin PHP version of the Dean Edwards JavaScript Compressor.

With a swish of mod_rewrite:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*\.)(js|css)$ jscsscomp/jscsscomp.php?q=$1$2 [L,NC]

you can get your JavaScript like this:

PLAIN TEXT

HTML:

<script src = "/jscsscomp/yahoo.js, dom.js, event.js, effects/dragdrop.js, slider.js"></script>

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 »

A while ago I authored a FormValidator class for Mootools and I just spent a few hours adding a lot more functionality to it. In a nutshell:

• Warnings - you can now author warnings for the user that won't prevent the form from being submitted.
• Ignore Fields - if the context changes, you can ignore entire fields (for instance, if they are hidden)
• Stop/Start - you can toggle the validator on and off.
• Serialization - by default only one error is shown unless the user explicitly changes a value. This means that if a user tabs past a required field and it produces an error, when they back up to fill in that field, the field they just tabbed into won't produce an error. If the user actually changes a value, the validation will produce an error if the field fails validation, regardless of the state of other errors. This is all configurable, and is just there to make the form a little less annoying.
• Instance Validators - previously, the only way to add a Validator was to add it to all the instances of FormValidator. Now you can add instance-specific validators. You can also extend FormValidator and add validators to all its instances. This way, you can add global validators (FormValidator.add), semi-global validators for Classes based on FormValidator (MyFormValidator.add) and specific instance validators (thisFormsValidator.add).

You can see this in action in the Wikitorial and dig into the options in the docs.

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 »

I've refactored stickyWinHTML (see this previous post) a bit more to allow for as many buttons as you like.

Here's a quick code example:

PLAIN TEXT

JavaScript:

var simpleLayoutExample = stickyWinHTML('the caption', 'this is the body', {
  width: '400px',
  buttons: [
    {
      text: 'close',
      onClick: function(){alert('closed!')}
    },
    {
      text: 'okey-dokey',
      onClick: function(){alert('ok!')}
    }
  ]
});
$('layoutExample').adopt(simpleLayoutExample);

var simpleLayoutExample = stickyWinHTML('the caption', 'this is the body', {
width: '400px',
buttons: [
{
text: 'close',
onClick: function(){alert('closed!')}
},
{
text: 'okey-dokey',
onClick: function(){alert('ok!')}
}
]
});
$('layoutExample').adopt(simpleLayoutExample);

The buttons array allows for as many buttons as you like. You can see more detail in the wikitorial on this topic.

Note: the old options (closeTxt, onClose, confirmTxt, and onConfirm) are still supported, though deprecated.

So over at Ajaxian today they have a post on Dean Edward's latest update for his excellent packer javascript compression tool:

Dean Edwards has released Packer v3.0, one of the top utilities to squeeze your JavaScript like a lemon.

• respects Microsoft conditional comments
• new option to shrink variable and argument identifiers
• removed the special chars feature
  
  (except the ;;; feature which people seem to like)
• some bug fixes:
  • packer no longer closes spaces between the +/- operators so code like this is safe: c = a++ +b;
  • the throw"error"} bug that affected Safari (this is a Safari bug really but packer gets around it)
  • the __proto__ bug for Mozilla browsers (this only affected the online version of packer)
  • a minor parsing bug affecting the detection of regular expressions
• simplified the user interface

Update:

The problems I outline below are fixed. Thanks Dean!

Unfortunately, I ran one of our libraries through it and found two issues that we'll need to address before we can use it (luckly, I have a local copy of the previous version of the Packer...):

• 'http://...' breaks. Your packer wants this to be double quotes ("http://...").
• /*comment*//*followed by another comment*/ breaks. This happens in our code because we concatenate several files together and each file starts with comments and ends with comments.

I emailed Dean. Maybe he'll have a fix. If not, we'll have to figure something out or use the old one.