It’s possible to implement pretty much the whole of TTML in terms of CSS and HTML in 600 lines of Javascript (a task which is by their own admission, beyond the bright young minds at Opera and Mozilla).

Is it perfect? – no. But it can do the 4/5ths of the problem that I care about; which is, internationalised, high quality typographic, accurately synched, captions, subtitles, lyrics, timed transcripts and text-descriptions; should anyone care to write them, which is more than can be said for the majority of the formats out there – espcially the ‘peoples choice’ SRT.

There are tools to produce it and consume it both professional and free and its been in daily use for several years on the web captioning thousands of hours of media.

Long live NIH eh.

YouTube will continue to ignore it and continue to publish self-congratulatory blog points about their atrocious “solution.”

dotSub and Subply and TED and the other crowdsourcing acolytes will continue to devalue the actual practice of captioning, a decline hastened by – wait for it – WGBH and NCI when they laid off their own staff circa three years ago.

Also, pretty much anything I say is going to get ignored anyway, or get criticized as an assault on the free market by redhead Objectivists. And I’m not being paid to work on this. Everybody else is. Even Pfeiffer.

So that’s my valuable input. I don’t know whether or not DXFP or whatever it’s called will be any good, but in every other facet of this issue my aphorism, varied slightly here, holds true: Everybody is walking around thinking the 4/5 of the problem they understand is the whole problem, and they’re about to announce a miracle solution for it.

My understanding is that the two front-running codecs (Ogg and H.264) have no issue with DFXP per se (and in fact, David Singer of Apple was part of the author group, and Apple is the main proponent for H.264…), so that particular argument rings a tad hollow as a barrier for captioning implementation (unless it is once again a WHAT WG N.I.H. argument)

You don’t want to “rush into” anything in HTML5, then why is HTML5 “rushing” into the <video> element when the element is half complete? You suggest that adding something to the draft spec now would likely be an inferior solution, yet in many other areas of the draft specification there are existing but inferior suggestions already – items that are flagged as “…close but until we can return to it…”, so from my perspective better an inferior solution than no solution, which is what we have now.

@Joe there was a reason why I used single quotes on that term Joe… Technically files such as .M4V (which is the preferred file format for the iPhone) are re-processed (re-burned?) to include the binary .SCC caption file as part of the single downloaded file, making further extraction of this data nearly impossible, and thus inaccessible to Adaptive Technology such as Braille Output devices.

Do you have any concrete solution to propose as a way forward? Your years of experience in both captioning and web accessibility make you well positioned to offer valuable input – what say you?