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 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 supports
console.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
offset of 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
form element 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').fileUploadUI(). The latter being more complicated and unrelated to my clientâs specifications. I notice that there is more documentation and code samples for
- The documentation for the
onLoad option strongly suggests that the
handler object in the function signature for
onLoad has a
parseResponse function. 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.