<meta name="user_id" content="1337" />
<meta name="user_name" content="Gary Barlow" />

I’m thinking core stuff like user ids which never change and get used again and again in ajax calls. Yes, you could achieve the same thing with cookie data, but if like me you like to keep the amount of data stored in cookies to the bare minimum, then this can be a nice little solution.

You can easily access these values like this:

var user_id = $("meta[name='user_id']").attr('content')

But eww, it’s pretty ugly, and ugly code makes Jamie a sad developer.

The following plugin simply provides a neat shorthand for accessing those variables. And I do like to keep things neat. It also caches by means of lazy-loading each meta contents into an internal object, so that the DOM is only traversed once. This is possibly overkill, and probably doesn’t save a single millisecond in any real-life scenario, but I like to optimise as I go and you can’t stop me.

(function($) {
$.meta = function(name) {
    if (typeof($.meta.cache[name])=='undefined'){
        $.meta.cache[name] = $("meta[name='"+name+"']").attr('content');
    }
    return $.meta.cache[name];
};
$.meta.cache = new Object;
})(jQuery);

You’re then free to access your variables neatly and concisely throughout your application using your new $.meta function.

$.post('path/to/someAjaxController', {method: 'doStuff', id: $.meta('user_id')}, function(r){
    alert('Thanks for doing stuff ' + $.meta('user_name'));
})

This isn’t to be confused with the existing and widely used jQuery Metadata Plugin which extracts meta data from DOM Elements. I should perhaps call this plugin something different, but to be honest I can’t think of a better name.

So to sum up. Ground-breaking? Not really. Useful? Yes.

IE7, don’t you just love it? What they gave us with one had in terms of CSS actually sort of working they took away with some of the stupidest niggly little bugs ever. Here’s another potentially large one i’m stumbled right into recently.

If your user agent string is more than 260 characters in length then your user agent string suddenly and almost magically becomes “Mozilla/4.0 (compatible; MSIE 6.0)”

Not what you’d expect to happen. Now, I know what your thinking. Why on god’s earth would your user agent string BE that long. The answer is simple. Toolbars and Spyware.

Toolbars and Spyware

The cool thing about Windows is that toolbars, spyware and crapware in general can and do add pointless shit to your Internet Explorer user agent string via the registry. Sounds good doesn’t it. Now consider the following:

1. Most store bough Windows PCs come pre-installed with tons of stupid toolbars and crapware
2. IE 7 isn’t much more secure than IE6 was in terms of spyware
3. Home users do not know or care about viruses and spyware

With me?

Try it yourself

You can easily trigger this bug yourself by editing the registry. Fire up regedit and navigate to HKLM/Software/Microsoft/Windows/CurrentVersion/Internet Settings/5./0User Agent/Post Platform. Create a new string key and fill up full of crap (enough to pass the 260 character threshold)

Next, close all instances of IE. Fire UP IE again and type the following into the address bar:

javascript:alert(navigator.userAgent)

Hit enter and IE7 should now tell you that it’s IE6. Awesome!

I firmly believe that this is one of the reasons behind problems such as the thickbox positioning bug that many people experience with IE7.

The workaround?

This is of course just another argument against relying on the user agent string to determine browser version. It really shouldn’t be done this way, yet it’s the method built into many JavaScript libraries including jQuery with it’s unreliable $.browser.version property.

If you really need to know if a browser is IE6 or IE7 then use something more solid like object detection. Simply testing for something like the following would be a better option than extracting unreliable data from the user agent string

A possible patch below redefines the browser version as “7.0″ only if the browser has already been identified as IE6 and the the presence of the XMLHttpRequest object suggests otherwise.

if(jQuery.browser.msie && parseInt(jQuery.browser.version) == 6 && this.XMLHttpRequest) {
	jQuery.browser.version = "7.0"
}

I’m thinking though that maybe this might not be bulletproof. If IE8 presents the same or similar “Hi i’m IE6!” behaviour then the above patch could incorrectly identify IE8 as IE7. This might not be as serious as IE7 vs. IE6 but it’s still an issue.

I just wish that Microsoft would put a bit more effort into writing good software. It’s not like they don’t have the resources.

The CSS includes rules for “.ui-tabs-nav-item” but these classes are never added to the list items by the plugin. Because they are unnecessary.

Simply changing the rules to “.ui-tabs-nav li” they way they should be brings it all into line again. Except the extra specificity overrides the “.ui-tabs-selected” rules. These need changing to “.ui-tabs-nav li.ui-tabs-selected” and Bob’s your monkey’s uncle.

There doesn’t appear to be a whole lot of consistency (or good CSS) rolling around the JQuery UI project at the moment. Hopefully this will improve. I was of the belief that a theme could be “dropped onto” a jQuery UI app to simply re-skin it. This isn’t the case. Not yet at least.

For the time being I think i’ll be sticking to good old fashioned hand written CSS

But what if you just want to use .getScript to programatically include parts of your application logic only where necessary (aka Lazy Loading), or you simply want to defer the execution of a non-essential plugin or two until a couple of seconds after the DOM becomes available. You’d want those scripts cached as if you’d hard-coded them into script tags right? I guess.

Can’t Cache, Won’t Cache (with Ainsley Harriott)

There’s no way you can send cache control options into getScript. It simply doesn’t accept any. getScript is merely a wrapper around .get which itself does not provide options for controlling caching. I’m not sure whether or not this is an oversight on the part of the developers. Feel free to shoot me down in flames if i’m spectacularly missing some glaringly obvious point here.

It’s not a problem though. .get is itslef just a simple wrapper around .ajax which publicly exposes all of jQuery’s AJAXy goodness. As such there’s absolutely no reason why you can’t just redefine JQuery.getScript to accept an optional boolean argument for cache control. That’s the beauty of jQuery.

jQuery.getScript Redefined

$.getScript = function(url, callback, cache){
	$.ajax({
			type: "GET",
			url: url,
			success: callback,
			dataType: "script",
			cache: cache
	});
};

This won’t break any existing code which references the function as omitting the cache argument defaults caching to false as per the original functionality. But if you want to allow caching you now have that option.

The Network Detection Object

The basic premise is very simple. We create an instance of a network detection object which will poll a URL at regular intervals. Should these HTTP requests fail we can assume that network connectivity has been lost, or the server is simply unreachable at the current time.

$.networkDetection = function(url,interval){
	var url = url;
	var interval = interval;
	online = false;
	this.StartPolling = function(){
		this.StopPolling();
		this.timer = setInterval(poll, interval);
	};
	this.StopPolling = function(){
		clearInterval(this.timer);
	};
	this.setPollInterval= function(i) {
		interval = i;
	};
	this.getOnlineStatus = function(){
		return online;
	};
	function poll() {
		$.ajax({
			type: "POST",
			url: url,
			dataType: "text",
			error: function(){
				online = false;
				$(document).trigger('status.networkDetection',[false]);
			},
			success: function(){
				online = true;
				$(document).trigger('status.networkDetection',[true]);
			}
		});
	};
};

You can view the demo here. Set your browser to work offline and see what happens…. no, it’s not very exciting.

Trigger and Bind

What is exciting though (or at least what is exciting me) is the method by which the status gets relayed through the application. I’ve stumbled upon a largely un-discussed method of implementing a pub/sub system using jQuery’s trigger and bind methods.

The demo code is more obtuse than it need to be. The network detection object publishes ’status ‘events to the document which actively listens for them and in turn publishes ‘notify’ events to all subscribers (more on those later). The reasoning behind this is that in a real world application there would probably be some more logic controlling when and how the ‘notify’ events are published.

$(document).bind("status.networkDetection", function(e, status){
	// subscribers can be namespaced with multiple classes
	subscribers = $('.subscriber.networkDetection');
	// publish notify.networkDetection even to subscribers
	subscribers.trigger("notify.networkDetection", [status])
	/*
	other logic based on network connectivity could go here
	use google gears offline storage etc
	maybe trigger some other events
	*/
});

Because of jQuery’s DOM centric approach events are published to (triggered on) DOM elements. This can be the window or document object for general events or you can generate a jQuery object using a selector. The approach i’ve taken with the demo is to create an almost namespaced approach to defining subscribers.

DOM elements which are to be subscribers are classed simply with “subscriber” and “networkDetection”. We can then publish events only to these elements (of which there is only one in the demo) by triggering a notify event on $(“.subscriber.networkDetection”)

The #notifier div which is part of the .subscriber.networkDetection group of subscribers then has an anonymous function bound to it, effectively acting as a listener.

$('#notifier').bind("notify.networkDetection",function(e, online){
	// the following simply demonstrates
	notifier = $(this);
	if(online){
		if (!notifier.hasClass("online")){
			$(this)
				.addClass("online")
				.removeClass("offline")
				.text("ONLINE");
		}
	}else{
		if (!notifier.hasClass("offline")){
			$(this)
				.addClass("offline")
				.removeClass("online")
				.text("OFFLINE");
		}
	};
});

So, there you go. It’s all pretty verbose and my example isn’t at all exciting. It also doesn’t showcase anything interesting you could do with these methods, but if anyone’s at all interested to dig through the source feel free. All the code is inline in the head of the demo page

There are the usual number of pitfalls you’d expect when integrating [insert widely-used microsoft technology here] with [insert useful open source technology here]

Want to consume a JSON Web Service with jQuery? Sounds simple. That’s kinda the point of JSON right? Well yeah, but no. Everything’s workaroundable and to be fair it isn’t all Microsoft’s fault… ok so most of it is.

I’m gonna be starting a large scale ASP.NET / jQuery / ExtJS project in the very near future and Dave’s short guide has probably just saved me several hours if not a whole day of figuring out all the lumps and bumps myself.

ga.js has all the capabilities of urchin.js but is structured in a fully Object oriented way. The new API has some nice new functionality which among other things allows for tracking of e-commerce transactions, which is pretty exciting. If you like that sorta thing.

I’ve quickly modified gaTracker to utilise the new API and call it’s _trackPageview() method rather than using urchinTracker(). The code is available below:

jquery.gatracker.js (Tracking API version)

It works in exactly the same way as the gaTracker 1.0.1 release, and can be dropped in it’s place, but utilises the new tracking API. Feel free to grab a copy until support gets built into the official release.

Currently it’s a work in progress and utilizes an extended version of Stewart’s Dynamic Heading Generator PHP script. The plugin will attempt to replace the text of an element such as a heading with text generated in a specified font in the same colour and size as specified in the CSS. It will generate one image per word allowing word-wrap to occur.

There is currently a known issue with IE (all versions) when using jitr with em based font sizes. Internet Explorer reports a size which does not represent the equivalent font size in pixels.

Syntax:

jitr(String fontfilename, String backgroundColor)

jitr returns the jQuery object so that it can be chained.

There is currently however one major part of the process which lies outside of the plugin. To avoid a flicker of unstyled content on document.ready, it is necessary to include a stylesheet (hide.css) which sets the elements which are to be replaced to have ‘visibility: hidden’. As each element is image replaced, it’s CSS visibility is reset to visible.

Example hide.css

h1, h2, h3 {
	visibility:hidden;
}

Simply including this stylesheet in the head would have adverse side-effects for visitors without JavaScript though. The CSS above would hide all the headings and the plugin, not being run, would not then reset them to visible. I have decided for the time being that the only solution i can see which will work, although slightly clunky is to use a document.write to include hide.css only when JavaScript is enabled.

<script type="text/javascript">
    document.write('<link rel="stylesheet" href="/path/to/hide.css" ' +
    'type="text/css" media="screen" />');
</script>

As previously mentioned in this post Thickbox 3.1 is currently broken in many revisions of Internet Explorer 7. Specifically, those revisions who return the substring “MSIE 6.0″ in the user-agent string.

Update: July 2008

This patch fixes a problem caused when certain installations of IE7 are incorrectly identified as IE6 causing the thickbox window to be positioned partially hidden in the top left hand corner of the viewport . It has become apparent that there are other bugs triggered in other revisions of IE7 which cause another type of miss-positioning with the thickbox window being centered correctly but outside of the viewport. This patch doesn’t fix that

As this is such a widespread problem, and lots of people seem to be having a little difficulty patching their copies of thickbox.js I thought i’d provide a patched copy here. But first a bit of background for those who are interested in why it’s broken. The following if statement in the function tb_position is as follows:

thickbox.js line 284

if ( !(jQuery.browser.msie && jQuery.browser.version < 7)) { // take away IE6
    $("#TB_window").css({marginTop: '-' + parseInt((TB_HEIGHT / 2),10) + 'px'});
}

The bug is triggered when, in certain revisions of IE7 jQuery.browser.version == 6, resulting in the Thickbox window not receiving the correct CSS positioning. (In IE6, the window receives it position through some clever CSS expressions in thickbox.css)

The workaround for all this though is fairly straightforward. You simply need a more accurate way for weeding out IE6... and here it is.

$.browser.msie6

$.browser.msie6 =
    $.browser.msie
    && /MSIE 6\.0/i.test(window.navigator.userAgent)
    && !/MSIE 7\.0/i.test(window.navigator.userAgent);

Once we have this new property defined within the $.browser object we can use it to fix the conditional statement mentioned previously. You can define $.browser.msie6 in thickbox.js (like i have in the patched copies of thickbox below), or patch jQuery itself. Or whatever. It's up to you. After that all that needs to be done is to modify the following line to make use of our new IE6 sniffer:

thickbox.js line 284

if ( !(jQuery.browser.msie6)) { // take away IE6
    $("#TB_window").css({marginTop: '-' + parseInt((TB_HEIGHT / 2),10) + 'px'});
}

If you don't feel confident patching your own copy of thickbox then feel free to grab a patched copy below. This is thickbox 3.1 with the abovementioned code modifications applied and should simply replace your existing file.

• thickbox.patch.js
• thickbox.patch.pack.js

Let me know if you find this useful

The problem can be circumvented to applying css rules directly to the element(s) in question.

// This will fail in Safari
$(element).hide()
// But this will work
$(element).css('display','none')

A quick google reveals that lot’s of people have come across this same issue, but no definitive answers.

]]> http://jamiethompson.co.uk/web/2008/03/17/jquery-hideshow-safari-bug/feed/ 7