If we need to break compatibility with SRT, maybe we shouldn't call it WebSRT.

Maybe a header and metadata is required to identify specific cases, e.g. the language tag. If we're adding a header and breaking compat, the encoding could always be UTF-8.

We discussed the UI and what it might be like: context menu, a button next to the seek bar.

We discussed the UI and what it might be like: context menu, a button.

Only specific track types appear in the UI, not metadata. Only some are visually displayed: subtitles, captions.

Problem: http://ale5000.altervista.org/subtitles.htm

All of these special formats need to be supported.

Also, now, WebSRT introduced extra stuff that will make this landscape further complex.

Maybe a header and metadata is required to identify specific cases, e.g. the language tag.

If we need to break compatibility with SRT, maybe we shouldn't call it SRT.

We discussed the UI and what it might be like: context menu, a button.

Is SRT WebSRT++?

Why does WebSRT do both subtitles/captions and the cue event shorthands in the same format?

Is SRT WebSRT++?

Why does WebSRT do both subtitles/captions and the cue event shorthands in the same format?

Because it makes it easier to deal with these through the same events and they are essentially the same.

[

== Is SRT WebSRT++? == Somewhat, the intention is to be mostly compatible with much of existing SRT syntax and also to work well enough with existing standalone players.

== Why does WebSRT do both subtitles/captions and the cue event shorthands in the same format? ==

WebSRT spec: http://www.whatwg.org/specs/web-apps/current-work/websrt.html

Present: Jeroen, Jean-Baptiste, Philip, Ralph, Sebastian, Sanjay, Silvia