You may have heard something about Chrome dropping support for H.264 from it’s Video tag implementation in favour of WebM. The reactions are unsurprisingly strong and partisan. From my point of view I see that:

• From a normal user’s point of view there is no discernable difference between a video that is played using the embed tag and one that uses the video tag. Advanced users may notice the performance difference or some of the particular behaviours of either Flash or the video tag but ultimately, both view the video perfectly successfully1{#footlink1:1295131564706.footnote}.
• Essentially the only users who can play video via the video tag but not Flash are iOS users.
• Before Google’s announcement, 99% of the web could view a video encoded in H.264 due to it’s support in Flash. About 40-50% could view one in WebM.
• Since every version of Chrome includes Flash, Google’s announcement did nothing to change those figures.
• There are already a variety of excellent libraries to allow the use of both the video tag with a Flash fallback.
• In order to maximise their potential audience, and thus business, content producers are going to supply video in the most widely supported video format.
• Since supporting two video formats simultaneously is expensive in terms of storage and bandwidth, content providers will avoid using a second format unless it is the only reasonable way to address a significant part of the market.

As a result, the only company who can exert any serious leverage on web video formats is Adobe. If they ship a version of Flash that supports WebM, suddenly it has traction very nearly equal to that of H.264 (but H.264 would still have the advantage of also working on iOS devices). For WebM to have the advantage Flash would have to support WebM and disable support for H.264.

There has been a trend over the past few years for open source projects to routinely ask for “donations” through a donate button on the site and increasingly in the software itself. I put “donations” in quotes because in the vast majority of cases these aren’t payments to a charitable organisation — they go straight into the pocket of the one and only developer.

Now it’s important to be clear, there are quite a number of open source organisations that are set up as actual charities or at least are independent organisations where the money donated actually goes towards the open source projects supported by that organisation. For example, when you donate to the Apache Software Foundation they use that money to pay for servers, bandwidth, legal advice the projects need, subsidising conferences around the projects and so on1{#footlink1:1294312313194.footnote}. These are great places to donate your money or time to — they handle donations very professionally as the funds directly benefit the projects and ecosystem around the projects.

CSS3 introduces the very handy columns support which is implemented in WebKit and Firefox browsers going back a fair way and degrades gracefully in all browsers that don’t support it (which appears to include IE9 sadly). The downside however is that support for the corresponding column-break property to control where column breaks are allowed to occur doesn’t appear to exist despite documentation suggesting it should. So for example1{#footlink1:1293713493905.footnote}:

<div style=”column-count: 3”>
  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>

  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>
</div>

Since column hights are always equal, the two items above will be split across the three columns. To keep each item together in a column, we should be able to use column-break-inside:

Many browsers include user preferences to select preferred colours for text, backgrounds and links. This is intended as an accessibility feature so that people with limited vision, dyslexia or other disabilities can choose a colour scheme that makes it easier for them to read web pages. In theory it’s a great idea. In practice however it seems to be nearly useless.

There are two “modes” these colour preferences can be used in:

I joined Ephox back in May 2002 and over the past eight-and-a-half years have had the pleasure of working with some of the most talented, dedicated, passionate and supportive people I’m ever likely to work with. It’s been an incredibly exciting time doing my small part to grow the company from a small team in Brisbane, Australia, though some very tight times to a very rapidly growing team with offices on three continents that’s firing on all cylinders.

In ARIA, there are two ways that you can attach a label to an element, aria-label and aria-labelledby. In theory, you should use aria-labelledby if the text is visually on-screen somewhere and this form is preferable. You should only use aria-label when it’s not possible to have the label visible on screen. This makes a lot of sense because generally sighted users like to be able to see the label as well and it prevents the visual and non-visual cues from getting out of sync.

I think Otis Gospodnetić has it spot on:

IMHO, commit messages are an important piece of the communication puzzle, and I feel they are often neglected or completely not even seen that way. Commit messages (that are distributed/delivered to co-developers via email or some other mechanism) help a developer keep others in the loop. They help co-developers stay up to date mostly passively, without having to proactively look for information about recent changes.

Brad Neuberg has a post up about ARIA on the iPad and some of the tricks he’s used to bend it to his will. Blogger won’t accept my OpenID to comment on the post for some reason so I’ll add some thoughts here.

tabindex

As Brad notes, you can set tabindex=”-1” to prevent an item in HTML from appearing in the tab order. Also as Brad notes, this won’t stop the VoiceOver cursor from moving to that element. It’s important to remember that the VoiceOver cursor is not linked to the keyboard focus, it’s linked to what is being read out to the user. This can be very confusing but it’s an important concept, allowing you to review parts of a document without losing the current caret position where you want to continue editing. Most screen readers seem to have this distinction between the text input focus and the screen reader cursor.

I have a bunch of JavaScript unit tests and for some of them I need to trigger a real keypress – one that activates the browser’s default functionality, not just triggers the JavaScript listeners. To do that, I have a simple signed applet that uses the AWT Robot to programmatically trigger the keypresses. Mostly, this works brilliantly.

The problem I’m having is that about 1 time in 10, the focus goes AWOL and the key events generated by the robot simply aren’t delivered anywhere. It’s generally not reliable, though I have got a setup now where I can make it happen within a few minutes of running the tests on a loop.

So Apple have announced that they will be contributing large swaths of code to the OpenJDK project and that from Java 7 onwards, Java will be a separate download from Oracle, much like Flash is now a separate download from Adobe. This really shouldn’t be unexpected for anyone who was paying attention to what was going on rather than just running around thinking the sky was falling.

This is fantastic news for Java developers of all types. Mac Java developers have been asking for Java to be separated from the OS for many, many years so that multiple versions of Java are more manageable and especially to decouple Java releases from the OS release timeline.

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.