[Bug 21851] revert removal of text and getCueAsHTML members; address constructor changes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851

--- Comment #22 from xham <graham.clift@am.sony.com> ---
(In reply to comment #21)
> I've thought about this some more and my suggestion for resolution is at
> http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange#.283.
> 29_Removal_of_TextTrackCue_constructor 
> 
> On top of renaming TextTrackCue to AbstractTextTrackCue and introducing an
> unparsed TextTrackCue API, I also suggest renaming
> inBandMetadataTrackDispatchType on TextTrack to cueFormatHint.
> 
> The cueFormatHint would be filled by the browser not just for in-band
> tracks, but also for files coming from <track>. For example, parsing a
> WebVTT file with captions would result in a cueFormatHint of "webvtt", but
> parsing a WebVTT file with metadata or chapters or descriptions would give a
> cueFormatHint of "plaintext". Or if the browser knew that it was metadata
> and knew it was JSON, it could set cueFormatHint to "json".
> 
> Then, it's clear which XXXCue object should be used to parse the .cues in
> the TextTrack.

You proposal for resolving "Removal of .text from TextTrackCue" is to
re-introduce the .text attribute.
Your proposal for resolving "Removal of TextTrackCue Constructor" is to
introduce the new TextCue that inherits from TextTrackCue. 

However it appears that the TextCue also has a .text attribute. 

Is the intention to change the resolution of the first proposal to say:
re-introduce the .text attribute, but on the new TextCue interface?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 24 July 2013 23:25:45 UTC