On Tue, Feb 28, 2012 at 1:50 AM, Israel Hilerio <[email protected]> wrote: > Anne, > > > > That is certainly one point of view. However, we’ve been collecting > features for a v2 since before June of 2011 [1]. To that effect, we’ve had > several email exchanges between the WG members where we agree to defer work > for v2 (see [2], [3], etc.). That tells me that our working group is > committed to delivering a v1 version of the spec. Furthermore, the fact > that we have a v2 list doesn’t invalidate the functionality we defined in > v1. For example, there is no reason why the change you are proposing > couldn’t be introduced in v2 and still be backwards compatible with our > legacy code. > > It is our belief based on internal feedback and external partner feedback > that the technology will remain un-deployed and in draft form if we continue > to make changes like this.
I completely agree that we should aggressively postpone new features for v2 and get v1 out the door as soon as possible. I wouldn't propose that we make a change such as this one if we couldn't create as good of a backwards compatibility story as we can here. I.e. basically no deployed code should need to be changed. I also wouldn't propose this if I thought this was something that we can change in v2. However changing the return value of .readyState, .mode and .direction can't be done in a backwards compatible way. Once wide-spread adoption happens (which will most surely happen before we can get v2 out the door) we won't be able to change them. Finally, I really think this is the last of the potentially sensitive changes we'll make. We've recently had a third browser vendor go through the spec with a fine comb and so far this is the only controversial issue found. I think that's a good indication that we'll be able to keep the rest as is. I'm definitely with you on that we need to get a specification with a W3C Rec stamp in order for adoption to start ramping up, something that I'm quite eager to see as you can imagine :) / Jonas
