Not everyone can know everything about jQuery plugins—not even John Resig. What is ruthless about some IT managers, from my hopefully distant past, is their expectation that you, the developer, know everything about the task you are about to undertake. It took me way, way too long to find out that this expectation, conscious and subconscious, is really the garbage of reckless youth—no matter how old the IT manager appears to be.
What is a nightmare scenario is realizing this magical expectation not only includes knowing all about the technology but also how the technology can be abused (the anti-patterns and just the anti-). I formally introduced this realm of hell to myself in “What’s most busy about the IT consulting business…” A couple of months later I’m still looking for a way to study Microsoft-based anti-patterns based on real data collected in the .NET 3.5/4.x timeframe.
So I have more experience with managing technological unknowns. The technology of the day (today) is jQuery. This is the client technology that’s paying my bills these days—so it would behoove me (my mother used that word) to hoof it and trot over the traps that caught me in these early days of HTML 5.
Here in the 21st Century, Internet Explorer Still Objectively and Scientifically Sucks
Internet Explorer is a living monument of corporate politics. This is why it sucks. Someone is going to write a book and then consult for a documentary film about Internet Explorer. Where’s the filmmaking skills of Robert X. Cringely when you need ’em?
In the meantime, install Internet Explorer 9 (there’s tweet I heard that said don’t install the 64-bit version because the JavaScript engine is “5x slower”—it’s not using the Chakra Engine) and go to http://html5test.com. This brand-new, 21st-century, browser will score the lowest of all the “modern” browsers.
In my recent work, here’s what stands out about Internet Explorer:
- It has the best Jscript debugging experience for any integrated development environment on the planet. In spite of this, I still use Firebug on Firefox and
console.log()(yes, IE Developer Tools also supportsconsole.log()—in a super-annoying way). - Internet Explorer 8 can’t do rounded corners (easily)—so Cornerz, yet another jQuery plugin, is still needed.
- Internet Explorer 8 can’t do CSS drop shadows (easily).
- I recommend using jQuery UI for designing any “pop-up” visual because Internet Explorer 8 has a very different interpretation of the
offsetof a block display. I lost hours of time and wasted my client’s money (as far as I’m concerned) discovering this “innovation” from Redmond.
File Input on an HTML Form for Cross-Browser Consistency is Ridiculously Hard
The fact that I did not know just how awful the situation is for <input type="file" /> betrays my lack of concern for providing ways of allowing “users” (interactors) to write files to a web server. Looks like I missed Web 2.0 entirely. (I did notice over the years how, say, flickr.com took exceedingly tedious steps to make file upload sexy—with much success.) In “CSS: Styling File Upload / Select Input Control <input type=”file” … />,” the situation is made explicit:
Let’s face it, the native implementations of file uploading control of HTML form is ugly, throughout most of the browsers, and not consistent at all.
Recent work led me to Sebastian Tschan, his work, jQuery-File-Upload. Like SlickGrid (see below) it’s on github.com and, like SlickGrid, it has little documentation—but, compared to the other stuff that’s out there, it’s awesome. It became awesome after these humps on the learning curve:
- jQuery-File-Upload by default uses an entire
formelement to do its magic. I tried to use a special, documented ‘micro-format’ to allow other visuals in the form but this did not work for me. - As I’m new to jQuery-File-Upload I prefer
$('#my-form').fileUpload()over$('#my-form').fileUploadUI(). The latter being more complicated and unrelated to my client’s specifications. I notice that there is more documentation and code samples for.fileUploadUI(). - The documentation for the
onLoadoption strongly suggests that thehandlerobject in the function signature foronLoadhas aparseResponsefunction. I have yet to find this function… perhaps it’s in another satellite file?
Deciding to Use SlickGrid Means Working with Almost No Documentation
There are too many freaking grids for the jQuery universe and no one is willing to declare themselves the supreme master of this space. I’m waiting for that grid episode on DocTypeTV to bust a move on this technical matter.
Before recent work, before my telecommuting experiment, I got mired in the well-documented, monumentality of jqGrid. Now it’s SlickGrid. I can see why I would prefer jqGrid over SlickGrid during my days at Amgen:
- jqGrid has better documentation than SlickGrid
- SlickGrid requires jQuery UI, which can be seen as an extravagant dependency (see below) that I would be unable to defend before a team of developers totally ignorant of the existence of jQuery UI.
jQuery UI “Theme Roller” Means Dragging around a Bunch of Files
jQuery UI is a celebration of the image file—my “theme rolled” customization has about 13 image files. Most of these image files make the gradient effect that CSS 3 promises to eliminate. In spite of the impressive idea in the celebrated ThemeRoller application, I literally cringe and almost dread having to change my custom theme. The way you “save” your theme, for example, is with a super-long URL which, for me, fails to preserve every detail painstakingly specified (this URL is also saved in a CSS file in your download).
It is fascinating to me how I am unable to find other Blog posts criticizing ThemeRoller. Even the search term “ThemeRoller alternative” returns little or nothing. I refuse to accept that ThemeRoller is beyond serious improvement. I suspect that serious CSS people, building on some 960 grid system, don’t even use it.
