[Webkit-unassigned] [Bug 110479] [Meta] Implement support for TTML

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110479





--- Comment #10 from Glenn Adams <glenn at skynav.com>  2013-02-21 18:59:08 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > I would not agree with a number of your above statements:
> > 
> > * that TTML content needs to be translated into a list of cues (as currently defined)
> > * that TTML content needs to be mapped to HTML or CSS
> > * that it is impossible to implement TTML without these clarifications
> > * that it is impossible to implement TTML compatibly between browsers
> > 
> > It may very well be possible to translate a profile of TTML, e.g., SMPTE-TT or SDP-US, into the current definition of text track cues, and that may be the first step in implementing support for such a profile. But it isn't necessary to do this in order to implement a compliant TTML presentation processor that is able to render a <track/> element that references a TTML resource.
> 
> 
> <track> is a replaced element as listed here: http://www.w3.org/TR/html5/single-page.html#replaced-elements . Replaced elements are mapped into the DOM through mapping to an Object. 
> 
> <track> is mapped to a TextTrack object.
> http://www.w3.org/TR/html5/single-page.html#the-track-element
> 
> A TextTrack object consists of a TextTrackCueList for active and for parsed cues.
> http://www.w3.org/TR/html5/single-page.html#texttrack
> 
> I fail to understand how you can represent TTML in the browser without making use of these constructs that <track> stands for.

Where did I see I wouldn't make use of these constructs?

4.8.10.12.1

"A list of zero or more cues
A list of text track cues, along with rules for updating the text track rendering. For example, for WebVTT, the rules for updating the display of WebVTT text tracks. [WEBVTT]"

4.8.10.12.4

"How a specific format's text track cues are to be interpreted for the purposes of processing by an HTML user agent is defined by that format. In the absence of such a specification, this section provides some constraints within which implementations can attempt to consistently expose such formats."

4.8.10.1.5

"The getCueAsHTML() method must convert the text track cue text to a DocumentFragment for the script's document of the entry script, using the appropriate rules for doing so. For example, for WebVTT, those rules are the WebVTT cue text parsing rules and the WebVTT cue text DOM construction rules. [WEBVTT]"

Nothing here requires populating cues. That is, the set of cues could be exposed or not via the DOM. It doesn't mandate their exposure, and it leaves it up to the specific format to decide what it means to expose its content in the form of cues. Further, it doesn't mandate whether a cue, if present, returns an HTML representation, or if it does, what it means or how it relates to the source track format.

I'm just not seeing a problem here so far. I've agreed that it would be nice and even possible to specify an explicit mapping, and I think that is something worth doing. But failing to do so doesn't prevent supporting TTML and adhering to the currently defined APIs. (Though see the two new bugs I posted earlier [1][2] where too much is assumed about use of WebVTT.)

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21079
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21080

> > Since IE10 does implement some level of support for TTML, it would be worth learning if they attempt to map to HTML/CSS and TextTrackCues as you suggest.
> 
> I don't have a Windows7 machine and IE10 at hand to test it, but I am 99% sure that the parsed cues are mapped into a TextTrackCueList both for TTML and WebVTT. Since IE10 only supports simple captions (starttime, endtime, text) and no formatting, all they had to do was to map the <p> elements into cues. That's the simple part of the mapping, but it's a start.
> 
> You can experiment with their implementation here on their example page:
> http://ie.microsoft.com/testdrive/Graphics/VideoCaptions/Default.html

Thanks, I'll look into this more. In any case, I'm not sure I follow your desire to map cue content to HTML. What is the purpose of this? Is it because you are assuming the implementation will take the resulting HTML and format it to present the cue? If so, I think that assumption is implementation specific, and not borne out by the spec. If it is implied by the spec, then I will need to file a bug asking that implication be removed, since it is not semantically necessary.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.