- From: Brendan Eich <brendan@mozilla.org>
- Date: Wed, 13 Apr 2011 12:38:49 +0200
- To: Darin Fisher <darin@chromium.org>
- Cc: public-webapps@w3.org
On Apr 13, 2011, at 7:01 AM, Darin Fisher wrote: > Agreed. I certainly don't assert that whatever Chrome ships first should be regarded as standard. Our rapid release schedule depends on platform features beginning life with a vendor prefix. I believe that we goofed in this case by not vendor-prefixing the slice method. More on this below... Vendor prefix may just add to the names developers have to juggle, and kick the can down the road a bit. If we can go from WD to REC with a single name and signature/semantics, even better. Here is a case where hedging with a vendor prefix arguably would have helped, in hindsight. OTOH other HTML5 prototype implementations in the past many years did well to avoid vendor prefixes. > s/Kenneth Arnold/Kenneth Russell/ Jetlag dredged up an old Unix name -- apols to Ken R. > Blobs are views on immutable data. WebKit's implementation will reject reads on a Blob, which points to a file that has since been modified. (This should be part of the spec if it is not.) This does seem slightly underspecified :-P. > One option we can consider is to rename Blob.slice to Blob.webkitSlice and adopt the newer arguments. I think we would want to similarly vendor-prefix BlobBuilder and FileReader as those too are non-standard. This change runs just as much risk of breaking Chrome-specific content; however, the failure mode (absence of a method) should be easier for apps to cope with. > > I'm not stating that we will do this yet. I'm just proposing it as another approach to consider. I'll discuss this idea with others on the team tomorrow. This sounds like a good way forward for the various parties. > By the way, I'm not too concerned about having to fix Google web apps. I'm much more concerned about third-party, Chrome-specific content available as either apps or extensions through the Chrome app store. It is hard to grep for instances of Blob.slice!! Indeed. http://codesearch.google.com's regexps are not quite up to this -- need to mix in some http://doctorjs.org/ and make a "semantic grep". /be
Received on Wednesday, 13 April 2011 10:39:21 UTC