Quick and easy:
if(fileType in {'jpg':'','gif':'','bmp':''}){ ... }
Create the Object you’re testing against on the fly. Seems that Object creation trumps in in the order of operations (at least in Firefox 3.0).
I ran into this one earlier today. Essentially, you use the Google Maps API’s GDirections object to load some directions into your map. Occasionally, without warning or any pattern I can see, the little blue-ish route polyline will begin disappearing in IE 6 and IE 7. There seems to be no rhyme or reason to it, although I suspect that it has to do with DOM modifications after the map redraws.
Speculation aside, here’s a fix that I dug out of the Google Maps API Group. Make sure your document is using a valid DOCTYPE (duh) and then add the following XML namespacing to your HTML tag:
<html xmlns=”http://www.w3.org/1999/xhtml” xmlns:v=”urn:schemas-
microsoft-com:vml”>
</html>
I didn’t have access to that part of the document as I’m working in a CMS, but found that this JavaScript version worked:
var el = document.getElementsByTagName('head')[0];
el.setAttribute('xmlns','http://www.w3.org/1999/xhtml');
el.setAttribute('xmlns:v', 'urn:schemas-microsoft-com:vml');
That should fix the problem. However, it may pop-up again if you clear the map results and any overlays you have, and plot points on that same map again. Really odd. Does Google clobber that namespace at some point, after centering or drawing a map? I haven’t been able to test to find out. My only thought would be to set those attributes after every redraw or map load, but that could be a bit of overkill.
Still, if you can promise only a single load of a set of directions, the above should save you. Here’s the Google Groups thread for posterity.
Just found a fantastic crash bug in the FireFox 2.0 line (I’m using 2.0.0.16 and it’s there). It seems to be fixed completely in FireFox 3.0 and up.
Basically, using Flash’s ExternalInterface to call a JavaScript function that removes the swf element from the DOM and also tries to set style properties on the element containing the swf is subject to timing issues (a race condition, really) that can cause a total browser crash. It seems to work this way: if the function called by external interface results in removing the swf before the calling function can execute all code inside it, the browser will bail out. (I’m not 100% sure if that’s the exact cause, but it seems to be supported by what testing I could do.)
How is this a problem? I was running a few animations that would call back a couple of times to closures inside them. If those closed functions wouldn’t have time to run before the swf was stripped out, things would explode. The solution: my final animation calls back and removes the swf; this seems to solve the problem entirely (as does removing the swf after a nice long callback that would ensure all the closure code completes). Perhaps this is a crazy bug that only shows up in this situation, with timing and closures? Like ExternalInterface needs all closures/JavaScript to execute before it can “safely” exit itself?
Very weird, but seems to be solved in later versions of Firefox. (By the way, I’m running Flash 9 and a swf that demands Flash 9, so it’s still a recent concern for newer versions of Flash.)
(Here’s a similar situation that got me in the right direction.
Tags: javascript, flash, external interface
The tradition of placing small, useful services on App Engine continues. This time, Adam Burmister has created img2json, a Google AppEngine service that extracts metadata from image URLs.The metadata can be as simple as width, height, mime type, file size, but it also extract EXIF metadata (camera make, manufacturer, GPS positioning, orientation, etc).
Ajaxian » img2json: get your image metadata via App Engine
Hmmm…using a web service vs. using a JavaScript-based, in-client approach. The webservice seems to be really fast and its based on Google’s distributed (?) app engine. I wonder if feeding this an asset that’s sitting on a content delivery network (Akamai, etc.) would combine with the Google’s App Engine speed to balance off loading that extra script? You’d still ostensibly need the same callback function.
Since you’re using a plain, old URL could you stuff the request URL in an img tag’s src attribute, then use the callback to do a quick swap once it loads? If so, that’s pretty darn effective. (I’d test it, but I’m lazy and kind of sure you’d see a broken image for a bit before it swaps in the good image; however, you could always set this up on a set of positioned or not-displayed images and achieve the same effect. I’m worried this would smack into the same origin policy and don’t want to do this on the server since it could be a blocking performance bottleneck.)
Nice to see App Engine paving the way for utility apps!
Tags: exif, images, javascript
IE6 in SP3 has the same version of jscript (@_jscript_version) number as IE7. (5.7 in this case). If you’re using jscript to target conditional compilation, heads up.
Tags: ie6, ie7, conditional compilation
Ever since Awesomebox closed down, I’ve been looking for a YUI-based lightbox script. Looks like I found it in Shadowbox. The best part: it’s completely library agnostic: you can use adapters to run it off any of the big libraries (YUI, jQuery, ext …).
It also aces the "hot lightbox opening animation test." Nice!
And on the side, a libary-agnostic app like this? About time! When are we going to stop seeing a billion different plugins in a billion different libraries and instead see one or two really great plugins that can run anywhere? I guess the limiting factor is the amount of time plugin authors can spend here. Wouldn’t a JavaScript library common architecture be something worthwhile: write it once, follow the plugin standards, and run it anywhere? How about it, library people???
I’ve been meaning to mention this for a while, but was waiting on a couple post-launch releases that added some “extras” that I liked.
NikonUSA.com was re-designed and re-built by my company, Molecular. We launched in late February and this was a total overhaul: new CMS (Interwoven LiveSite/TeamSite), new design, and plenty of custom code. I built the entire front-end here, from the overall architecture to writing XSL to build HTML to build pages.
There’s lots and lots of custom stuff I wrote from “Quick View” overlays to DOM stylesheet manipulations, and plenty of YUI, awesomebox, and yCarousel to go around, too.
Cool stuff to look for:
I’m most proud of being able to wrangle some nice, semantic HTML in there. The “AJAX” features feel natural, too, something I always like to do in an app: the lightboxes and carousel presentation makes sense and feels right in context; it doesn’t feel “bolted on”, like these flashy bits sometimes do. I can also now give dissertations on Flash/DHTML layering, ImageMagick, and many other cool things.
I may add a few posts describing bits and pieces of functionality in the future; the front-end here was huge, and I built a lot of stuff (and trained users, and designed pages…). But, it’s still a launch!
Tags: nikon, nikonusa, design, build, launch, javascript, html, flash
Here’s an experiment in keepings things small and confined to one Javascript file. There are no external image files or anything, everything is rendered with Javascript using either canvas elements or old fashioned div-making tactics (for IE). The sprites are stored in custom encoded strings in a format that only allows 4 colors for each sprite but in turn only takes up around 40-60 bytes per sprite.We also have MIDI music embedded as base64-encoded data: URI’s. No music for IE, though, and it seems all the other browsers each have different, minor problems with it, but it sort of works.
nihilogic: Super Mario in 14kB Javascript
!!!
Makes me think I should: a) be doing more with Canvas and b) be doing more with encoding data as strings.
Tags: javascript, examples, !flash
JavaScript is the world’s most misunderstood programming language, and even if we use them from about 10 years, there is still confusion about the basis of its prototypal inheritance nature.
JavaScript Prototypal Inheritance - My 5 Cents From Web Reflection
Andrea Giammarchi is a very smart guy, and this is a very good read of the inner-workings of JavaScript’s prototypal inheritance structure.
Tags: javascript, prototypal inheritance
My favourite AJAX ide Aptana still doesn’t support YUI 2.5 (latest stable version supports 2.3.1) so i decided to write a plugin for YUI 2.5.0,.. and i would like to share it with all of you guys … just download the YUI 2.5.0 plugin for Aptana and drop it in the plugins folder of Aptana, and restart Aptana.
YUI 2.5.0 plugin for Aptana | Gaurav Verma
Since Aptana’s own team is a bit behind, Gaurav Verma put together this little YUI 2.5.0 helper for Aptana. Now you can create a glorious YUI 2.5.0 project from the Aptana project wizard and enjoy all the benefits thereof.
