WebVTT styling

[Chris Harrelson]

I know next to nothing about WebVTT. But there is an intent to implement and ship involving allowing style sheets to apply to that content. Any thoughts on the design or whether it is a good idea?

https://docs.google.com/document/d/1irKaV9iSOdmL6J4T8x7qWCgf9hvrZaZCSpaphxoPr-U/edit

Chris

[Chris Harrelson]

Gentle ping?

[Rune Lillesveen]

I've been involved in reviewing the implementation in progress along with Fredrik and tried to push this in the right direction implementation-wise. To which extent this is important work, I don't know. The main worry is about the privacy issue already raised in the intent thread about not blocking all non-data: fetches.

[Fredrik Söderquist]

On Thu, Sep 5, 2019 at 2:57 PM Rune Lillesveen <fut...@chromium.org> wrote:

I've been involved in reviewing the implementation in progress along with Fredrik and tried to push this in the right direction implementation-wise. To which extent this is important work, I don't know. The main worry is about the privacy issue already raised in the intent thread about not blocking all non-data: fetches.

I managed to dig up the following https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023 which has some background. (It continues into https://github.com/w3c/webvtt/pull/219 - but that is mostly spec wrangling).

I think the short version is that VTT inline styles allow distribution of a self-contained package (cues and their styling). This in turn means that for example allow converting from other formats with higher fidelity (essentially retaining the style/color scheme; ISTR compliance with CEA 608/708 often being cited as a requirement in the past).

/fs

[Chris Harrelson]

Another ping?

[Chris Harrelson]

On Thu, Sep 5, 2019 at 5:57 AM Rune Lillesveen <fut...@chromium.org> wrote:

I've been involved in reviewing the implementation in progress along with Fredrik and tried to push this in the right direction implementation-wise. To which extent this is important work, I don't know. The main worry is about the privacy issue already raised in the intent thread about not blocking all non-data: fetches.

Ok. But is it actively bad in any way? e.g. introducing unreasonable complexity or performance problems?

[Fredrik Söderquist]

On Fri, Sep 6, 2019 at 11:24 PM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Sep 5, 2019 at 5:57 AM Rune Lillesveen <fut...@chromium.org> wrote:

I've been involved in reviewing the implementation in progress along with Fredrik and tried to push this in the right direction implementation-wise. To which extent this is important work, I don't know. The main worry is about the privacy issue already raised in the intent thread about not blocking all non-data: fetches.

Ok. But is it actively bad in any way? e.g. introducing unreasonable complexity or performance problems?

Rune will have to answer that since I think the complexity is entirely on the style side of things. The currently proposed implementation (what's in review) doesn't strike me as the prettiest, but that doesn't necessarily mean that it complexity in general (since it's a fairly isolated case). The only performance concern that has arisen thus far I think is to identify the cases where matching needs to take place - which doesn't seem like an insurmountable issue (and probably on par with similar features being added that require style matching). But that is my take as a non-style expert.

/fs

[Rune Lillesveen]

On Fri, Sep 6, 2019 at 11:23 PM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Sep 5, 2019 at 5:57 AM Rune Lillesveen <fut...@chromium.org> wrote:

I've been involved in reviewing the implementation in progress along with Fredrik and tried to push this in the right direction implementation-wise. To which extent this is important work, I don't know. The main worry is about the privacy issue already raised in the intent thread about not blocking all non-data: fetches.

Ok. But is it actively bad in any way? e.g. introducing unreasonable complexity or performance problems?

No.