CNET JS Standards: Posts

There are several new goodies in the most recent release of the CNET libraries. I’ve got examples and details in the wikitorial, but here’s a quick list:

• JsonP - handles grabbing Json from a foreign domain; works a lot like Ajax
• Element.smoothShow/smoothHide - a height/opacity transition for an element to add it to the page smoothly.
• Element.setPosition - position an element relative to another (the window or another dom element)
• ProductPicker - a generic “picker” to allow users (typically in a CMS) to choose an item from a data source.
• stickyWinHTML - a default html block for in-page popups
• SimpleSlideShow - a very, very simple slideshow for dom elements or images

Have fun.

Hi gang,

I’ve set up an svn server at Google code to host all our “common” or “public” libraries. This is so you can keep up to date with the files as we fix bugs and whatnot. CNET has it’s own internal source control, but it’s behind our firewall. Rather than go through the trouble of setting up an external server for our libraries, I’m just using Google’s stuff.
In addition to this, I’ve broken up the libraries into chunks so you can download all the little files, or you can download just our extensions in a group. It’s not as fancy as Valerio’s document builder, but it’ll have to do.

• Our svn home page
• Browse the repository
• Download the concatenated versions

Note that our libraries are working off the development version of Mootools, so if you are using 1.0 you may find that some of our functions don’t work. I’ve included in the SVN our copy of Mootools, which will work with all our extensions. This copy is likely a few revisions behind the dev version.

I ran a pass through our reporting software the other day and here’s the breakdown of browser usage @ CNET. It’s not in a fancy chart because I don’t have time for that kind of thing, but I’m sure you’ll manage:

OS:
92.3 % Windows
6.8% Mac
0.4% Linux

Browser:
Firefox: 23%
MSIE: 71%
Safari: 4%

MSIE:
55.9% ver. 6
43.5% ver.7

Summary:

Firefox has made some strides but continues to be an underdog. Safari is only barely big enough to even worry about supporting it (though of course we do). IE7 has made a lot of headway since it’s launch, but IE6 is still the winner (sigh) with near 40% of the total market. No other browsers cracked the 1% mark.

It’s scary that .6% of our IE users are still using version 5 (dear god why?!?) and .1% of them are using IE 4. These people, presumably, were stranded on an island after their plane crashed. There they found a fall-out shelter with a computer that requires you to click a button every 108 minutes. This button reads “object expected in line 12.”

Thought I’d drop a note that there are a few bug fixes in the CNET common libraries that are worth downloading if you’re using our stuff.

• Modalizer - The overlay div that it creates has to be larger than the window space (only slightly). In IE, it eats memory when you create a div this large that is semi-transparent. Before I would create a new overlay every time you instantiated Modalizer, but now I reuse the layer. Note that it doesn’t leak this memory. As soon as you reload the page or browse elsewhere you get it back.
• string.cnet.js - re-implemented String.replaceAll() because String.replace(old, new, “ig”) doesn’t work in, you guessed it, IE. In IE, it would seem that you can’t pass in that third option (the regex options). If you want to replace something globally you have to do String.replace(/old/ig, new). String.replaceAll() does this for you (and lets you pass in regex options as a third and optional argument).
• StickyWinModal - this was calling the wrong hide method for the StickyWin instance and the result was that the iframe shim was left behind on the page.

Mootools 1.0 is out. Fancy new site design and docs.

We’ve already refactored all our code for 1.0, though it is not yet released to the CNET site. We’re entering into QA now…

I’ve also released the second part of my wiki tutorial series, this time giving working examples of all the CNET common code. The CNET Libraries are comprised of common code (widgets, shortcuts, etc.) and implementation code - code that is specific to a given page or application. The implementation code is usually just implementing and executing functions and libraries in the common portion of the library. The wikitorial for the CNET common code focuses on this generic content. Form validation, date pickers, carousels, etc. Dig in! Oh, and if you have a chance, Digg the tutorials, too. You’ll find shortcuts to do that in the right navigation column in the tutorials.

Just this morning I was pinging Valerio (author of Mootools) about a cheat sheet for Mootools after Snook posted his updated cheat sheet for Prototype 1.5. Funny thing; Snook posted a Mootools cheat sheet yesterday and it just hadn’t gotten to my inbox yet. Go Snook! I’m going to add this to our cvs library along with all our other docs and whatnot.

In the same vein as the Prototype Cheat Sheet, I decided to go through and detail the Mootools library, as well. In comparison to Prototype, Mootools is definitely smaller and it’s obvious they’ve put more focus on interactivity and decent DOM traversing.

I’ve colour-coded this one to match the four main categories that are in the download section of the web site and within the documentation. This way, it should hopefully be clearer when trying to compare against the two.

In going through things, I noticed that the documentation for Mootools isn’t bad but spelling mistakes and what not have meant that a couple features aren’t actually detailed in the documentation.

Anyways, for you Mootool luvin’ fans, here are the cheat sheets:

Downloads

• PDF [32k]
• PNG 1024×768 [111k]

Hi gang,

To go along with the posting of our collection of scripts, I’m still writing tutorials on how to make use of all our code. Today’s update is for all our extensions to the Mootools libraries that we’ve written.

You’ll find new helper functions, new extensions to ajax, string, element, window and more. For the most part, you can just drop these scripts into your environment and they should work. If there are dependencies, you can find them listed at the top of each script.

Hi gang,

I’ve been at work on a mootools primer as a tutorial for those who want to use the library but don’t know a lot about javascript. It’s replete with working code examples that you can execute right in the browser and see the result. | Read the rest »

Here’s a trick I learned from Valerio (author of Mootools) on how to handle options for classes and functions. After refactoring a couple of legacy scripts I thought I’d share for those of you who might not know it already. This example below uses the Mootools syntax for class creation, but the rest of it can be used even on its own I think. | Read the rest »

Bill Scott has a great article on designing a component that is worth a read. He talks about his rules of thumb when building something that should be reusable (and nearly everything should):

• Make the component specific in purpose, yet flexible in use.

Avoid the do-everything component. Instead make it do the main thing well. But make it pragmatic by keeping it flexible.

• Separate the concerns of interface, interaction, and content.

Avoid hard-coding visual style, give flexibility in the interaction model and provide flexible ways to manage data content. Keep these three areas independent to allow them to be customized separately.

• Document the interface and use the component before releasing it.

You know the experience. You think you have a great idea. Then when you go to explain it to another person you immediately see the holes in your logic. Documentation provides a way to explain your interface; writing demos allow you to exercise the component to test its ease of use and flexibility.

There's a lot more detail and examples in the full article.

This kind of thinking has had a big influence on my work on CNET's global framework and stumbling across this article just recently made me refocus my thoughts on the topic.

a.n.