Re: Draft for summary of an HTMLCue proposal

On Fri, Aug 14, 2015 at 6:26 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> Andreas, all,
>
> I've done some digging in blink on this following our discussion yesterday
> and Silvia's suggestion to think about this in a browser development
> context.
>
> disclaimer: I'm not claiming to be 100% sure I've understood exactly how
> it works just yet!
>
> It does broadly look as though it works by generating an equivalent HTML.
>
> VTTCue is derived from TextTrackCue, and the implementation code can be
> viewed in a browser at
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebK
> it/Source/core/html/track/vtt/VTTCue.cpp
>
> The VTTCue::getCueAsHTML() method returns a fragment of HTML stored in the
> private m_cueBackgroundBox private member pointer variable of the VTTCue
> class, to cherry-pick an example.
>
> It therefore looks as though it would be very straightforward to create an
> HTMLCue class as per the proposal, that would have an HTML fragment
> created on construction and simply return it when requested. We could
> highlight this close alignment between the blink VTTCue implementation and
> our proposed HTMLCue in our communications with the HTML WG and others,
> for example.

VTTCue::getCueAsHTML() is merely the implementation of the spec's
VTT.getCueAsHTML():
http://dev.w3.org/html5/webvtt/#dfn-vttcue-getcueashtml

What it returns is not used for rendering, which is confusing. It
doesn't have anything to do with m_cueBackgroundBox AFAICT.

The DOM fragment actually used for rendering comes from
VTTCue::getDisplayTree(), and there's also the LayoutVTTCue class, in
the case of WebVTT it's not just a matter of inserting DOM fragments,
the layout code is needed to get the line stepping and overlap
avoidance right.

Philip

Received on Monday, 17 August 2015 10:09:36 UTC