W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

Re: Timestamps in cues

From: Victor Carbune <victor.carbune@gmail.com>
Date: Wed, 26 Sep 2012 19:50:40 +0300
Message-ID: <CA+nQPrmJXPRfdrX4BaAK_n+TZPnB4DSaOpeOxWVwPEDAZ3gj8w@mail.gmail.com>
To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>
On Wed, Sep 26, 2012 at 6:22 PM, Cyril Concolato
<cyril.concolato@telecom-paristech.fr> wrote:
> Hi all,
> What is the correct behavior when an embedded timestamp in a cue is not
> within the range of the start/end times of the cue?
> I've made an example here:
> http://perso.telecom-paristech.fr/~concolat/html5_tests/webvtt-late-cue.html
> <http://perso.telecom-paristech.fr/%7Econcolat/html5_tests/webvtt-late-cue.html>
> Here an inline timestamp in the second cue has a value greater than the end
> of the cue. Chrome does not display the text after the timestamp. Opera
> displays it. This is what I prefer as my understanding, correct me if I'm
> wrong, is that inline timestamps only affect :past and :future behavior.
You are right, with the existing spec, the timestamps should have no
effect on the text displayed, unless there's proper CSS associated
with them. I have registered a bug on Chrome for this.

However, I believe that timestamps generally need to be improved:
1) The spec should support the opacity: 0 or visibility: hidden
property (reported as bug 18519 [1])
2) Ignoring timestamps by default is not natural: it forces the author
to always add the one-line CSS to hide the future nodes (given that 1)
would be supported). Thinking about VTT players without CSS support,
I believe that the default behavior should be to hide the future nodes.
3) We definitely need a resolution for matching simple text between
timestamps, before these can be simply used within any browser
(reported as bug 16875 [2])

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18519
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16875

Received on Wednesday, 26 September 2012 16:51:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:20 UTC