One of those is dealing with something that came up on my last contract: the jQuery “jumping” bug with slideUp, slideDown and slideToggle. If you’re not familiar with it, check out Remy Sharp’s great screencast on the issue.

So I’ve made my first attempt at writing a jQuery plugin from scratch to deal with this issue. The result is BetterSlide which is intended to be a replacement to the native slideUp/slideDown/slideToggle calls.  Complete documentation is below.

You can download the plugin from GitHub.

This plugin is very much in beta, so I’m looking for any and all feedback, especially bug reports, you can throw my way. Thanks.

Documentation

BetterSlide Plugin
Replaces jQuery’s native SlideUp/SlideDown/SlideToggle functionality to eliminate the “jump” bug.

Version 1.0b
Updated 2012-01-17
License: MIT (https://github.com/jquery/jquery/blob/master/MIT-LICENSE.txt)

Usage:
$(‘element’).betterSlide( { options } );

BetterSlide Options

action: ‘toggle’; Slide action desired. Also accepts ‘up’ or ‘down’

duration: 400; time in milliseconds for animation. Also accepts ‘fast’ (200 milliseconds) and ‘slow’ (600 milliseconds)

easing: ‘swing’; Desired easing effect. Supports any easing effect you have installed, including jQuery UI effects.

callback: ”; Function to perform upon completion of the animation

Alternate Usage (to more closely match native jQuery commands):
$(‘element’).betterSlideUp( { options } );
$(‘element’).betterSlideDown( { options } );
$(‘element’).betterSlideToggle( { options } );

The same options are recognized, except for the “action” option.

Original:

There seems to be a lot of discussion going on about how a “real” web designer also needs to have serious HTML and CSS chops, otherwise they’re just (in the words of one blogger) “drawing pictures.” Some blog posts of note:

• If You Can Think, Design & Code, You Win
• Web Design is Product Design
• Why The Valley Wants Designers That Can Code

Okay, fine, if you want to focus this on the designer, one could take that point.

But I have a problem with what could be seen as a corollary: to be a good web developer (and we’re just talking front end here, folks), one necessarily has to be a designer as well.

This is kinda a WTF idea for me. In my career, I’ve worked with a bunch of great web visual designers, many (most?) of whom wouldn’t know a pseudo-selector from a boolean attribute. On the flip side, I have absolutely zero sense of how to balance the right color with the right shadowing and the right spacing, although Lord knows I’ve tried when I’ve been pressed into that duty.

What I can do is look at a design, mentally break it down into its components, structure the code for how to best arrange it on a web page, templatize it, and then go back and tweak it for all the multitude of web browsers out there so they all look pretty much (with varying margins of IE error) the way the designer intended.

I’m in the midst of a job hunt (I’m not sayin’, I’m just sayin’), and there are two patterns out there thoroughly annoy me. The first is the “we need a web person who can do everything” pattern, where a company expects one person to be and expert in Photoshop, Flash, HTML, JavaScript, CSS, Visual Basic, Oracle, MSSQL, J2EE… well, you get the idea. (Oh, and this person should be willing to work sixty hours a week for $25,000/year, but I digress.) This simply isn’t realistic.

The second pattern that frustrates me is companies who expect me to supply a “portfolio.” Well, I’m a developer. Snatching a few screen shots is essentially meaningless, as the sites were designed by someone else. Also, many of the sites I’ve worked on through the years have evaporated away as sites often do. Lastly, you might be able to view my front-end coding work by viewing source and checking out the CSS and JavaScript files, but that’s usually only a small part of the story; the PHP running the whole show won’t be visible at all and let’s not even get into the problems when it’s a template-driven site like WordPress.

My point is, design and development are two different skill sets, and having one by no means ensures that you have the other. Hire a designer to design, and hire me… uh, I mean a developer to develop. Like me.

So my question to you all is: do you still test in IE7? Or is it only 8 and above for you guys now?

Thanks for your input!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

I spoke too soon! Sarah used this on this week’s show. Awesome!

I recorded this Mobile Safari “Duh” tip for iPad Today, but they didn’t use it on this week’s show. Their loss. Enjoy!

Example of HTML5 semantic markup displayed correctly in Google Chrome for Mac.

The first, unsurprisingly, is Internet Explorer. Only within the past year have many federal agencies upgraded, and that was only going from version 6 to version 8. IE8, sadly, is incapable of rendering many of HTML5′s semantic tags without the help of JavaScript.

Example of HTML5 semantic markup displayed incorrectly in Internet Explorer 8.

That leads us to our second problem: Section 508. By way of review, Section 508 is the well-intentioned, but somewhat antiquated law that mandates certain accessible practices for government websites. It is in major need of updating, but until that happens, web developers in the federal sector need to follow the law that is currently on the page.

The exact provision that gives us pause when trying to implement HTML5 is Subpart B, §1194.22, Rule (l) which states:

When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

This means that the JavaScript trick that’s standard practice for developers to use to get Internet Explorer < 9 to render the new HTML5 semantic elements are prohibited for the purposes of Section 508.

The alternative? Use classnames that correlate to the semantic elements for easier find and replace at a later date. For example, <article> would become <div class=”article”>.

It’s not the optimal situation, but it’s a workable solution.

But we don’t build websites in a bubble. If we do this for a living, it’s for that reason: to deliver the product our clients want so that they pay us for our time, effort and expertise. So ultimately, it’s up to them to determine how far we need to go to deliver a product that looks the same whether it’s viewed in Firefox or Internet Explorer, etc.

In turn, that client should be considering the users to his site when making the yes and no decisions. What browsers do his visitors really use? Are they going to mind if that element has rounded corners or not? Are they even going to notice?

What takes one line of CSS to do for four of the major browser titles out there takes lines of extra markup, extra CSS, and superfluous images to do in the fifth.¹ But the ability is (usually) there, and it’s not always a black and white decision as to whether or not the effort should be made to do it.

But if your client (or the executives at your company, same difference) is running Internet Explorer 8 on their computer, you should be prepared to make some accommodations so that the site at least comes close to the designer’s vision, if not matching it exactly. Websites get built for large corporations and government agencies. Large business units such as those are often slow to upgrade their operating systems, and with them, their browsers. But the executives in charge are not going to blame their IT departments when their websites look awful; they’re going to blame the web developer.

What I suggest, and what I try to do for my clients, is find a middle ground. Maybe all the widget boxes in the sidebar don’t really need rounded corners or gradient backgrounds. Maybe squared corners and a color that comes close will do. But if the feature is prominent and is the focus of the page, then I will make the effort, whatever is reasonable, to make that element look the same across platforms.

Let me be clear: I am in no way defending older browsers, or as many know to be true, “buggy” browsers with poor implementations of web standards. But they’re out there. We have to live with them. We have to produce websites for people who still use them. That’s not going to change quickly. And in the meantime, accommodations will still need to be made, no matter how distasteful it may be to our web-standards loving sensibilities.

Interface

The document drawer has been on the right side of the screen since its introduction.² So for years my eyes have been used to seeing my document on the left edge of my monitor, and a document drawer on my right, which I assigned a keyboard shortcut to show and hide at will. Since I read and write in English (well, HTML and PHP), going left to right, my content was left aligned where my eyes were comfortable finding it.

Now, open documents in the same window are listed in a sidebar on the left, and the document itself is on the right. This may sound like a small change, but now my eyes have to find the left edge of the document somewhere closer so the middle of the screen. The built-in keyboard shortcut to hide this panel is CMD-0 (zero), which in of itself is not obvious, but now this is causing the left edge of the document to shift back and forth.

BBEdit 10 window with the document sidebar on the left.

In short, it’s hard for my eyes to know exactly where the left edge of my content is. Anything you have to think about beyond the code you’re trying to write is a distraction which takes away from your focus. I want the left edge of my content to be anchored to that left edge of my monitor, unmoving. BBEdit should at the very least make the sidebar’s position a preference.

Preferences

One of BBEdit 10′s biggest interface overhauls was in its preference window. Certainly, the preferences were growing out of control with options to customize almost any aspect of the program, but what BareBones chose to remove has left me scratching my head in bemusement. Not to mention the overall design of the preference window itself.

Now the preference window sports cutesy icons in the left sidebar (a Groucho nose and glasses? Really?), renaming almost every category so that I have to go hunting for the right tab. But as I do, the preference window resizes for each category, creating a whole lot of unnecessary movement. More distractions.

BBEdit 10 Preferences from taupecat on Vimeo.

But not only all of that, but some options are now missing entirely from the preferences system. To delete to the right of your cursor (say, on a MacBook [Pro/Mini] keyboard that lacks a right-delete button, you used to be able to set a preference that would make Shift-Delete do that. Now that preference is gone, replaced by an “expert” preference that requires opening Terminal and entering a command on the command line.^{3 4}

BBEdit 9's Shift-Delete preference.

Another preference demoted to the “expert” category is “Next Document and Previous Document navigate in: Display order/History order” which was in the “Documents & Drawer” preference category. When I have documents open for days at a time, which I often do, the order in which I opened them is pretty meaningless, and accessing them in alphabetical order is far more useful. Now, that preference is gone from the preference window altogether, and can only be set by typing “defaults write com.barebones.bbedit SurfNextPreviousInDrawerOrder -bool YES”. Awesome.

BBEdit 9's Next/Previous document preference.

Window Arrangement

This is, by far, my biggest gripe with BBEdit 10. In my everyday workflow, I copy HTML from the browser to work on front-end (HTML, CSS) changes locally, before migrating my changes to a JSP or Java file that might take hours before it’s built, and builds only happen three or four times a day. Traditionally, I used a custom keyboard command along with my preferences to open my HTML file and the JSP file side-by-side, something like this:

In BBEdit 10, such window arrangements are completely gone and the only arrangment left is one window stacked upon another. So a critical function I use each and every day is completely wiped out in the name of simplicity.

Stacking windows is the only way to arrange them in BBEdit 10.

There are third-party fixes, such as Cinch and BetterTouchTool, but none of them are as simple and as quick as what I had going in BBEdit 9.

BareBones support has said to me in email that “some of the options may make a triumphant return in a future update.” That’s cold comfort, to say the least.

Conclusion

I’m not going to dispute, or really address much at all, the improvements that BBEdit 10 has made. You can now edit files in a Zip archive without opening and rezipping the file. I don’t remember ever having to need this feature, but it’s probably going to be useful for somebody. And there are interface updates to some of the HTML markup tools, but I rarely used such tools in BBEdit 9 so I’m not sure yet how much that will benefit me.

All I can see right now are the things that are gone, things that I relied on to do my job the way I did it, and overall I’m left feeling like BBEdit is a huge step in the wrong direction for me and my workflow. Since BBEdit 10 came out, I’ve dabbled with TextMate, but that doesn’t have the great CVS and Subversion integration that BBEdit has, doesn’t do the side-by-side window arrangement that BBEdit 9 gave me, and it simply cannot handle large files such as MySQL dumps.

So I guess I’m sticking with BBEdit 9 for the time being.

Get it from the usual place.

Be gone, browser version warning!

WordPress 3.2 introduced a new dashboard widget that warns you if you’re not using the latest version of your chosen browser. While some may find this useful, if your clients/contributors/other interested parties cannot upgrade their browser for whatever reason (or simply choose not to), you can disable this warning across the board rather than scare them with warning messages they have no power to control.

Of course, by disabling this warning message you run the risk that your WordPress site may not function properly for older browser users. However, global browser usage statistics indicate that WordPress’ stated support (namely, Internet Explorer >= 7), will be perfectly fine for the vast majority of WordPress users out there.

Download it now and feel the warm fuzzies.

Update: This has now made its way onto the the WordPress Plugin Repository. Sweet!

I love the fact that I can scrub past commercials. It’s made listening to the show so much faster now that I don’t have to sit through twenty asthma PSAs per show.

Downloading to my computer has worked pretty well, although LockerSync3, the program one needs to transfer the audio files from the cloud into iTunes, occasionally freaks out and spews some mysterious errors. But mostly, I haven’t bothered, opting instead to listen through the DAR.fm web interface.

Less successful has been listening to the show through AirBand, the iPhone app that connects to mp3tunes.com. I’ve gotten it to work, but you can’t scrub through the tracks. I’m spoiled now. I’m not going to listen to commercials if there’s any other option at all, so I don’t.

The biggest problem is that sometimes the last few seconds of the show (emails) gets cut off, I guess because the show runs long. Fortunately, the mothership podcast, which is usually released sometime in the afternoon after the show, always has the emails, so I just listen to what got cut off.

All in all, I’ve found a new way of consuming the Tony Kornheiser Show that involves same-day time-shifting and no ads. And I have ESPN 980 to thank for that!