A few days ago I talked about the Email and P Myth, but didn’t explain why it’s so frustrating for editor developers that people keep wanting to use BR tags instead of P tags. It’s not actually because we’re fastidious about using the correct semantic HTML, though obviously we do recommend that, it’s because a lot of concepts that user’s expect simply aren’t possible to implement sensibly if you don’t use the correct paragraph level elements.

Back when git and GitHub were relatively new to the mainstream, there was a big discussion about how it promoted forking and was potentially bad for community building. Since then GitHub has well and truly proven that it can successfully support significant community and very successful projects. Looking around GitHub though, it’s clear that not every project successfully builds community there and the tendency to fork can still become a problem.

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.

I had written up a long, comprehensive and timely set of thoughts about what went wrong with Google Wave, but WordPress ate it so you’ll have to take my word that it was awesome and instead put up with this rather late and significantly shorter thought. There are lots of opinions around about why Wave failed, and they show that it was a combination of a lot of factors from poor UI, inexplicable purpose, unreliability and simply combining too many technologies that didn’t always fit (e.

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.

Despite all the hype about how everyone’s making advertising more targeted and therefore more useful to people, you still get gaffs like this one: The advertising industry is booming and ads are popping up in more and more places, but the quality of ads are still really bad. It’s no wonder ad blocking technology has become so popular. On a side note, it’s also somewhat worrying that there’s a minimum $10,000 investment for finding oil in the Gulf of Mexico – seems pretty easy to find at the moment…

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.

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.

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.

Normally applets run in a security sandbox, much like JavaScript, but with signed applets those restrictions are lifted and the applet can do anything. At least, that’s the theory – in practice most implementations leave a security manager instance installed but with significantly reduced restrictions (such that most programs will never be affected by them). To get around these remaining restrictions, applets can remove or replace the security manager: System.setSecurityManager(null); Having set a null security manager though, you will start to get NullPointerExceptions in Firefox on OS X when you try to call Java methods from JavaScript (via LiveConnect).

One of the things Ephox is contributing to TinyMCE is a build farm to run the automated tests in various browsers which winds up publishing it’s results for all to see. This has been pretty interesting to set up and there are a range of different approaches. Matt Raible posted recently about his experiences using Selenium with Sauce Labs. I had initially looked into that as well, but was worried about a few of the issues Matt hit and TinyMCE had already written a lot of tests using QUnit rather than Selenium.

The new Ephox Enterprise TinyMCE site has now gone live, a result of our new partnership with Moxiecode, the company behind everyone’s favorite open source editor TinyMCE. I’m really excited about the potential of this partnership and have really enjoyed the opportunity to work with the Moxiecode team so far. What We’re Adding… We think we can bring a lot to the TinyMCE community, the things below are just where we’re starting.