The following guide came about after I was tasked with transferring my Web Development expertise into two VB developer colleagues. No mean feat in the one month I have left at my current place of work. Ultimately it’s possibly a futile task, but it’s worth a shot.

Web Development is not just collection of related technologies. It’s a state of mind, and in that respect it is very much like Yorkshire.

What follows is aimed at existing developers (VB or otherwise) looking to move into Web Development. The advice I offer is that of best practice in the field of Web Development. The books suggested are generally those which I have read myself that or that come highly recommended by friends and colleagues of mine.

What is a Web Developer?

A web developer is a software developer or software engineer who is specifically engaged in the development of World Wide Web applications, or distributed network applications that are run over the HTTP protocol from a web server to a web browser. Many web developers are also skilled in related areas such as web design, information architecture, usability engineering, web content management systems, web server administration, database administration, software engineering, project management, network security, and search engine optimization.

Developers often specialize in either front-end or back-end work. Frontend developers tend to focus on the client-side and typically work with technologies such as markup languages, ECMAscript and its variants (JavaScript, JScript, ActionScript), CSS, and the DOM. Backend developers usually focus on the interaction between server-side frameworks using Perl, Python, Ruby, PHP, JSP, or .NET and databases. Some back-end developers maintain databases directly on their web servers, while in other situations the backend developer calls data, managed by a database administrator, on an external system.

- Wikipedia

In my experience the statement about specialization comes into play more within larger organisations. Small to medium enterprises tend to look for generic web developers with a grounding in one or maybe two server-side frameworks as well as an understanding of (X)HTML / CSS and JavaScript. Generally speaking, most web developers begin their careers within smaller organisations, and while it is not always the case, you will tend to find a large degree of overlap between front-end and back-end web developers for this very reason.

The Right Tools for The Job

There was a time when the in thing was to use a WYSIWYG editor to design and develop websites. Those days have gone (Microsoft please pay attention! Visual Web Developer 2008? OMGWTFDONOTWANT!!*). Dreamweaver, whilst it’s design view should be used for nothing more than ridicule, is a perfectly adequate syntax highlighting code editor for web development. It also has the benefit of it’s built in FTP client which is very handy. What you use to edit your code is entirely a personal preference. Something with syntax highlighting and brace matching will save you time by helping you to work faster. Some options include:

• Notepad++ – Windows – Open source syntax highlighting code editor, many plugins available including an FTP client (compatible with Wine.. sort of)
• Aptana Studio – Windows/Mac/Linux – Eclipse based editor with an invaluable PHP debugger plugin as well as working nicely with html/css/javascript right out the box
• Notepad – Windows – included with any copy of Microsoft Windows (There’s no reason that, at a push you can’t ply your trade with this trusty tool)
• Dreamweaver – You should be familiar with it if nothing else. For some reason your employer might INSIST that you use it.

Mozilla Firefox is an excellent developer’s browser, and with the following plugins installed is close to a perfect development environment.

• Web Developer Plugin
• Firebug
• Firecookie
• ColorZilla
• HTML Validator

For testing in multiple versions of Internet Explorer in Windows, IETester is an invaluable tool. IEs4Linux is handy for linux based development environments but there’s not substitute for running virtual machines with differing OS/Browser setups to cover all bases. It is also a good idea to invest in a Mac of some description for testing purposes.

* To avoid confusion, the budding Web Developer should attempt to learn lolcat

First Things First

Your first task is to forget everything you think you know about Web Development. Forget Dreamweaver (for now). Please forget Frontpage. Don’t even THINK about cranking up Visual Studio, it isn’t a web development tool despite what Microsoft might tell you. To be sucessful in web development whether you plan to move into front-end or back-end development or even if you just want to be a competent web designer you need to start from the ground up. That’s HTML and CSS.

Knowing (X)HTML inside out is not an option. You cannot skip this step. CSS guru status is possibly optional for those in a soley back-end role where presentation and layout are the consideration of a front-end developer. Even so, I would argue that there’s no excuse for not learning at least the basic principles of CSS. Whether you’re a designer designing for the web, a front-end developer implementing the designs of others, or a back-end developer providing the business logic behind someone else’s front-end, you should always strive to fully understand the medium in which you’re working and the way in which your design patterns impact on others.

It is possible to grasp the fundamentals of designing for the web in XHTML and CSS in a fairly short space of time. I know this from experience after watching a colleague of mine, a talented graphic designer, learn web design from the ground up simply by reading and trial and error over the course of several months. Of course, it goes without saying that the intricacies of cross browser compatibility can take years to fully master, and in this respect there is no substitute for the wealth of experience gained over time fixing one mind numbing IE6 bug after another, over and over and over again, until your eyes start to bleed and what’s left of your brain trickles out of your nose. One year and a bit later Rick is still a talented graphic designer but one who makes my life all the more bearable by chopping up his own designs and turning them into perfectly semantic valid XHTML and CSS. All it takes is patience and a thirst for knowledge.

The Fundamentals

Broadly speaking a page on the World Wide Web consists of

• Markup – HTML or XHMTL – The bare-bones of the page structure and it’s content
• Style - CSS – colors, fonts, layout etc
• Client-side logic – JavaScript – how the page deals with complex user interaction.

Marking it up

The only possible starting point is to learn to write markup. Markup is what defines the structure of the pages which make up the web. A common misconception, and one that’s more commonly held by those already within the IT industry is that there are many different technologies for displaying pages on the web. Whether the url of your page ends in .html, .asp, .php or one of a multitude of other extensions, the page that you see is your web browsers interpretation of some (X)HTML markup (hopefully) in conjunction with some CSS. The important thing to remember is that no matter what technology is used on the server-side to generate a web page, the web page is self never amounts to anything more than some HTML and CSS. We’ll touch on JavaScript later on but for now we’ll pretend that it doesn’t exist. So I have to say sorry to all you .NET developers but I’m afraid that ASP.NET pages really aren’t some kind of magical in-browser .NET application. It’s an illusion created by Visual Studio, Some poorly auto-generated HTML forms and a heap of really bad old-school JavaScript.

The standards for (X)HTML markup are set out by the W3C (World Wide Web Consortium). As a Web Developer you should strive for as much as much of your (X)HTML to validate against the doctype you specify; and you should ALWAYS declare a doctype (or the sky catch fire). You should validate your markup regularly during development and before release. Having a HTML validator built into your browser (such as Firefox) saves a lot of time in this respect. One of the best resources for learning the fundamentals of HTML and CSS is htmldog.com, whether you’re a total n00b or you’re halfway proficient in the basics already they seem to have tutorials and reference to suit. W3Schools is also a very good (but ugly) source of quick reference for pretty much all web technologies including HTML, CSS, JavaScript and most major server-side languages.

If you’re planning on heading down the .NET route of Web Development (and there’s nothing wrong with that), it’s imperative that you fully understand the concepts of semantic, valid HTML, pure CSS layouts as well as good JavaScript practices before you even open Visual Studio. That way you’ll have a solid understanding of which features of ASP.NET to take advantage of and which you need to avoid like the plague.

It is one thing to understand HTML, it is quite another to write semantic HTML and express context and meaning through markup. I would suggest reading up on the subject of semantic markup before going any further as a solid understanding of these principles will make the transition into the dark world of CSS much less painful.

Reference:

www.htmldog.com – HTML and CSS Tutorials
www.W3Schools.com – Web Technologies Reference Guides
www.w3.org/Consortium – About the W3C

Books:

HTML Mastery

Cascading Style Sheets

Style on the web is achieved using Cascading Style Sheets. An in depth guide to CSS is beyond the scope of this article but if HTML is the cake then you can think of CSS as the icing. CSS allows you to take your plain, u-nstyled, semantic markup and skin it anyway you choose without affecting it’s content or structure. Every presentational element of a website design can be achieved using CSS and CSS should be your only method of styling markup.

CSS support across browsers is inconsistent. Different browsers will render valid CSS in wildly different ways to each other, and it is in dealing with these cross browser issues that the skill and experience of the front-end developer really comes into play. Be prepared for hours of nail-biting CSS debugging action. There is no substitute for learning from your mistakes. It takes time to smooth your way through the minefield of browser incompatibilities but resources like quirksmode.org are a godsend providing explanations of common CSS bugs, workarounds and accepted means of circumventing certain issues (Mostly Microsoft Internet Explorer ones).

Reference:

www.quirksmode.org – CSS Bugs and Hacks
www.positioniseverything.net - More CSS Bugs and Hacks

Books:

CSS Mastery
CSS The Definitive Guide

Client-Side Logic

It is almost impossible to develop a modern web application without employing at least a small amount of client-side code in the form of JavaScript. But what is JavaScript? JavaScript is not Java, and if you say it is I will hurt you. JavaScript is not like Java. It isn’t even a stripped down version of Java.

JavaScript is the name erroneously given to the implementation of the ECMAScript scripting language which is built into almost all modern web browsers.

JavaScript is what allows the developer to deal with complex user interaction. Broadly speaking, any kind of interaction between the user and the page which involves more than simply moving the user to another page is probably controlled by JavaScript.

Each web browser implementation of ECMAScript varies slightly and this can catch out even the most experienced JavaScript developer. Many open source projects have sought to level the playing field with comprehensive cross browser libraries which attempt to provide solid cross-browser APIs for common programming tasks. These libraries commonly referred to as as ‘frameworks’ allow developers to focus on writing their application rather than on the multitude of cross-browser issues their application faces; and I cannot be more clear when i say that “You really really need to use a JavaScript framework of some description or you’ll go clinically insane”

JavaScript Frameworks

• jQuery – The Write Less, Do More JavaScript Library
• MooTools – a compact JavaScript Framework
• Prototype – Easy AJAX and DOM manipulation
• Dojo – the JavaScript Toolkit

Some of these JavaScript frameworks make it possible by means of plugins to work on client-side logic with very little in-depth understanding of JavaScript. jQuery for example has a simple enough basic usage that designers with little to no programming experience are often able to integrate fairly complex interface logic unaided via plugins. Should you wish to develop anything more complex than what is available as a plugin you will need to learn JavaScript. For this you will need books. JavaScript is often dismissed as a ‘toy’ language or simply as a very basic scripting language but it is in fact a very powerful language in it’s own right and can take some effort to master.

One thing all these frameworks have in common is AJAX. AJAX is the acronym of Asynchronous JavaScript and XML. To an extent AJAX is little more than a marketing term, like “Web 2.0″. Generally speaking, AJAX is a term mostly misunderstood by the vast majority of people who use it. The term AJAX is commonly used to refer to any form of JavaScript based rich user interface (another acronym commonly banded about is RIA – Rich Internet Application). In essence AJAX is the name erroneously given to any means by which modern web applications communicate asynchronously with a web server to provide a rich user interface. This communication doesn’t have to be XML, in fact more often than not it isn’t XML. The underlying technologies behind an AJAX request are way beyond the scope of this article. The best way to learn more about AJAX is by choosing a JavaScript framework and using it.

Reference:

A concise history of ECMAScript
JavaScript Tutorials
en.wikipedia.org/wiki/AJAX – Sums it up better than I ever could

Books:

Learning JavaScript

AJAX hacks (never read but looks to be a great little primer)

Server-Side Logic

The Server-side is where your web applications get down to business. This is where you connect to databases, manipulate data and make decisions based on user input. You could say this is the “real programming”, but that would be to the detriment of all your hard work on the client-side.

A front-end developer need not learn a server-side language, though it is good practice to understand at least the basics of the server-side language of any project you’re working on. Back-end developers it goes without saying should be proficient in at least one server-side language as well as SQL and database design principles. There are as many choices of server-side framework as you care to choose but your best option is to pick one and learn it inside out. Popular frameworks include.

PHP – Arguably the most ubiquitous open source server-side language of all time – That doesn’t make it the best though
Ruby on Rails – Favoured by cool kids with slick hairdos
JSP – Favoured for “Enterprise Solutions” and by those with smart beards
ASP – Also known as Classic ASP – Most commonly VBScript or JScript – Although defunct as a language, many developers will find themselves supporting ASP web apps for many years to come. It’s a valuable skill to have
ASP.NET – ASP’s big brother – Most commonly VB.NET or C# – Very powerful yet most usually favoured by those who don’t know what they’re doing

Databases

As a back-end developer you will need to be proficient in SQL (structured query language) which is often but not always pronounced “sequel”. SQL is the language in which almost all Database systems accept queries. The basics of SQL are the same from system to system, but each database system has it’s own slightly varying syntax. Popular relational database systems include:

• MySQL – Open Source – Most popularly partnered with PHP
• PostgreSQL – Open Source – slightly less popular than MySQL
• Microsoft SQL Server – Most commonly used with ASP(.NET)
• Oracle – if you’ve got money to burn

Reference:
www.w3schools.com/sql – Basic SQL tutorial

Books:
SQL in a Nutshell

Final Thoughts

So hopefully this has given you some new directions to spin off in on your journey into web development. Hopefully it’ll help you avoid some time-consuming pitfalls, maybe it won’t, and maybe that’s half the fun.

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