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.

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.