Ephox has had Yonas working on with us on various TinyMCE related stuff for a while but mostly outside of the core source code on plugins for various clients. Today however, his first patch made it through both Ephox QA and the Moxiecode review into the mainline TinyMCE codebase. It will ship as part of the 3.4 release along with a bunch of other Ephox developed fixes and lots of good stuff in general.

James Turner gives a week in review and mentions the deprecated Java on OS X issue1{#footlink1:1288187415254.footnote}. One thing to correct:

Deprecation basically means that neither package will be delivered as part of the installation DVDs, and updates will not come via the Apple update mechanisms. It doesn’t mean they won’t be available anymore, it just means you’ll have to download them directly from Oracle and Adobe. Firstly, there’s nothing to suggest that Java won’t come from Apple but not be part of the standard OS X package.

It’s interesting to see how many people are jumping to conclusions around the very carefully worded deprecation notice for Java in OS X. Read it carefully and pay careful attention to what it actually says:

As of the release of Java for Mac OS X 10.6 Update 3, the Java runtime ported by Apple and that ships with Mac OS X is deprecated. Developers should not rely on the Apple-supplied Java runtime being present in future versions of Mac OS X. Most notably the note only refers to the Apple ported JVM that ships with OS X. This leaves the door open for an Apple ported JVM that ships as a separate download and for a non-Apple JVM that ships with OS X.

I was quite pleased to see Odi’s post this morning stating that the NTLM code in HttpClient (now HttpComponents) has finally been replaced with a more robust and compatible version that supports the more modern NTLM variants. Many years ago that NTLM code was my first contribution to someone else’s open source project and it lead on to me writing a bunch of documentation and becoming an Apache committer. In turn, that’s put me in touch with a whole heap of incredibly smart people.

As part of exploring JavaScript performance, I started wondering if the particular method of looping made a difference to performance. After all, one of the most often repeated bits of advice is that JavaScript is much faster if you loop backwards through an array instead of forwards and the slow part of my code was a loop. Using jsperf.com I could set up a simple test case pretty quickly and easily: for vs forEach.

This is the 1001th post to this blog. Fittingly, the 1000th post was actually reasonably technical. Being late to the blogging craze I started on 25th January 2004, 2448 days ago. A average posting rate of roughly every 2 and a half days is pretty good – much better than I would have expected actually.

I’ve been working to build a better filter for pasting from Microsoft Word into TinyMCE and if you know anything about filtering what Word calls HTML, you know there’s an awful lot of work to be done. As such, performance becomes a real issue – ideally we’d like to be able to filter reasonable sized documents (10-20 pages) in under the half a second that users generally call snappy.

Since filtering Word HTML is also inherently complex and we want to ensure the code is maintainable, I started out by developing the code in the most maintainable way possible, without regard to performance. There’s also a lot of tests to ensure correctness, and allow me to optimise later without fear of breaking things. With that done, it’s time to set up some performance tests and see what kind of performance behaviour it has.

The Wall Street Journal has an article on a new bill just passed by US Congress that updates accessibility requirements.

The legislation, called the 21st Century Communications and Video Accessibility Act, covers things like captions on Internet video, Internet phone services that work with hearing aids, television menus that can be seen by people with vision loss and even touch screens that the blind can use. The bill, which passed by voice vote and will now go to President Obama for approval, updates existing regulations to bring them in line with the Internet age. I haven’t taken the time to decipher the details from the actual legislation text as yet, so it’s hard to say exactly what implications this will have. It is at least good to see improvements to US laws – to date it has really been civil threats, such as the suit against Target, which have been the main legal avenue to ensure accessibility. This is generally under the American’s with Disabilities Act which was written in terms of physical accessibility for public places, but has been deemed to also apply to the web. As I understand it, this new legislation will provide some more teeth on the criminal1{#footlink1:1285835355912.footnote} side.

Over the weekend I went to JSConf EU and every time I met someone and told them I was working on TinyMCE the conversation rapidly veered off into why contentEditable is too hard/buggy to work with and how it would be so much better if it was all built on top of canvas or just used the DOM with a custom selection API. This matched the thinking throughout the conference that it doesn’t really matter how messed up browsers are because JavaScript can be used to work around it.

Austin Seraphin’s posts on his experiences using the Voice Over technology in iPhone and Mac OS has been mentioned fairly widely and they are definitely worth reading. Many people understand that blind users, and people with other forms of disabilities, are dependent on screen readers to interact with computers, but what is likely to come as a shock is just how expensive high quality screen readers can be:

I joyfully look forward to the day when blind people finally catch on and realize that for $700, HALF the cost of JAWS for Windows, the most popular software used or rather pushed on the blind, they can get a fully functional computer that delivers a superior experience and comes with a superior screen reader with superior speech. JAWS standard edition turns out to be $895 on the online store, professional $1095 but that still doubles the cost of a computer for users who need a screen reader. There are open source screen readers and my understanding is that some of them are quite good, but the defacto-standard is very much JAWS. Most accessibility testing that is done is with JAWS and so it’s an up-hill battle to use anything else.

Windows uses a particularly ugly format for putting HTML on the clipboard, called CF_HTML. Basically, it adds a header to the content with pretty useless information essentially declaring how many bytes in the header (and yes you have to pad the byte counts since they themselves are included in the count).

The problem between Java and Firefox is that Java always sets the ‘StartHTML’ and ‘EndHTML’ fields to -1 to indicate there is no context and Firefox will refuse to paste HTML from the clipboard if StartHTML or EndHTML is set to -1. As such, if you copy HTML from Java it will be impossible to paste into Firefox. It works perfectly with Word and IE.

Lisa Hill from Blue Fish has published an excellent article covering how to customize the EditLive! rich text editor in Web Publisher. It includes many of my favorite ways to get the most out of EditLive! as well.