Re: [MEDIA_PIPELINE_TF] ISSUE-34: ViewPort-Support

Hi Sylvia,

> Can you fill the TextTrack object and the cues from a SVG? As long as
> you can make a mapping, it's possible. If the format doesn't fit with
> the elements, then it's an orthogonal concept that won't fit the bill.
Reading it says:
"A text track consists of:"
* "The kind of text track": would apply to SVG tracks
* "A label": would apply to SVG tracks
* "A language": would apply to SVG tracks
* "A readiness state": would apply as well
* "A mode": same
* "A list of zero or more cues"

A Cue is defined as:
* "An identifier": applicable to SVG tracks

* "A start time"/"An end time":
As such SVG does not define frame-based content as Flash would do or other subtitling formats, but you can define frame-based content such as:

* A pause-on-exit flag:
not sure what it means but seems applicable

* A writing direction: when restricted to unidirectional text content, it would be applicable but I don't see it in the TextTrackCue object (

* A size:
not sure I understand why it's not 2 numbers but it could match the SVG width (also not in the interface)

* The text of the cue:
if the SVG animation contains text, it could be passed, if not, could be an empty string (or the content of a <desc> element) if required.

The active flag: applicable
The display state: applicable

What I'm trying to say is that it seems very restrictive to limit the track element to pure text tracks. It disables interesting use cases (synchronized graphics overlay) while options to do it are there with SVG, already implemented in browsers.

> In my understanding, SVG has a complex DOM that goes far beyond what
> TextTrack is capable of representing.
I don't get this point. The definition of a TextTrack element should not care about the expressiveness of the language used to represent the text content as long as this language can be mapped to the TextTrack features: if it has graphics or not, if it can do bold/italic or not, if it can do bidi text or not ...

> So, I think it's too rich a
> format for the feature.
"Oh I don't want your color TV, I just need a black-and-white one".

> Of course you can always throw any format at a HTML element.However,
> if browsers don't support it, you can only deal with it through
> JavaScript - so it's not a standardised feature and not really
> relevant to the W3C.
SVG is not any format. It's a W3C format. I think it's relevant.


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France

Received on Thursday, 11 August 2011 09:36:26 UTC