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

[bugzilla-daemon at webkit.org]

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





--- Comment #16 from Glenn Adams <glenn at skynav.com>  2013-02-21 21:01:40 PST ---
(In reply to comment #14)
> (In reply to comment #13)
> > > Are you further suggesting to "just render" the text on top of the video without adding it to the shadow DOM?
> > 
> > I'm not exactly sure what you are referring to as shadow DOM here, but if you are referring to TextTrack, then there is no reason not to provide a TextTrack object. But individual cues aren't needed in TextTrack to  perform formatting of TTML content.
> 
> The way it's currently specified, rendering relies on having TextTrackCues.

I don't see that. Please point out where the spec mandates that interpretation. I can see how some implementation may depend on this, e.g., the WK support for VTT, but it is certainly not a necessary implementation.

> 
> > > How is this rendering supposed to work? Are you intending to render pixels into the video before the video is displayed?
> > 
> > I'm assuming there is a reasonable implementation specific way to overlay a graphics layer over a video layer in WK's display pipeline. Since WebVTT is displaying over video, then clearly there is some functionality there to support this.
> 
> Try opening up an example video with <track> in Chromium or Chrome and open your inspector. Activate the "Shadow DOM" functionality of inspector and look at how captions are rendered. They are not rendered into a graphics layer but into the Shadow DOM.

That's just a possible implementation approach, and not mandated by the spec. If it is mandated by the spec, please tell me where.

> > > The way in which <track> is specified in HTML5 is that it introduces content into the browser that a JS developer can manipulate. Therefore it populates all of the objects. This is intentional and not a bug.

Sure, and that's great. But it is not a logical consequence of the current spec language. Further, exposing cues to JS to permit events or JS manipulation of cues is not a technical requirement to be able to process and present track content. It is simply the approach that has been taken for VTT.

Don't get me wrong, I'm not objecting to doing this, and I'd like to see a mapping of TTML into exposable cue objects. I'm only saying that I don't see it as necessary, either for providing TTML rendering or HTML5 spec compliance.

> > 
> > Sure. But there is nothing in the HTML5 spec that says that cues (or what might be considered a "cue") *must* be exposed and can't be implicitly presented or otherwise processed without exposing actual cue objects. At least there is nothing I'm aware of that mandates this. Please correct me if I've missed it.
> 
> I think you've missed it. Try implementing TTML support and you'll certainly come across it.

If I missed it (in the spec), then please point it out. If I move forward with implementing TTML in WK, then I will find out if it is possible to do as I suggest or not. I'm confident that TTML presentation processing can be readily accomplished without relying on the use of text cue objects, shadow dom objects, or translating to HTML/CSS. If I'm wrong, I'll be the first to admit it. At the same time, I will do what I can to define a reasonable mapping to cue objects and HTML/CSS fragments to permit JS exposure. I think both goals are reasonable and independent. Given the upcoming first meeting of the TT Task Force in the Web & TV IG, it might be useful to suggest they take up the task of defining this mapping. I trust that if a mapping is drafted, then you will be able to provide a valuable review of it.

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