Re: TextTrack API changes

I think that is a worse interface than the default "undefined" return value
in JavaScript, because it doesn't allow a JS developer to distinguish
between when there is really an empty string returned as the actual value
in contrast to that functionality not being available on a text track cue
type. I'd prefer we just leave it as is.
Silvia.

On Wed, Apr 24, 2013 at 3:04 PM, Glenn Adams <glenn@skynav.com> wrote:

> I would prefer to keep both .text and getCueAsHTML() in the generic
> interface, and simply define it to return the empty string if no text or
> HTML mapping applies.
>
>
> On Tue, Apr 23, 2013 at 3:21 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> To compare the two new interfaces look at:
>> http://dev.w3.org/html5/webvtt/#webvtt-api (for WebVTTCue)
>> and
>> http://www.w3.org/html/wg/drafts/html/master/single-page.html#texttrackcue(for TextTrackCue)
>> .
>>
>> I had the discussion about .text and getCueAsHTML() with Ian, too. Here
>> are his thoughts on why not to add .text to the attribute list of
>> TextTrackCue:
>>
>> > .text provides the uninterpreted content of a cue - every format will
>> > have such.
>>
>> Not necessarily. DVD subtitles wouldn't have one, they'd likely have
>> something that returned an ImageBitmap or some such. TTML probably
>> wouldn't have one, since their format is structured DOM and might never
>> have had a textual form (think script-created DOMs) -- they'd just have a
>> way to get a pointer to the relevant node in the actual DOM tree, I'd
>> guess. Other formats might have other needs, e.g. EBU might want to just
>> expose the Text Field as a raw 112 byte ArrayBuffer; I don't know how
>> you'd really expose an unparsed DOMString for EBU.
>>
>>
>> At this point, it actually doesn't matter how we make the distinction
>> between what attributes / functions stay on TextTrackCue and which go to
>> WebVTTCue, because the only one that can be instantiated is WebVTTCue. When
>> TTMLCue or some other format comes along and creates another interface, and
>> we find out that there are more shared attributes, then we can still make
>> that change. It's probably better to stay minimal until then.
>>
>> Regards,
>> Silvia.
>>
>>
>> On Wed, Apr 24, 2013 at 4:53 AM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>> I agree with Bob. I'm afraid I didn't look at the API details off the
>>> changes, but I'd suggest that Sylvia summarize which API features she would
>>> like to move from TextTrackCue to WebVTTCue, and that we can then review
>>> which of those features should remain generic.
>>>
>>>
>>> On Tue, Apr 23, 2013 at 12:37 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>>>
>>>>  It seems to me that the distinction between "replaced" vs
>>>> "reorganized" has to do with what got moved from TextTrackCue to WebVTTCue.
>>>> I would have thought that getCueAsHTML and getCueAsText would be generic
>>>> across formats and therefore a candidate to remain with TextTrackCue.
>>>>
>>>>  Bob
>>>>
>>>>   From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>>>> Date: Tuesday, April 23, 2013 2:57 AM
>>>> To: "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>
>>>> Cc: Glenn Adams <glenn@skynav.com>, Bob Lund <b.lund@cablelabs.com>,
>>>> Mark Vickers <mark_vickers@cable.comcast.com>, public-html <
>>>> public-html@w3.org>
>>>>
>>>> Subject: Re: TextTrack API changes
>>>>
>>>>   To add to that, we've not *replaced* TextTrackCue with WebVTTCue,
>>>> but we have reorganised TextTrackCue as an abstract cue interface and
>>>> created WebVTTCue only in the WebVTT spec. Note also that <track> continues
>>>> to exist as is and will continue to take WebVTT in its @src attribute (as
>>>> well as TTML in IE10).
>>>>
>>>> I hope that addresses your concerns?
>>>>
>>>> Thanks,
>>>> Silvia.
>>>>
>>>> On Tue, Apr 23, 2013 at 10:51 AM, Glenn Adams <glenn@skynav.com> wrote:
>>>>
>>>>> There is no part of this change that entails creating a new element
>>>>> (tag) for different tag formats. Rather, this change improves the
>>>>> definition of some of the text track API interface to move VTT specifics
>>>>> out of the HTML5 spec. This is entirely appropriate since it is expected
>>>>> that TTML (and other formats) will be used for time text track content. In
>>>>> fact I believe IE supports TTML to some extent (though I'm not familiar
>>>>> with the details of this support).
>>>>>
>>>>> On Mon, Apr 22, 2013 at 12:26 PM, Jerry Smith (WINDOWS) <
>>>>> jdsmith@microsoft.com> wrote:
>>>>>
>>>>>>  I have some concerns about these changes.  They create a new
>>>>>> element that is specific to a file format.  Format specifics like this are
>>>>>> normally abstracted away.  For instance, for images we don’t have
>>>>>> <jpegimage>, <pngimage> etc…  It would be very inconsistent to have WebVTT
>>>>>> variants for TextTrack.****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> What are the plans for other captioning formats?  Would we similarly
>>>>>> propose having a ttmptextcue object?****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> Jerry****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> *From:* Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>>>>>> *Sent:* Wednesday, April 17, 2013 5:26 PM
>>>>>> *To:* Bob Lund
>>>>>> *Cc:* Mark Vickers @ Comcast; Glenn Adams; public-html
>>>>>>
>>>>>> *Subject:* Re: TextTrack API changes****
>>>>>>
>>>>>>  ** **
>>>>>>
>>>>>> I will apply this to HTML5.0 next week if there are no objections.
>>>>>> Cheers,
>>>>>> Silvia.
>>>>>>
>>>>>> ****
>>>>>>
>>>>>> On Thu, Apr 18, 2013 at 3:28 AM, Bob Lund <B.Lund@cablelabs.com>
>>>>>> wrote:****
>>>>>>
>>>>>>  +1****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> *From: *<Vickers>, Mark Vickers <mark_vickers@cable.comcast.com>
>>>>>> *Date: *Wednesday, April 17, 2013 11:21 AM
>>>>>> *To: *Glenn Adams <glenn@skynav.com>
>>>>>> *Cc: *Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html <
>>>>>> public-html@w3.org>
>>>>>> *Subject: *Re: TextTrack API changes
>>>>>> *Resent-From: *<public-html@w3.org>
>>>>>> *Resent-Date: *Wednesday, April 17, 2013 11:22 AM****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>>  I'd very much support this change as it will significantly improve
>>>>>> TextTrack. Though, I think it should be made to both 5.0 & 5.1 or neither,
>>>>>> to avoid backwards-incompatibility. ****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> Thanks,****
>>>>>>
>>>>>> mav****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> On Apr 8, 2013, at 2:26 PM, Glenn Adams <glenn@skynav.com> wrote:****
>>>>>>
>>>>>>
>>>>>>
>>>>>> ****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> On Sun, Apr 7, 2013 at 11:42 PM, Silvia Pfeiffer <
>>>>>> silviapfeiffer1@gmail.com> wrote:****
>>>>>>
>>>>>>  Hi all,****
>>>>>>
>>>>>> Recently, I cherry-picked some changes to the TextTrack API from the
>>>>>> WHATWG repository into the HTML5 specification.
>>>>>>
>>>>>> In particular, I am referring to these patches:
>>>>>>
>>>>>> ** Split TextTrackCue into an abstract TextTrackCue interface and a
>>>>>> WebVTT-specific interface WebVTTCue. Makes it easier to use TextTrack with
>>>>>> other file formats.
>>>>>>
>>>>>> https://github.com/w3c/html/commit/586ae3996fdce5d9f71cbe57a08759fce7b26d8f
>>>>>> WHATWG: 98cdbf20015b11ae7febc581280c3ce02dcd800e (7742)
>>>>>>
>>>>>> ** Split more WebVTT-specific things into the WebVTT spec. This also
>>>>>> makes some normative changes to HTML for handling non-WebVTT cue types, but
>>>>>> that shouldn't affect any existing implementations.
>>>>>> https://github.com/w3c/html/bdae138d123ddb73586eb8d7f39761ec93e3aa28
>>>>>> WHATWG: 0776094323b3f44cbf88eb9f023f4b12c3a6b6a9 (7748)
>>>>>>
>>>>>> The aim of these patches was two-fold:
>>>>>>
>>>>>> Firstly, they provide for a cleaner cut between the WebVTT
>>>>>> specification and the HTML specification. This was in preparation for a
>>>>>> removal of the WebVTT text from the source file from which the HTML
>>>>>> specification is created such that the WebVTT specification can now be
>>>>>> edited separately (see
>>>>>> https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html
>>>>>> ).
>>>>>>
>>>>>> Secondly, these changes make the TextTrack API abstract and thus more
>>>>>> easily extensible to other file formats such as TTML.
>>>>>>
>>>>>> The downside of the changes is that TextTrackCue is now an abstract
>>>>>> interface without a constructor (instead, the WebVTT spec provides the
>>>>>> WebVTTCue constructor). This breaks existing implementations of the
>>>>>> TextTrackCue interface in webkit-based browsers (including blink) and in
>>>>>> presto. IIUC, Mozilla and IE are not supporting TextTrackCue yet. Also,
>>>>>> analysis on the webdevdata collection suggests that the TextTrackCue
>>>>>> constructor is not used much on the Web yet, so this is still a good time
>>>>>> to break the interface (see
>>>>>> http://lists.w3.org/Archives/Public/public-texttracks/2013Apr/0006.html
>>>>>> ).
>>>>>>
>>>>>> While I have right now only applied these changes to HTML5.1, I am
>>>>>> considering applying them to HTML5.0 as well if presto, webkit and blink
>>>>>> decide to change their implementation and gecko and trident decide to
>>>>>> support the new specification. I am looking for advice on such a move.
>>>>>> ****
>>>>>>
>>>>>>  ** **
>>>>>>
>>>>>> Thanks for doing this. I think this makes this functionality more
>>>>>> useful and more consistent with existing MIME type independent interfaces.
>>>>>> Cox supports these changes.****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>>  ** **
>>>>>>
>>>>>>    ** **
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>