[Bug 13943] <track> The "bad cue" handling is stricter than it should be

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13943

--- Comment #13 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-09-28 01:45:07 UTC ---
(In reply to comment #11)
> I agree with Philip. The parser shouldn't drocanianly drop cues for trivial
> authoring mistakes. I don't know if we need to polish the parsing of the id
> (though I don't mind that), but certainly the timestamp parsing needs
> polishing. From what I remember when looking at SRT content, it's not uncommon
> to have various mistakes in the timestamp. Usually you don't notice the error
> (until you validate the file or check a browser's error console). The parsing
> of timestamps should be DWIM (doesn't need to be compatible with SRT
> implementations though).
> 
> 1:01.000 = 01:01.000
> 01:1.000 = 01:01.000
> 01:01,000 = 01:01.000
> 01:01.5 = 01:01.500
> 01:01.5000 = 01:01.500

Maybe.

> 01:61.000 = 02:01.000

It would be bad if we accepted this kind of mistake IMHO. Think e.g. about
01:5432153.000 - that's neither readable nor makes it much sense at all as a
time format.


I'm in two minds about this.

On the one hand, allowing simpler time formats (such as just
seconds.milliseconds) would be a nice simplification to allow and makes it
easier to convert from other formats that use such a formats.

On the other hand, every simplification that we introduce into authoring makes
the parsing much harder. With the fixed format that is currently given,
implementing a parser is really trivial. Allowing for all the exceptions and
authoring errors will give us all sorts of edge cases. For example, in SRT
01:01.5 is actually interpreted by some players as 01:01.005 and by others as
01:01.500 . We'd have to introduce rules on what these things actually mean and
then implement more complex parsers.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 28 September 2011 01:45:13 UTC