- From: Victor Carbune <victor.carbune@gmail.com>
- Date: Wed, 26 Sep 2012 19:50:40 +0300
- 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 Victor
Received on Wednesday, 26 September 2012 16:51:31 UTC