It starts off by talking about lazily loading code via the old favorites of adding a <script> to the DOM, or XHR+eval, but then it gets beyond the typical and discusses the nuance of mobile + offline caching. The hack that is used, is another oldie.... which is to hide the script and eval it later:

For an HTML 5 application that takes advantage of the application cache to reduce startup latency and to serve the application offline, there are a few caveats one should be aware of. Mobile networks have decent bandwidth, but poor round trip latency, so listing each module as a separate resource in the manifest incurs quite a bit of extra startup latency when the application cache is empty. Also, if one of the module resources fails to be downloaded by the application cache (e.g. disconnected from network), additional error handling code needs to be written to handle such a case. Finally, applications today have no control when the application cache decides to download the resources in the manifest (such a feature is not defined in the current specification of the draft standard). Typically, resources are downloaded once the main page is loaded, but that's not an ideal time since that's when the application requests user data.

To work-around these caveats, we found a trick that allows you to bundle all of your modules into a single resource without having to parse any of the JavaScript. Of course, with this strategy, there is greater latency with the initial download of the single resource (since it has all your JavaScript modules), but once the resource is stored in the browser's application cache, this issue becomes much less of a factor.

To combine all modules into a single resource, we wrote each module into a separate script tag and hid the code inside a comment block (/* */). When the resource first loads, none of the code is parsed since it is commented out. To load a module, find the DOM element for the corresponding script tag, strip out the comment block, and eval() the code. If the web app supports XHTML, this trick is even more elegant as the modules can be hidden inside a CDATA tag instead of a script tag. An added bonus is the ability to lazy load your modules synchronously since there's no longer a need to fetch the modules asynchronously over the network.

On an iPhone 2.2 device, 200k of JavaScript held within a block comment adds 240ms during page load, whereas 200k of JavaScript that is parsed during page load added 2600 ms. That's more than a 10x reduction in startup latency by eliminating 200k of unneeded JavaScript during page load! Take a look at the code sample below to see how this is done.

PLAIN TEXT

HTML:

1.  
2. <script id="lazy">
3. // Make sure you strip out (or replace) comment blocks in your JavaScript first.
4. /*
5. JavaScript of lazy module
6. */
7. </script>
8.  
9. <script>
10.   function lazyLoad() {
11.     var lazyElement = document.getElementById('lazy');
12.     var lazyElementBody = lazyElement.innerHTML;
13.     var jsCode = stripOutCommentBlock(lazyElementBody);
14.     eval(jsCode);
15.   }
16. </script>
17.  

In the future, we hope that the HTML5 standard will allow more control over when the application cache should download resources in the manifest, since using comments to pass along code is not elegant but worked nicely for us.

FireCrystal is a Firefox extension that helps designers and programmers alike figure out how interactive behaviors on the web work. FireCrystal allows users to record and rewind their interactions with web pages while showing the relevant code.

and converts it to:

all via the CSS:

Yup, even IE.

Andrea Giammarchi had his own post on encodings in a different way.... as he talked about
en-code which you can check out in action here on the page that lets you do simple encodings, especially for source code, in short order.

He has included a test page and you can view the different browsers via browsershots.

Finally, he links to another concise list... of JavaScript sniffs.

He has a nice little tip on the many syntaxes that you can use to iterate over arrays in various JavaScript implementations and standards. Some folks had some interesting points on the various approaches:

for each in:

PLAIN TEXT

JAVASCRIPT:

1.  
2. for each (var item in [1, 2, 3]) alert(item);
3.  

The MDC docs for "for each" say not to iterate arrays that way, too, so I never use it on them. The usual (would need to guard with hasOwnProperty() issue).

JavaScript 1.6 added the Array.forEach method:

PLAIN TEXT

JAVASCRIPT:

1.  
2. [1, 2, 3].forEach(function(item) { alert(item) });
3.  

JavaScript 1.7 added array comprehensions for array initialization:

PLAIN TEXT

JAVASCRIPT:

1.  
2. var squares = [item * item for each (item in [1, 2, 3])];
3.  

I just realized I can (ab)use comprehensions to iterate arrays with Perl-like syntax by throwing away the result:

PLAIN TEXT

JAVASCRIPT:

1.  
2. [alert(item) for each (item in [1, 2, 3])];
3.  

I can iterate object properties the same way:

PLAIN TEXT

JAVASCRIPT:

1.  
2. var obj = { foo: 1, bar: 2, baz: 3 };
3. [alert(name + "=" + obj[name]) for (name in obj)];
4.  

Edward Lee points out how to use Iterators:

PLAIN TEXT

JAVASCRIPT:

1.  
2. [alert(key + "=" + val) for ([key, val] in Iterator({a:1,b:2,c:3}))]
3.  

Along with this, he put up a simple test case that you can point at.

When you care about performance, or SEO (or just doing a good job as web dev) an interesting data point is the ratio of page content vs. the markup used to present this content. Or... how much crap we put in HTML in order to present what the users want to see - the content.

So I played tonight with a bookmarklet to provide this piece of stats.

The bookmarklet code is served from here. The code is also on github.

And some fun results:

Here are some random results of running the bookmarklet on different sites.

http://www.cnn.com:
Total size: 92004 bytes
Content size: 11475 bytes
Content-to-markup ratio: 0.12
Fair ratio * : 0.16

http://www.sitepoint.com

Total size: 65989 bytes
Content size: 16199 bytes
Content-to-markup ratio: 0.25
Fair ratio * : 0.60

Article on http://en.wikipedia.org:
Total size: 21648 bytes
Content size: 3315 bytes
Content-to-markup ratio: 0.15
Fair ratio * : 0.35

http://www.phpied.com
Total size: 31899 bytes
Content size: 7933 bytes
Content-to-markup ratio: 0.25
Fair ratio * : 0.48

http://www.google.com SERP
Total size: 29963 bytes
Content size: 3351 bytes
Content-to-markup ratio: 0.11
Fair ratio * : 0.14

He also realized that the core piece of the bookmarklet is actually a nice view of the power of Prototype as a library:

Jacob is back, and this time he has a cheat sheet with him. It is nice to see the Canvas API fitting on one sheet here, and I really like the images showing how things look like and work.

That is the current winner in the shortest way to test for IE (including 8). The other notable was:

Huh :)

Gareth Heyes (the chap who did the v trick) has posted on this himself and comes up with One Line To Rule Them All:

This is a fun little hack by Manfred Staudinger.

Thanks to select="system-property('xsl:vendor')", he has a style sheet that allows you to show items depending on the browser:

To include a link or a style element for one of the above choices you use the dr:select attribute and specify one or more tokens as a comma separated list. For example dr:select="Firefox, Safari 3" will cause the link or style element to be included for any Firefox and for Safari 3. If you specify more than one token, each of which constitutes a positive selection, you may use any combination of tokens from the non-IE browsers plus the token "IE".

To select a specific IE only one token in the dr:select attribute is allowed, because it is directly used in constructing a Conditional Comment (CC). These are constructed on the fly only if the current browser is actually an IE. Any valid CC expression is allowed, so you can specify for example dr:select="lte IE 7" (positive selection) or dr:select="!IE 6" (negative selection). To clarify, a positive CC selection will allow only the IE's specified to read the CSS, and a negative CC will exclude them from seeing it. The best, you don't need anymore to include Microsoft proprietary CC's for selecting CSS in your HTML!

Link and style elements without a dr:select attribute are considered common stylesheets which every browser will see. They will remain unchanged, as any other HTML element. Only the dr:select attributes will be nullified.

You could do this when JavaScript isn't enabled for example.... although I am not sure how practical it actually is :)

"Ethan" has a really nicely packaged set of web resources that he uses.

From JavaScript core libraries, to widgets, to tools, to CSS frameworks, to CSS techniques, to browser compatibility, to typography, to extensions, and much much more. Nicely done.

This is an update to the Script.aculo.us forceRerendering so it will probably be in Scripty 2? :)

Sebastian of Qooxdoo had a similar technique:

You may also use some kind of addClass/removeClass combo. That would result into the same effect but without creating unused DOM elements. We use this method in qooxdoo and it works well.

Do you run into these issues?

Guid0 is a GUID library for Javascript. Okay, it doesn't yet do official, bona fide, 128-bit, GUIDs yet, mainly for API design reasons. But this is a library you might find useful if you want to generate a unique ID in your Ajax app.

PLAIN TEXT

JAVASCRIPT:

1.  
2. // simple
3. guid = new Guid();
4. var newguid = guid.generate();
5.  
6. // options
7. guid = new Guid(
8.   {
9.         chars: Guid.constants.base85,  // or you could say "abc" if you only wanted those chars to appear
10.         epoch: "June 1, 2003",
11.         counterSequenceLength: 2, // a counter field appended to the end
12.         randomSequenceLength: 2 // a random field appended to the end
13.   }
14. );
15.  

He is working on 128-bit support.

“How many thousands of developer hours have been lost to random IE bugs like this?” I asked myself. I decided that there had to be a good way to detect this problem in an automated way, without firing up a copy of IE and running a full test suite.

It turns out that these and other syntax errors can be detected automatically from the Windows command line, using the Windows Scripting Host (WSH). On Windows XP and higher, the command-line tool “cscript.exe” can be used to run JavaScript (ahem, JScript) headlessly (outside of any browser).

Just create a file called “wsh-parser.js” like this:

PLAIN TEXT

JAVASCRIPT:

1.  
2. var fso = new ActiveXObject( "Scripting.FileSystemObject" );
3.  
4. function parse(fname) {
5.     var file = fso.OpenTextFile( fname, 1 );
6.     ret = file.ReadAll();
7.     file.Close();
8.     try {
9.         eval("(function(){\n"+ret+"\n});");
10.     } catch (e) {
11.         WScript.Echo("Syntax error parsing " + fname);
12.         WScript.Echo("  " + e.message);
13.     }
14. }
15.  
16. function findJavaScript(folder) {
17.     for (var fc = new Enumerator(folder.files); !fc.atEnd(); fc.moveNext()) {
18.         var file=fc.item();
19.         if (/.js$/.test(file.Name)) {
20.             parse(file);
21.         }
22.     }
23.     for (var fc = new Enumerator(folder.subfolders); !fc.atEnd(); fc.moveNext()) {
24.         var subfolder = fc.item();
25.         if (subfolder.Name == ".svn") continue; // ignore .svn folders
26.         findJavaScript(subfolder);
27.     }
28. }
29.  
30. var rootPath = "src/main/javascript";
31. var rootFolder = fso.GetFolder(rootPath);
32.  
33. findJavaScript(rootFolder);
34.  

Other tools will help you hunt this down too, and I am sure some of you have Perl/Ruby/Python one liners to do the same ;)

We keep our IE related styling right below the common (standards-based) declarations. BUT, we DON’T use hacks. Underscore hacks, * hacks, and all of those things that we all gave up with the birth of IE7 should remain dead and buried. Instead, we’re going to use IE’s conditional commenting to create IE specific CSS selectors. We do this by adding a conditional comment block as the outer most wrapper in our html template (ie. the first tag inside the ).

PLAIN TEXT

HTML:

1.  
2.   </body><body>
3.      <!--[if IE 7]><div id="body1" class="IE IE7 IE67"><![endif]-->
4.      <!--[if IE 6]><div id="body1" class="IE IE6 IE56 IE67"><![endif]-->
5.      <!--[if IE 5]><div id="body1" class="IE IE5 IE56"><![endif]-->
6.      <!--[if !IE]>-->
7.           <div id="body1" class="W3C">
8.      <!--<![endif]-->
9.                 /* THE REST OF YOUR HTML GOES HERE */
10.           </div>   
11.   </div></div></div></body> 
12.  

Now, in this sample, we do have support for older legacy versions of IE, so you could always reduce the number of conditions if your project doesn’t need this level of support. And, you could also easily extend it to include IE8, or to do minus versioning such as IE8-.

With this conditional block in place, it becomes quite easy to place IE only style declarations right below their standards-based counterparts. As an example:

PLAIN TEXT

CSS:

1.  
2. #header { overflow: hidden; }
3. .IE #header { zoom: 1; }
4.  

All you have to do is make sure that the image is display: block and has a padding.

He put up a simple demo that uses a div with an image, and he applies backgrounds to both:

You have the little chap running as the actual src of the image, the animated background as the img background, and then the sky background applied to the div.

Once in place, you simple do your usual link, and asynchronously the Web page will be updated to look like "your pdf link (pdf 2.8 MB)".

Check out the sample and pull up a print preview. He details the good, bad, and ugly:

The Good

The first step to getting a printable watermark is to use an inline tag, rather than background-images. In most browsers, background-images won’t be printed unless the user selects an additional browser option to enable it.

From here, we need to place the watermark image so that it is repeated on each page. It looks like the W3C thought of this ahead of time in the positioning module. The position property’s fixed value should ensure that a watermark is printed on each page. Some browsers, like FireFox and Internet Explorer 7, apply this rule correctly.

The Bad

Not all browsers play nicely with position:fixed and we haven’t yet considered using z-indexing to ensure the watermark displays behind all the regular page content. For IE and FireFox 3+, simply applying z-index:-1 to the watermark will do the trick.

Though, it turns out that earlier versions of FireFox (and other Gecko-based browsers) don’t play nicely with negative z-indexing. So, my current approach uses a few Gecko-specific hacks to degrade the watermark approach for FireFox 2. For FireFox 2, the watermark will display over the content, but still display on every page. Unfortunately, this means the CSS for my approach doesn’t validate.

The Ugly

But of course, position:fixed isn’t supported at all in IE6; it appears to ignore the rule altogether and display the image inline. So, I use conditional comments to filter just a *few* IE6-specific hacks:

Absolute positioning and an additional 100% height on the watermark and printable content are the keys to getting this working for IE6:

div.watermark{
position:absolute;
overflow:hidden;
}
div.content{
height:100%;

}