- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Feb 2011 09:44:57 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12076 Philip Jägenstedt <philipj@opera.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philipj@opera.com --- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-02-15 09:44:56 UTC --- I'm calling this a wishlist item because it is editorial. Still, here's my reasoning: When I made a JavaScript implementation of the earlier WebSRT parser, I found it quite hard to follow the steps because of how handling of CRLF is sprinkled all over, and even found a spec bug related to it (fixed already). Of course the spec should be precise down to every single byte what should happen, but I'm hoping that could happen with a line-based parser as well. If it's not obvious, by a line-based parser I mean one which operates on the input and generates lines for a second step. This wouldn't harm streaming, because AFAICT no cues will be output from the parser before CRLF or EOF is encountered anyway. I dare say this makes it more likely that implementations of WebVTT in high-level languages like JavaScript and Python will actually follow the spec, since operating on lines is quite easier to understand for a format like WebVTT. If you go and look for random SRT parsers, I think you'll find that most work like this. (The ones I've written do anyway.) The spec is already mostly line-based, I'm just suggesting that the line-splitting be separated out from the rest to improve readability. Do as you will. -- 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 Tuesday, 15 February 2011 09:44:59 UTC