The Email and P Myth

September 2nd, 2010

One of the greatest frustrations for anyone who develops an HTML editor is the constant supply of people who are convinced they want to use BR tags instead of P tags. Most of these are just people who don’t want “double spacing” and they’re happy once you give them the magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 0;
}

The other group however are people writing HTML emails who insist that P tags are completely incompatible with some email clients and cause rendering problems. At one point it seems that Yahoo! Mail really did strip them entirely but now it just applies a different default CSS styling (ironically, the magical CSS above that removes the extra spacing). So if you naively use P without specifying the padding you want, some clients will display a blank line between paragraphs, others, notably Yahoo!, will push all the lines immediately under each other. The solution is of course the opposite magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 1em;
}

Solved right? Nope. This runs straight into the where the heck do I define styles? problem. In HTML, it should be:

<html>
<head>
<style>
p {
  margin-top: 0;
  margin-bottom: 1em;
}
</style>
</head>
<body>
…
</body>
</html>

However while this works in some clients, it has no effect in most. Instead, the common wisdom is to move the style tag into the body tag:

<html>
<head>
</head>
<body>
<style>
p {
  margin-top: 0;
  margin-bottom: 1em;
}
</style>
…
</body>
</html>

Which works almost everywhere. Enter GMail. GMail never respects the style tag, only inline styles. So now you need to write your paragraphs as:

<p style=”margin-top: 0; margin-bottom: 1em;”>…</p>

Thankfully you can use the margin shorthand if you know what you want the left and right margins to be as well:

<p style=”margin: 0 0 1em 0;”>…</p>

I would strongly recommend using embedded styles while editing and then just use post processing to inline all the styles – Premailer can do that for you.

As far as I can tell, there is no need to avoid P tags in email anymore and sampling a number of emails from various clients that happened to be in my inbox, they turned out to appear in emails from a few different clients though that’s far from scientific and it was still intermingled with a lot of <br> and <div><br></div> hacks. I would be very keen to hear from anyone who knows of an email client that cannot be made to render P tags correctly.

With a bit of luck we may be able to start moving away from the horrific abuses of <br> tags…

Open Core, Open Development and Co-location

July 21st, 2010

It would be hard to have not noticed the on-going debate around “open core”. From what I can tell, it largely, but not completely, boils down to concerns about a product being called “open source” if the core that’s open source is generally unusable without the commercial-only additions. Mostly, people are ok with there being separate commercial-only plugins or tools provided so long as the open source product can stand alone and be useful and effective. Dave Neary hits on what I think is a key warning sign that a product is using a damaging open-core model:

And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom.

The open source definition is all about what license is being used for the software, but the effectiveness of something being open source is at least equally affected by the development model in use. The ability for anyone to jump in and contribute to the project reasonably easily is what drives extra innovation and enables the development investment to be spread among many users of the software. Having access to the source code and the ability to modify it yourself is useful to avoid lock-in, but maintaining the entire software is generally too expensive to be worthwhile for users – it’s cheaper to incur the costs of switching to another product instead.

What Dave Neary’s paragraph above starts to move towards is looking for a product that uses open development rather than just open source. Bertrand Delacrétaz wrote up how we work at Apache recently and it’s a great model of things to look for in open development1. In particular Apache lives and dies by the first item: “All technical discussions and decisions on public mailing lists” or as I’ve often heard it put, “if it didn’t happen on the mailing list, it didn’t happen”. Unless all discussions wind up happening in a public forum, be it a mailing list, forum, wiki, wave or whatever, it’s unlikely that open development will be possible2.

So all of this leads me to a somewhat unexpected realisation: any open source company that insists on having all its developers colocated is failing to do open development effectively. If your employees can’t develop effectively from remote locations, how can you possibly expect to benefit from significant community contributions?

Anyone have examples of companies using exclusively co-located developers but still fostering an open development model?

1 – of course there are other approaches to open development, but few are as well articulated as the Apache way these days.

2 – Apache does use face to face meet-ups, but they make a point of keeping the mailing list in the loop about what was discussed there so everyone can still be involved

range.extractContents Bug in Firefox Pre-3.5

July 5th, 2010

It’s not often I say things like this, but oddly today’s problems are Firefox exclusive. It turns out that prior to Firefox 3.5 Range.extractContents is subtly but, for my uses, devastatingly broken. Basically, on any browser except those earlier versions of FireFox the test below should pass:

test('range.extractContents', 2, function() {
  var item1, item2, list, r, fragment, test;
  test = document.createElement('div'); 
  test.id = 'test';
  test.innerHTML = '<ul><li id="item1">Item 1</li><li id="item2">Item 2</li></ul>';
  document.body.appendChild(test);

  item1 = document.getElementById('item1');
  item2 = document.getElementById('item2');
  list = item1.parentNode;

  r = document.createRange();
  r.setStart(list, 0);
  r.setEnd(list, 1);
  fragment = r.extractContents();
  list.appendChild(fragment);

  ok(item1 === document.getElementById('item1'), 'Item 1 must not be cloned');
  ok(item2 === document.getElementById('item2'), 'Item 2 must not be cloned');
}

Basically, extractContents should remove the nodes within the range from the document and give them to you in a DocumentFragment (so you can put them somewhere else usually). The key requirement is that they be the same nodes unless only a part of the node is within the range, at which point the node should be shallow cloned and split.

My tweet is of course rather hyperbole because IE doesn’t implement the W3C range at all (at least prior to IE9), but I don’t notice because TinyMCE includes an emulation layer which gets this behaviour right, thus leaving Firefox as the only browser to exhibit the problem. Thankfully, it appears that I can just use the pure-JavaScript implementation designed for IE to fix the problem in earlier Firefox versions as well.

Who’s Committed in my Git Repository?

June 30th, 2010

Note to self: if you ever want to get a simple list of people who have committed to a git repository, the command you want is:

git log --format='%aN <%ae>' | sort -u | uniq

Or for just the e-mail address:

git log --format='%ae' | sort -u | uniq

Or for just the name:

git log --format='%aN' | sort -u | uniq

This is in the help manual but it’s way down the bottom so takes ages to read through to find it.

Java AWT Robot and Windows Remote Desktop

June 15th, 2010

Problem

If you’re attempting to use the Java AWT Robot to help automate tests, you may find it convenient to log in via remote desktop to watch the tests execute and verify they work well. You may also find that they work fine while you’re watching them but then inexplicably start failing whenever you aren’t. Basically your test is an angel from Dr Who.

What’s most likely happening is that when you disconnect from the remote desktop session, the console on the Windows box is left in a locked state and you need to enter the user password before you can resume interacting with programs on the main display. Since the AWT Robot is doing a very effective job of acting like a user, it also can’t interact with the programs you’re intending and instead is interacting, probably quite ineffectively, with the login dialog box.

Solution

It may be possible to get the AWT Robot to actually login before continuing, but then your tests would break when you were watching and it complicates the tests. Instead, you can take two approaches:

  1. Stop using remote desktop and switch to VNC which doesn’t lock the screen when you disconnect.
  2. Rather than disconnecting from remote desktop, transfer the session back to the console. Use Start->Run or a DOS prompt and run:
    tscon.exe 0 /dest:consol
    

Or of course just get up and walk over to the remote machine and watch the tests on the console directly, but that’s not always a viable option.