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 lat
- Original Message -
> On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman
> 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 f
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
mailto:jo...@sicking.cc>> wrote:
On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio
mailto:isra...@microsoft.com>> wrote:
> On
On Fri, Dec 16, 2011 at 3:30 PM, Jonas Sicking wrote:
> On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio
> wrote:
> > On December 15, 2011 10:20 PM, Jonas Sicking wrote:
> >> On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell
> >> wrote:
> >> > Is there any particular reason why IDBTransaction.object
On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman 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 2:41 PM, Israel Hilerio wrote:
> On December 15, 2011 10:20 PM, Jonas Sicking wrote:
>> On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell
>> wrote:
>> > Is there any particular reason why IDBTransaction.objectStore() and
>> > IDBObjectStore.index() should be usable (i.e. retur
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 wrote:
> Is there something requiring that the origin be part of the URL?
>
>
>
> On Dec 16, 2011, at 2:29 PM, Michael Nordman wrote:
>
> > "and MUST be at
Is there something requiring that the origin be part of the URL?
On Dec 16, 2011, at 2:29 PM, Michael Nordman 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 but also embed
On December 15, 2011 10:20 PM, Jonas Sicking wrote:
> On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell
> wrote:
> > Is there any particular reason why IDBTransaction.objectStore() and
> > IDBObjectStore.index() should be usable (i.e. return values vs. raise
> > exceptions) after the containing transa
> "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 wrote:
> On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kes
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
On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kesteren 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 suspect when
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 XMLDSIG
On Fri, 16 Dec 2011 11:12:21 +0100, Charles Pritchard
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 learned about Can
On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan
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 discussed on
the IETF/URI lists
- 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 t
- 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 oug
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 element) and then
> revoking the URL. This requires a fa
On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking wrote:
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren
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
The problem is that we have tons
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 reliev
On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow wrote:
> 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 have a commitme
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
22 matches
Mail list logo
