On 5/20/11 10:03 AM, Scott Wilson wrote:
This test case states:
"Tests that update-info element's version attribute should have a value
higher than current version for the widget to be updated. The widget is
not updated or replaced."
However, in the specification itself, there is no condition t
For the optional parameters variable that is expected by the
IDBDatabase.createObjectStore function, would it be possible to constrain the
variable to have the keyPath and autoIncrement attributes as part of its
instance members and not as part of its inheritance hierarchy?
Israel
It looks like Gecko, Presto, and Webkit all support on* event attributes
on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would propose that these be supported on all Elements at least for
events that are not element-specific (e.g. "click").
-Boris
On Fri, May 27, 2011 at 10:27 AM, Israel Hilerio wrote:
> For the optional parameters variable that is expected by the
> IDBDatabase.createObjectStore function, would it be possible to constrain
> the variable to have the keyPath and autoIncrement attributes as part of its
> instance members and n
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12433
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Israel Hilerio:
> > For the optional parameters variable that is expected by the
> > IDBDatabase.createObjectStore function, would it be possible to constrain
> > the variable to have the keyPath and autoIncrement attributes as part of its
> > instance members and not as part of its inheritance hie
I'm pleased to see the changes in the WebSockets API for binary message support.
I'm a little confused by this text:
When a WebSocket object is created, its binaryType IDL attribute must
be set to the Blob interface object associated with the same global
object as the WebSocket constru
On Fri, 27 May 2011, Adrian Bateman wrote:
>
> I'm pleased to see the changes in the WebSockets API for binary message
> support. I'm a little confused by this text:
>
> When a WebSocket object is created, its binaryType IDL attribute must
> be set to the Blob interface object associated
Ian Hickson:
> Consistency is good when it makes sense. However, I don't think XHR is a
> good parallel here. XHR has all kinds of additional complexities, for
> example it lets you get a string, whereas here string vs binary is handled
> at the protocol level and so can't ever be confused.
>
>
On Fri, May 27, 2011 at 4:02 PM, Ian Hickson wrote:
> On Fri, 27 May 2011, Adrian Bateman wrote:
>>
>> I'm pleased to see the changes in the WebSockets API for binary message
>> support. I'm a little confused by this text:
>>
>> When a WebSocket object is created, its binaryType IDL attribute
On Sat, 28 May 2011, Cameron McCormack wrote:
> Ian Hickson:
> > Consistency is good when it makes sense. However, I don't think XHR is a
> > good parallel here. XHR has all kinds of additional complexities, for
> > example it lets you get a string, whereas here string vs binary is handled
> > a
On Fri, 27 May 2011, Jonas Sicking wrote:
>
> I agree that the WebSocket solution looks cleaner in the simple cases.
> However it introduces complexity for the case when the script is dealing
> with multiple globals. For example, what is an implementation supposed
> to do if a page does:
>
> w
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote:
> However, I think there might be another solution to this whole
> situation. There really is no reason that only binary data can be
> received as a Blob. Getting data as a Blob is useful any time you're
> dealing with a large chunk of data wher
On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
> On Fri, 27 May 2011, Jonas Sicking wrote:
> > For example, what is an implementation supposed
> > to do if a page does:
> >
> > ws.binaryType = otherwindow.ArrayBuffer
> >
> > or
> >
> > otherwindow.useThis(ws);
> > with other window containing
As I proposed in March [1], we think it makes sense to separate the WebSocket
constructor from the operation to initiate the network operation. We proposed a
separate open() method similar to XHR. This allows a WebSocket object to be
constructed and initialised prior to communication. We think t
On Fri, May 27, 2011 at 4:29 PM, Ian Hickson wrote:
> On Fri, 27 May 2011, Jonas Sicking wrote:
>>
>> I agree that the WebSocket solution looks cleaner in the simple cases.
>> However it introduces complexity for the case when the script is dealing
>> with multiple globals. For example, what is an
On Fri, May 27, 2011 at 5:47 PM, Adrian Bateman wrote:
> As I proposed in March [1], we think it makes sense to separate the WebSocket
> constructor from the operation to initiate the network operation. We proposed
> a separate open() method similar to XHR. This allows a WebSocket object to be
18 matches
Mail list logo
