The following jQuery powered widget, jCarouselLite, is an example of the dangers of jQuery and CSS collisions in WordPress [this is WordPress version 2.9.2 but the same is true of the new 3.0.1 beta]. I simply have not been able to get the code to work without resorting to an iframe as used here. This despite the fact that jQuery has become the defacto JavaScript Framework for WordPress. CSS is the main problem but also JavaScript collisions. Lets look at the CSS problems.
What CSS Needs is a RESET Command
Eric Meyer has raised this issue along with several other CSS experts. They have in fact generated all sorts of proxy class definitions of a RESET – but they are like sledgehammers when I want and need a delicate scalpel. Nonetheless, I tried most of them to no avail before resorting to a clumsy iframe. Here is how a RESET command would work in CSS:
<h2 style=”reset; margin: 4px; padding: 2px> Just the new margin and padding is applied</h2>
The RESET command would tell the browser to drop all the CSS cascade and styling info/state for this tag only and just apply the CSS contained in the STYLE option. If another <h2> tag [or any other tag] is encountered without the RESET command then the existing CSS Cascade still applies. Simple – and allows user custom control over the CSS. This becomes more important as two or more JavaScript Frameworks now appear in many Web 2.0 applications. I have had particular difficulties integrating various widgets into WordPress and Joomla. The problems are also theme/template dependent because of the huge CSS files used in some themes.
JavaScript Collisions
As anyone knows who has worked on adding JavaScript widgets to various existing Web code – think Galleries, blogs, bulletin boards, eCommerce apps – and some of the most popular names like Gallery, Joomla, Coppermine, WordPress => adding JavaScript often results in collisions . Now I specifically mention jQuery in the title to this post because it is one of the most popular JavaScript kits, constantly being in demand in job and freelance posting in the Toronto, Montreal and Washington areas.
The collisions are threefold. One widget demands the latest JavaScript version while another is maybe two revisions behind – so I must go firebugging and bring the old widget in line withe the new JavaScript version or live with two copies of the same JS library. The second collision occurs when two different JavaScript implementations use the the same name and parameters for a support function but clearly do not work the same [think EASING(ntime, ndelay) or any of a rogues gallery of commonly named support functions that internally work alarmingly different.]. But the worst case, is when the two JavaScript kits base code collide. An example, is Prototype and Scriptaculous versus jQuery in using the $() function. jQuery has graciously provided a workaround; but not all code invokes the workaround. This type of base collision can spill over into CSS as well. The net result is hours of precious time spent making things work together when separately they work fine.
Summary
These CSS and JavaScript collisions can be most vexing – they arise like murphy at the worst possible time – often at the end of projects when system integration is being done. Of course, the browser differences in implementation of W3C, HTML, CSS, DOM and JavaScript standards just make matters worse. And now gaping differences in standards support – see Whither E4X – only make matters worse. In sum, being a Web 2.0 developer these days may be hazardous to your health, sanity and well-being