Symphonious

Living in a state of accord.

The Joy of Browser Selection

Anyone who’s done much work with JavaScript has probably discovered that the selection APIs are completely different in Internet Explorer vs the rest of the world, what comes as a bit more of a surprise once you start using them in anger is that FireFox is actually quite different to all the other W3C compliant browsers in an important way as well.

If all you ever want to do is retrieve the selection or you only want to work with ranges rather than selection, you’ll probably never encounter this, but as soon as you use window.getSelection().addRange() you’re going to get bitten. The difference is that FireFox will preserve whatever range you give it precisely as you original created it. The other browsers won’t.

Start with a simple document with three paragraphs:

<body>
  <p>Paragraph 1</p>
  <p>Paragraph 2</p>
  <p>Paragraph 3</p>
</body>

Create a range where the startContainer and endContainer are the body element:

var range = document.createRange();
range.setStart(document.body, 0);
range.setEnd(document.body, 1);

The range now encompasses the entirety of the first paragraph element – including the actual P element itself, not just the text within. Now add that to a selection:

window.getSelection().addRange(range);

In FireFox this selects the paragraph element, but in Opera, Safari and Chrome the selection is now just the text within the paragraph. So in FireFox and only FireFox, the statements below are true:

var selected = window.getSelection().getRangeAt(0);
selected.startContainer === range.startContainer === document.body;
selected.endContainer === range.endContainer === document.body;

This isn’t an arbitrary change by Opera, Safari and Chrome – as far as I can tell, they really can’t select actual elements, only textual ranges. So if you add a range that includes elements, the selection winds up encompassing just the text of those elements and that’s correctly reflected in the range the selection returns. I’m unsure which behavior is correct or whether this is just a missing part of the standard altogether. It appears that the whole concept of a selection object is an old Netscape 4 thing that has never actually been defined1.

Unfortunately, selection is one of those surprisingly difficult concepts to get right in any rich text editor due to the complexity of what users want to select and how that affects the operations they will then perform. With these kinds of differences in browser behavior, JavaScript based editors really are fighting an uphill battle that they shouldn’t have to.

1 – Range has been defined by the W3C, but the selection object doesn’t appear to have been.

Job Application Tips

This has been said before but apparently even really smart people aren’t listening. So here’s my top two tips for job applications:

  1. Tailor your résumé. If you’re applying for a JavaScript job, highlight the JavaScript experience you have first and foremost. Even something as simple as the order you list skills in makes a difference – if JavaScript is at the end of a list of skills, it’s probably not a priority, if it’s first it makes it seem more important to you, so you seem more qualified.
  2. Get a blog, make it look good, fill it with good content.

The corollary to number 2 is that you should set your FaceBook page to private – it never seems to be what you want to have turn up. It’s surprising how many blogs have relatively good technical content but look terrible. Even if you’re not going to be applying for design jobs, having a decent layout without broken images is always helpful.

But really, tailor the résumé – it’s crazy that people don't do this.

The Fear of Reading Code

From yield thoughtOn The Fear of Reading Code:

When I was learning to program someone told me that I should try to read as much code as possible. Budding genius that I was, I thought this was advice for stupid people who needed to learn from their betters. I thought the only reason to read code was to pick up tricks from it.

How wrong I was. The real reason to read code has nothing to do with learning from the programmer who wrote it.

Far too many programmers fail to take the time to read and understand other people’s code and it’s a great loss. Much like history, if you don’t take the time to read and truly understand other people’s code, you’re doomed to repeat their mistakes. It’s not just learning from old code either, sometimes that old messy, “unmaintainable” code, is actually just battle hardened and bug-free. As the referenced post mentions, it’s all too common for developers to find a bug in someone else’s code, not really read and understand the code and decide to reimplement.

It’s only after years and years of repeating this pattern that it has begun to dawn on me that each time I do this I’m really just wasting precious, precious time on something that doesn’t improve the product at all. What’s worse, I’m only doing it because I can’t face the thought of reading somebody else’s code. If I spent one fraction of the time reading and understanding it then I’d learn a lot more about the problem it’s trying to solve and would be in a great place to tweak or refactor it to suit my needs.

So perhaps the next time you want to improve your coding skills, try taking someone else’s code and improving it in some way. You’ll learn far more from doing that than from any new code you might write.

Apache Pivot

Thanks to a tweet from @bdelacretaz I discovered Apache Pivot today. It does indeed have a nice website, and the library itself looks great. It’s pitched as an RIA framework and mostly seems focussed on browser based deployment via applets. However, pivot apps can also be deployed as standalone applications which is where I think it’s most promising.

The killer feature as far as I can see, is the much richer set of components that are available, combined with a better set of customisation points such as effects, transitions, web queries and data binding. There are libraries to do most or all of this with Swing, but since it wasn’t designed for it up front, they tend to feel pretty clunky and “bolted-on”. Hopefully Pivot can avoid that.

Sadly, it does look a bit like you’re leaving Swing completely behind – if for no reason other than the look and feel is unlikely to match nicely with the Pivot themes without a lot of effort. While Pivot has a lot of components built-in, there are a vast world of custom Swing components around and it would be nice if you could leverage those.

Know when to refine, when to refactor and when to refrain

Chris J Davis in Lessons for the Newly Minted:

As you can clearly see, when you have tight deadlines, and mountains of work, refactoring existing code that works is highly unadvisable. As a developer you must make strategic decisions about where your time is spent, and this must be informed and balanced by the needs of the company. Should you strive to craft breathtakingly beautiful code? Yes, but not at the expense of the overall velocity of your development schedule. Sometimes good enough is beautiful.

Amen to that.