Re: [sdw] What would implementing WebVMT mean for user agents?

Good points.

I'd originally thought of _requiring_ the `div-id` map property to link the `<video>` to a `<div>` element, but then relaxed this to an _optional parameter_ so that if the `div-id` (or the `tile-url`) was omitted then a default value would be used. However, I agree with your analysis: the VMT file should be agnostic of the web page.

What if `div-id` and `tile-url` were attributes of the `<track>` element instead, alongside the `src` attribute? That would provide the same connection within the HTML page and make the VMT file independent of it, which may be a better solution. I've also been thinking about a `map-api` property to specify the map renderer (API), e.g. Google Maps, OpenLayers, Leaflet, etc. If all three properties were attributes of the `<track>` element, that would provide sufficient information for the user agent to load the correct map rendering scripts.

This system works in a similar way to embedded YouTube video content, which can be included in a self-populating `<iframe>` element. Rendering the map in an `<iframe>`, rather than a `<div>` element, would add some complexity to synchronisation messaging, as two discrete web pages would have to communicate, but it might be worth considering. Current web map APIs use a `<div>` element as their root.

I think the goal is to parse the VMT file and issue map `VMTCue`s to a receiver at the correct time, though I've not yet specified that interface, i.e. item 1 only. I believe that information flows from the video player to the map controller _only_, and never in the opposite direction. The `VMTCue` interface should provide a natural boundary between items 1 and 2, so the rendering process is entirely separate though may have a type influenced by the `map-api` property.

As map rendering is not supported in user agents currently, there is a more general question of how to handle the transition if they do support it in future, which is probably beyond the scope of this project, though still worth discussing in a separate thread.

GitHub Notification of comment by rjksmith
Please view or discuss this issue at using your GitHub account

Received on Friday, 16 March 2018 15:54:46 UTC