- From: Marcos Caceres <w3c@marcosc.com>
- Date: Fri, 23 Dec 2011 01:09:17 +0000
- To: Arun Ranganathan <aranganathan@mozilla.com>, Charles Pritchard <chuck@jumis.com>
- Cc: Ojan Vafai <ojan@chromium.org>, Adrian Bateman <adrianba@microsoft.com>, Feras Moussa <ferasm@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Monday, 19 December 2011 at 01:22, Charles Pritchard wrote: > I don't think it's practical for developers to follow the change logs. I've certainly missed a few. > > While readAsBinaryString and readAsDataURL are very rarely used, it seems to me that editors should take some extra effort to help out developers who have in good faith, jumped on the HTML5 bandwagon. Web Apps and HTML5 seem to me, to be quite different than other specs. I think they're a special case. > > Google code search shows readAsDataURL to be about as popular as the deprecated readAsBinaryString. It'd be nice if somewhere, near the spec but not in it, this history was maintained in a readable and index-able form. Change logs do accomplish that, but they are more difficult to get to. > > http://www.google.com/search?q=readAsBinaryString > > I do think that this deprecated feature can be removed from the File API spec altogether. I'd still like a human-usable place to point to. > > Scenario: Alice, a random developer, sends a note to Bob a phonegap committer about readAsBinaryString being deprecated. Bob is surprised, looks at the File API spec and sees that the method indeed is missing. "What happened?", wonders Bob. Bob knows the specs are in constant flux, and doesn't know what to do. Bob is scared. > > Even a simple Editors log supplemental would give some credibility and explanation for the change, allowing Bob to feel more confident in removing hooks, even allowing Bob to update his own change logs with references to the editor's changes. > > It's just a bit more formal than pointing to VCS revision markers. > > I hope I've helped a little here. To be absolutely clear: I'm fine with the method being removed, and I'm not demanding the editor stash the old IDL, text nor reason in any particular place. I'm just requesting we consider that, as part of this living spec process, we maintain a living journal of deprecated APIs. +1 Please see WebIDL's change logs… they are pretty good. I've had a few "Bob" moments as described above, and the WebIDL logs have been wonderfully helpful and informative. -- Marcos Caceres http://datadriven.com.au
Received on Friday, 23 December 2011 01:09:50 UTC