- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 4 Sep 2014 22:41:20 +0000 (UTC)
- To: Loretta Guarino Reid <lorettaguarino@google.com>
- cc: Philip Jägenstedt <philipj@opera.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
On Thu, 4 Sep 2014, Loretta Guarino Reid wrote: > > I would really like a fixed-point version of the spec. There's at least 166 fixed-point versions of the spec. For example, here's version 1.23 (25 April 2012): http://dev.w3.org/cvsweb/~checkout~/html5/webvtt/Overview.html?rev=1.23;content-type=text%2Fhtml Here's version 1.166 (2 September 2014): http://dev.w3.org/cvsweb/~checkout~/html5/webvtt/Overview.html?rev=1.166;content-type=text%2Fhtml There's also patent-licensed-covered version from February: http://dev.w3.org/html5/webvtt/e0a5a82bd5be3501e7649a949fcce4c7b83a427c.html > It is fine for the spec to continue to evolve, but the range of > implementations of WebVTT in different browsers has me pulling my hair > out The spec evolving actually helps that problem, it doesn't hurt it. If the spec didn't change, it would mean that the browsers would have no guidance on how to converge when the spec is known to be wrong. > and it is hard to file bugs against behavior that doesn't match the spec > as the spec continues to move. This would not be solved by having a snapshot of the spec. You could tell people today to implement version 1.166 of the spec. The problem is that when a bug is found in that version, the implementors aren't going to want to implement it. They'll want to implement the fixed version, 1.167. > I think issuing a REC version of WebVTT is the easiest way to define a > fixed version. That's definitely not the easiest way; the easiest way is the way we've already done it: just archive every version ever made. I _think_ what you're _actually_ asking for is "stop making changes to the spec". That is something we should definitely do -- once something has shipped, the spec should match that and that part of hte spec should never change again. If the spec is changing in ways that make deployed interoperable implementations non-compliant, then that's a big issue. But a REC wouldn't stop that, since even having a REC wouldn't stop the spec from continuing to evolve, just like having version 1.23 didn't stop the spec from continuing to evolve. Fundamentally, we always need somewhere to fix bugs that are found, and somewhere to put new features that people ask for and that browsers want to implement. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 4 September 2014 22:41:44 UTC