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

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

--- Comment #5 from Philip Jägenstedt <philipj@opera.com> 2011-09-10 16:31:42 UTC ---
(In reply to comment #4)
> It makes all kinds of extensions possible, for example it allows configuration
> default blocks, etc, all by just having the syntax not include a valid time
> range in the second line of the block. Your proposal (which if I understand
> correctly is to just keep trying to read a time line until it's successful?)
> would preclude that. So far, all the extensions proposed have been of this
> nature, rather than of the nature of adding features to a cue — which we can
> already do anyway, by adding more settings after the time range (which is why
> invalid settings are ignored, and don't cause the cue to be dropped).

I don't follow, at all. For default blocks in the beginning of the file, why
would it include a timing line at all? It would be skipped entirely. For
additional settings on cues on lines before or after the id line, dropping the
cue entirely seems like terrible fallback.

-- 
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 Saturday, 10 September 2011 16:31:45 UTC