Cached images have no width or height in webkit (e.g. Chrome or Safari)
Stackoverflow (SO) has always been a handy resource. Today I noticed a particularly valuable comment with 0 votes.
I created an SO account with the explicit purpose of voting this comment upwards, but unfortunately, I have no reputation on SO, and am not able to do this (yet).
For lack of a better way to credit JKS for his insightful solution I thought I’d recognise it here.
In webkit browsers (e.g: Chrome or Safari) the
onload event fires for both cached and non-cached images, but images loading from cache seem to return dimensions of
JKS proposes a simple solution, a seemingly redundant
setTimeout before taking your measurements seems to magically restore cached image dimensions. In jQuery, that would look like this:
// do something based on $('img').width and/or $('img').height
Thanks again to JKS for the tip!
Cache manifests and Firefox
I’ve been playing with offline web applications this afternoon. Generally, it’s pretty straightforward:
- Reference your manifest file in the
<html> tag of each page.
- Fill out your
.manifest file with the relevant resources you want to be cached and available offline.
- Configure your server to serve
.manifest files at
Most browsers picked this up fine (tested: Opera 11, Chrome 7, Mobile Safari iOS 4.3), but unfortunately I ran into…
Firefox (tested: 3.6.13 and 4.0b11) refused to pull resources back from appCache—even though it reported successfully caching 175kB of data—or request any resources that weren’t cached. Firefox just presented the plain HTML for each pages without loading images, stylesheets, scripts or any other assets.
After much searching and trial and error, I came across a recommendation on stackoverflow to use
http://* within the
NETWORK section of the manifest for the sake of Firefox, and sure enough…
Final code samples as follows…
# etc ...
Apache configuration (
# Ensure manifests are served using the correct mime type
AddType text/cache-manifest .manifest
Thanks to dalibor for pointing out that
http://* is required for Firefox.
One other handy resource is Mark Pilgrim‘s Let’s take this offline, and if it had mentioned
http://* it would have been perfect!
unrecognized expression: #
I’ve tried to use one of my own jQuery plugins—that I know works—only to receive the following console messages without any reference to a code line number, hence no way to track down the culprit:
uncaught exception: Syntax error, unrecognized expression: #
I’m sure this has caught me out a number of times. Each time is far enough apart that I have forgotten how I debugged the issue previously. And each time I search the interwebs in vain. No one seems to have clearly explained what causes this exception!
Next time I encounter this problem, hopefully I remember—or find—this post, solution follows…
This exception is thrown by jQuery when you ask it to resolve the selector
'#' without an
id following. In my case it is often caused by my plugin code assuming an element has an
id. If the element doesn’t have an
id, the exception is thrown, for example:
var storedID = $(this).attr('id');
this doesn’t have an
id, I’ve essentially asked jQuery to resolve the following:
Which jQuery doesn’t like to do, hence the exception.
Finally got around to fixing my corrupt zip file issues. Fresh and flawless zip files are now available for the latest versions of all widgets and plugins.
BTW the compact content plugins have been updated with a bunch of small fixes (IE6 benefits the most from this release). See new examples, downloads and changelog for version 3.5.
Test support for short URL auto-discovery
Short URL autodiscovery sounds like a good idea to me. The easiest way for a developer to integrate this mechanism is to use the link element in your document’s
<link rel="shorturl" href="http://irama.org/673" />
Or if you are using WordPress there are few handy plugins that do this automatically (for example: Short link maker and Shorter links).
But who’s going to know you’ve gone to all this trouble? How far has support for auto-discovery penetrated? I think it would be great if social media client applications would offer my short URL to users when they choose to shorten URLs within their posts, but I can’t find much documentation about which if any apps will pick up and use short URLs exposed in this way.
Go forth and test
This post can serve as a test, and a collection point for data, leave a comment if you have tested a new client application (include the version if known), and I’ll do the same.