I'm happy to remove this from the specification. Right now this is marked as
deprecated, which I suppose isn't strong enough discouragement? :)
- Original Message -
Another topic that came up at TPAC was readAsBinaryString [1]. This
method
predates support for typed arrays in the
On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow art.bars...@nokia.comwrote:
Hi Kinuko, All,
Besides the Chromium team, I think it would be helpful if other browser
vendors would state their level of interest for this API (e.g. would review
drafts, prototype, deploy, etc.).
Kinuko - do you
Wouldn't mind a more managed log of API shifts. Any ideas for a very simple
deprecation journal?
I just learned about CanvasPixelArray being turned over today and I follow the
lists.
A simple HTML.deprecated list would have the dual use of notifying followers
about strong progress. It'd
On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com
wrote:
I think we should solve this by assigning an object directly to
attributes
that take a URL.
So instead you would get
imgElement.src = blob
Adrian,
- Original Message -
At TPAC [1,2] I described our proposal for adding an isReusable flag
to
createObjectURL. A common pattern we have seen is the need for a blob
URL
for a single use (for example, loading into an img element) and then
revoking the URL. This requires a fair
- Original Message -
Wouldn't mind a more managed log of API shifts. Any ideas for a very
simple deprecation journal?
I'd be a fan of this. To date, the only thing I've deprecated (and will
eventually remove) is readAsBinaryString.
On topic: anyone using readAsBinaryString ought
- Original Message -
The current spec requires the opaque string in Blob URLs to be at
least
36 characters in length [1]. Our implementation doesn't currently use
a
UUID and the length of the string is shorter than 36 characters. While
I have no problem with the recommendation to use
On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan
aranganat...@mozilla.com wrote:
Adrian: I'm willing to relax this. I suppose it *is* inconsistent to
insist on 36 chars when we don't insist on UUID. But I suspect when it
comes time to making blob: a registered protocol (it was
On Fri, 16 Dec 2011 11:12:21 +0100, Charles Pritchard ch...@jumis.com
wrote:
Wouldn't mind a more managed log of API shifts. Any ideas for a very
simple deprecation journal?
There's
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#historical for
the DOM at the moment.
I just
On 12/15/11 11:51 AM, ext Brian LaMacchia wrote:
Hello all,
Sorry for coming to this thread late (I'm on vacation) but I want to comment on
a number of points raised during this thread:
1) Concerning the suggestion to move ECDSA out of XMLDSIG 1.1, that suggestion
is a non-starter for
On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan
aranganat...@mozilla.com wrote:
Adrian: I'm willing to relax this. I suppose it *is* inconsistent to
insist on 36 chars when we don't insist on UUID. But I
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15234
Summary: Throw if IDBTransaction.objectStore() or
IDBObjectStore.index() called after transaction
finished
Product: WebAppsWG
Version: unspecified
Platform: All
and MUST be at least 36 characters long
I can't think of any reason for that requirement, seems fine to delete it.
Webkit and Chrome do use guids but also embed the origin in these url.
On Fri, Dec 16, 2011 at 5:58 AM, Jarred Nicholls jar...@webkit.org wrote:
On Fri, Dec 16, 2011 at 6:27
On December 15, 2011 10:20 PM, Jonas Sicking wrote:
On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell jsb...@chromium.org
wrote:
Is there any particular reason why IDBTransaction.objectStore() and
IDBObjectStore.index() should be usable (i.e. return values vs. raise
exceptions) after the
Is there something requiring that the origin be part of the URL?
On Dec 16, 2011, at 2:29 PM, Michael Nordman micha...@google.com wrote:
and MUST be at least 36 characters long
I can't think of any reason for that requirement, seems fine to delete it.
Webkit and Chrome do use guids
There is no requirement for that in the spec/draft, it's useful for our
implementation.
On Fri, Dec 16, 2011 at 3:06 PM, Charles Pritchard ch...@jumis.com wrote:
Is there something requiring that the origin be part of the URL?
On Dec 16, 2011, at 2:29 PM, Michael Nordman micha...@google.com
On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio isra...@microsoft.com wrote:
On December 15, 2011 10:20 PM, Jonas Sicking wrote:
On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell jsb...@chromium.org
wrote:
Is there any particular reason why IDBTransaction.objectStore() and
On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman micha...@google.com wrote:
There is no requirement for that in the spec/draft, it's useful for our
implementation.
I suspect this will be true in Firefox too in due time. So I
definitely think that we should allow for this.
/ Jonas
On Fri, Dec 16, 2011 at 3:30 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio isra...@microsoft.com
wrote:
On December 15, 2011 10:20 PM, Jonas Sicking wrote:
On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell jsb...@chromium.org
wrote:
Is there any
Sounds good! I've updated the bug to reflect this decision.
Israel
On Friday, December 16, 2011 3:37 PM, Joshua Bell wrote:
On Fri, Dec 16, 2011 at 3:30 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio
- Original Message -
On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman micha...@google.com
wrote:
There is no requirement for that in the spec/draft, it's useful for
our
implementation.
I suspect this will be true in Firefox too in due time. So I
definitely think that we
I think I have a better solution...
1. Widgets points to unversioned: http://www.w3.org/TR/xmldsig-core/
2. when XML dig sig pag finishes and spec goes to rec, XML Dig Sig 1.X (and
future versions) gets put at http://www.w3.org/TR/xmldsig-core/
3. Done.
That way widgets always just depend on
22 matches
Mail list logo
