This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The API for TexttTrackCue from the HTML5 specification http://www.w3.org/TR/html5/embedded-content-0.html#texttrackcue is a superset of the APIs in the latest HTML5.1 specification: http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#texttrackcue where the differences, including the constructor, seem to be captured in a new WebVTTCue api http://dev.w3.org/html5/webvtt/#webvttcue It seems that part of the TextTrackCue object is being deprecated already and this could have an impact on interoperability. I work in a standards organization that will be heavily relying upon this API. Could you help me understand why this action has been taken? It seems it could have been possible to keep the constructor on the TextTrackCue object and overload the methods needed for the new WebVTTCue API
I don't see an impact on interoperability coming from DLNA (I assume that is the standards organization you refer to). It is simply too early in the process for this to be an issue. In particular, there are no devices deployed yet using this developing standard, and there are no web pages serving content being transmitted to such hypothetical devices.
(In reply to comment #1) > I don't see an impact on interoperability coming from DLNA (I assume that is > the standards organization you refer to). > Whether this spec is in use by DLNA or not is up to standards organization that is using it to reveal not me. > It is simply too early in the process for this to be an issue. In > particular, there are no devices deployed yet using this developing > standard, and there are no web pages serving content being transmitted to > such hypothetical devices. There is a problem when a standards organization references and uses the API from HTML5.0 but the latest WebKit and Mozilla builds start to use the APIs from HTML5.1. It means creating a fork in implementations/updates to these devices and as well as putting API detection into the content that uses these APIs. If none of these APIs are in use then why not change the HTML5.0 spec now to have compatibility with the future standard? Or why not have the functionality remain in the TextTrackCue and have the WebVTTCue simply add to it as needed?
First, the term "deprecated" does not apply since we are still not in REC state. If an external organization references a not yet complete (i.e., not yet REC) W3C specification, then they must take the risk of having that spec change before arriving at REC. Second, as I mention, the fielded implementations are effectively experimental, and as Sylvia indicates, little impact is expected by reworking the TTC constructor signature. Third, this is the purpose of having a CR period, otherwise known as "Call for Implementations", in which experience can be gathered and fed back to the spec process. It is a general understanding that this process may end up producing changes in the spec. Fourth, it is well recognized that the VTT specification material in HTML5 was due to be moved to another specification, and that what remained behind should be sufficiently generic to accommodate different text track content types. So what Sylvia is suggesting is already well understood and consistent with expectations.
xham, you may have missed some of the discussions around this: bug 21851 is relevant and so is the email thread started at http://lists.w3.org/Archives/Public/public-html/2013Apr/0027.html . You can keep track of the current status of the discussion at http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange . We will likely re-introduce .text . The re-introduction of the constructor is still undecided. The resolution to the discussion on this bug will come from the resolution to bug 21851, so I will close this bug as a duplicate. *** This bug has been marked as a duplicate of bug 21851 ***