This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16480 - Declarative TV Mosaic
Summary: Declarative TV Mosaic
Status: NEW
Alias: None
Product: Web & TV
Classification: Unclassified
Component: Media Pipeline TF (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Clarke Stevens
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-22 16:49 UTC by David Corvoysier
Modified: 2012-12-04 00:52 UTC (History)
2 users (show)

See Also:


Attachments

Description David Corvoysier 2012-03-22 16:49:32 UTC
**Description**:

TV service providers typically dedicate a channel to advertize their programmes through a Mosaic displaying several channels at once.
From this specific channel, the end user is able to pick one of the programmes and switch to the corresponding channel.

The UC would be to allow a web application to provide mouse and keyboard interaction with the sub-sections of a video frame corresponding to the channels of a TV mosaic without requiring too much specific code.

**Need/justification**

The UC can be solved with existing technologies in at least two ways:

Solution A:
First, the web application can apply a set of well-organized HTML elements as an overlay to a video element, and associate anchors to these elements to trigger the appropriate action when the end user activates them.    

Solution B:
Second, the application can catch all input events received by the video element, and apply a specific calculation algorithm to trigger the appropriate actions when the portion of the video corresponding to a channel is meant to be selected.

Drawbacks of these solutions:
- they increase the page complexity (more DOM+CSS or more javascript) -> more processing power, error prone
- they don't allow the web application to take advantage of the video element native controls (because the overlay or the javascript will capture the events) 
Note: What about accessibility ?  

Using a declarative syntax to describe the areas corresponding to the mosaic channels in the video frame and associating actions or links to them would be much simpler and would preserve the ability to use the video tag native controls. 

**Category**
This requires an evolution of the HTML5 specification

**PROPOSAL**:

Since the HTML5 map element already provides the expected features to the img or object tags using only a declarative syntax, the proposal is simply to allow the HTML5 map element to be applied also on video elements.
Comment 1 Philip Jägenstedt 2012-04-10 08:48:05 UTC
It sounds like "more DOM+CSS or more javascript" is needed in the suggested solution as well, since simple links can't change the source of the video, and after one has changed the source the <map> must be removed since it no longer makes any sense.

How about simply tuning each channel into individual <video> elements and on clicking "zooming in" that channel while ramping up the volume? That seems to make better use of the capabilities of the platform as a whole...