[Bug 11207] Make track element additions technology neutral


--- Comment #4 from Tab Atkins Jr. <jackalmage@gmail.com> 2010-11-03 16:56:39 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Why do we want to remove WebSRT specifics? 
> At this time the media sub-group of the Accessibility Task Force desire that
> the language be as neutral and technology agnostic as possible. It is unclear
> _at this time_ if WebSRT is sufficient for meeting all of the user requirements
> and author needs that we have identified. We are currently evaluating a number
> of time formats (WebSRT, TTML, etc.) to determine which, if any, best meets
> these needs, which is why we are asking that folks review the user
> requirements.

There is an obvious possibility that WebSRT be the format chosen by the media
accessibility subgroup.  If this occurs, then any effort spent on genericizing
the API will be wasted.  (In fact, it will be a waste if any single format is
chosen, as you instead want a specialized API if you have only a single
format.)  As such, it seems premature to spend any effort on this right now.

> > Why do we want to try and
> > genericize the API, when there aren't currently plans to add additional timed
> > text formats?
> Curious to know where this assertion is coming from, as AFAIK this has never
> been discussed within the W3C, and this is a topic that I have been following
> most closely. Implementers might be experimenting with WebSRT today (and there
> is usefulness in that), but at this time I do not believe a final decision has
> been made to standardize on a specific time format.

The fact that a final decision hasn't been made doesn't negate the fact that
there aren't *currently* any plans to add an additional format.  So far, there
has been no public announcement of any plans to add an additional format; there
is only the a11y TF's investigation of formats, which has not yet resulted in
any announcement.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 November 2010 16:56:42 UTC