- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 26 Apr 2012 13:26:04 +1000
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Ian Hickson <ian@hixie.ch>, Victor Carbune <victor.carbune@gmail.com>, public-texttracks@w3.org
On Thu, Apr 26, 2012 at 9:05 AM, Glenn Maynard <glenn@zewt.org> wrote: > On Wed, Apr 25, 2012 at 3:12 PM, Ian Hickson <ian@hixie.ch> wrote: >> >> Such a situation is possible because there's nothing we can do to stop >> authors from making mistakes. Whether we drop the cue when the cue is >> found to have negative duration, or leave it in the DOM as is, or somehow >> normalise the values so duration is zero or positive, etc, is merely a >> design trade-off. In this case, it turns out to be simpler to just leave >> the cues in the DOM than try to filter them out. > > > I disagree. While it's hard to stop them from being added by the API, it's > trivial to filter them out in the parser. Doing this means that > implementations which don't expose an API (eg. media players) have smaller > testing requirements; they only need to test that they're discarded at the > parser. I agree. Keeping such faulty cues in the objects will just result in a need for extra error handling in the browsers and other implementations, which have to continuously check if the next cue in the TextTrackCueList is valid before attaching callbacks and doing rendering etc. Also, all the browser developers on this list agreed to drop such cues on the floor in the parsing step, which is a pretty big argument IMO. >> It also makes it easier for cue editors to use the parser and API without >> having to worry about >> losing cues that happen to have incorrect timings. > > I don't see the value. If it's an invalid cue, then it's no different than > losing a cue that happens to have a syntax error. In fact, if we don't lose it, they may never notice their mistake, seeing as it ends up in the cue list structure. Silvia.
Received on Thursday, 26 April 2012 03:26:53 UTC