Re: Call for Consensus - Selectors API to Candidate Rec

Jonas Sicking: > Still not sure that I understand that chart. As I read it, firefox for > the namespaceURI parameter of DOMImplementation.createDocument treats > undefined as null (hence the 'N' in the second column). However I > would have really expected us to treat undefined as the string > 'un

Re: Call for Consensus - Selectors API to Candidate Rec

On Thu, Feb 12, 2009 at 4:14 PM, Cameron McCormack wrote: > > Boris Zbarsky: >> On John Resig's tests in particular, every single failure in Gecko is >> due to a violation of this part of the API: >> >> Undefined=Empty >> >> This is using a WebIDL syntax from a working draft that we don't >> im

Re: Call for Consensus - Selectors API to Candidate Rec

Cameron McCormack wrote: If that does end up being the more common behaviour, I’ll change the default in Web IDL to be to stringify to "undefined" unless overridden, For what it's worth, that's what the current WebIDL draft says in any case. -Boris

Re: Call for Consensus - Selectors API to Candidate Rec

Jonas Sicking: > An alternative would be to not mention behavior for undefined at all > and let it be whatever the default is for WebIDL once that spec makes > up its mind. It seems more important to me to behave consistently with > other methods than to have any specific behavior for undefined.

Re: Call for Consensus - Selectors API to Candidate Rec

Boris Zbarsky: > On John Resig's tests in particular, every single failure in Gecko is > due to a violation of this part of the API: > > Undefined=Empty > > This is using a WebIDL syntax from a working draft that we don't > implement yet, and the current JavaScript DOM binding in Gecko alway

Re: DOMTimeStamp binding

On Thu, 12 Feb 2009 10:01:44 -0800, Darin Adler wrote: > > Of course, WebKit could change. But I thought the point here was that > the top market share browsers all already agree. I don't see the > upside in changing, given that. Converting the value to a date is > extremely simple. Lets m

Re: [cors] cache-max-age: just 86400s?

On Thu, Feb 12, 2009 at 8:19 AM, Anne van Kesteren wrote: > > The specification does not state it yet, but it has been suggested that the > maximum time any cache entry can persist in the preflight result cache > should be 86400 seconds (i.e. 24 hours). It still seems rather low to me. If > peopl

ISSUE-81: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? [Widgets]

ISSUE-81: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? [Widgets] http://www.w3.org/2008/webapps/track/issues/81 Raised by: Frederick Hirsch On product: Widgets During the 12-Feb-2009 widgets voice conference, Frederick raised this issue: [[

[widgets] Minutes from 12-Feb-2009 Voice Conference

The minutes from the February 12 Widgets voice conference are available at the following and copied below: WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 19 February 2009 (th

Re: Call for Consensus - Selectors API to Candidate Rec

On Thu, Feb 12, 2009 at 8:14 AM, Boris Zbarsky wrote: > > Lachlan Hunt wrote: >> >> Firefox appears to have some issues that might related to the API, though >> I haven't investigated the cause of those yet, so I don't know for sure. > > On John Resig's tests in particular, every single failure i

Re: DOMTimeStamp binding

* Kartikaya Gupta wrote: >DOM 3 Core says this about DOMTimeStamp: > >> For Java, DOMTimeStamp is bound to the long type. For ECMAScript, >> DOMTimeStamp >> is bound to the Date type because the range of the integer type is too small. The former WebAPI working group discussed this issue and foun

Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

timeless wrote: I think the problem here is that there's too much syntactic sugar in sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL, and maybe Hixie or others could help to address it). I can easily replace the object (window.sessionStorage={}) The sessionStorage proper

Re: DOMTimeStamp binding

On Feb 12, 2009, at 9:53 AM, Anne van Kesteren wrote: On Thu, 12 Feb 2009 18:51:02 +0100, Darin Adler wrote: On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote: Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. Chrome uses an entir

Re: DOMTimeStamp binding

On Thu, 12 Feb 2009 18:51:02 +0100, Darin Adler wrote: On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote: Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. Chrome uses an entirely different JavaScript binding, not the standard WebK

Re: DOMTimeStamp binding

On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote: Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. Chrome uses an entirely different JavaScript binding, not the standard WebKit one, so I'm not surprised that it’s exhibiting differ

Selectors API Test Suite Update

Hey Everyone - I've updated the Selectors API test suite that I created to run in IE8. I've uploaded a copy of the suite here: http://ejohn.org/apps/selectortest/ You can get the source here: http://github.com/jeresig/selectortest/tree/master For right now I'm getting the following numbers: -

[cors] cache-max-age: just 86400s?

The specification does not state it yet, but it has been suggested that the maximum time any cache entry can persist in the preflight result cache should be 86400 seconds (i.e. 24 hours). It still seems rather low to me. If people still think we should limit it to this I will make it a re

Re: Call for Consensus - Selectors API to Candidate Rec

Lachlan Hunt wrote: Firefox appears to have some issues that might related to the API, though I haven't investigated the cause of those yet, so I don't know for sure. On John Resig's tests in particular, every single failure in Gecko is due to a violation of this part of the API: Undefin

Re: [whatwg] DOMTimeStamp binding

On Thu, 12 Feb 2009 16:12:49 +0100, Kartikaya Gupta wrote: It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually r

Re: [whatwg] DOMTimeStamp binding

On Thu, 12 Feb 2009 07:03:22 +0100, "Simon Pieters" wrote: > > On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta > wrote: > > > I updated to Safari 3.2 on Windows (which looks it also has WebKit > > 525.27.1) and you're right, it is now showing "number" instead of > > "object". I guess

Re: DOMTimeStamp binding

On Wed, 11 Feb 2009 15:03:01 -0800, Darin Adler wrote: > > On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote: > > > I updated to Safari 3.2 on Windows (which looks it also has WebKit > > 525.27.1) and you're right, it is now showing "number" instead of > > "object". I guess this was chang

Re: ISSUE-80: Runtime localization model for widgets [Widgets]

2009/2/5 Jon Ferraiolo : > I am all in favor of *not* having to replicate many files in the widget > distribution just so you can create localized versions of a single image. > > One more thing I'll add. One of the URL techniques in the Widgets spec, using > "/" as the first character in a relat

Re: [widgets] Comments on the 22-Dec-2008 LCWD of the Widgets 1.0: P&C spec

Hi Art, 2009/2/10 Arthur Barstow : > Marcos, > > On Feb 3, 2009, at 9:15 AM, ext Marcos Caceres wrote: >> >> The spec now reads: >> >> [[ >> "A user agent is a user agent that attempts to implement this specification. >> >> Note: The user agent described in this specification does not denote a >>

Re: [widgets] Comments on the 22-Dec-2008 LCWD of the Widgets 1.0: P&C spec

2009/2/7 Priestley, Mark, VF-Group : >> 3. Signature handling should be specified in [Widgets-DigSig], thus, >> replace all of Step 5 in section 8.2 with the following: >> >> [[ >> The algorithm that describes how to process the list of signatures >> created in step 4 is defined in [Widgets-DigSig

Re: [widgets] Widget modes

2009/1/31 ivan.demarino : > > Hello. > > Here in Orange Labs UK we think that the idea of having multiple modes with multiple HTML five can address another risk: the need of adapting the presentation layer programmatically, can drive to excessive "cpu-bound" calculation (it's Javascript after all).

Re: SVG as Widget Icon

Hi Doug, 2009/1/31 Doug Schepers : > > Hi, Jere- > > Jere Kapyaho wrote (on 1/30/09 3:31 AM): >> >> (And if there is any animation, just use the first rendered frame.) > > Declarative animations should be allowed, assuming the UA supports them. > > FWIW, SVG doesn't use frames, it uses timeline-b

[widgets] Fwd: Widget test reorganisation

Hi, I'm forwarding an email from Kai, who is currently working on the widget test suite, about some recent changes he has made to the widget spec test suite. Kai, for the benefit or those not subscribed to the mwts list, it would be greatly appreciated if you could also CC public-webapps for any

Re: Required support for SVG in widgets

2009/2/6 Robin Berjon : > > Hi Nick, > > On Feb 5, 2009, at 18:04 , Nick Allott wrote: >> >> To clarify: BONDI work would have been introduced to W3C activity earlier in >> the process, however, we have been fighting the internal (and cross >> organisational) processes surrounding IPR regimes. >

Re: http://dev.w3.org/2006/waf/widgets/#the-feature-element

HI Kai 2009/2/7 Kai Hendry : > > Currently a widget developer declaring the dependency on a feature > might simply write: > > http://bondi.omtp.org/api.geolocation";> > > Since the required attribute will be unset and as a > http://dev.w3.org/2006/waf/widgets/#boolean-attribute it will default >

Re: [widgets] A proposal on widget modes

Hi Mark, Arve, I've renamed currentMode to viewMode in the API spec. viewMode represents the current view mode of the widget. I would like to hear more use cases for the element before adding it to the spec. Kind regards, Marcos 2009/1/22 Arve Bersvendsen : > > On Thu, 22 Jan 2009 14:25:02

Re: [widgets] Action 293: Add the tag: scheme to the scheme pros and cons document

2009/2/12 Arthur Barstow : > Hi Marcos, > > To facilitate addressing Action 293 ("Add the tag: scheme to the scheme pros > and cons document"), and to provide an easy way for other members of the > group to contribute to the widget scheme pros and cons discussion, I copied > your slide set to o

Re: Call for Consensus - Selectors API to Candidate Rec

Charles McCathieNevile wrote: In addition, since this specification has a number of implementations we may try to have a zero-length CR period (by approving tests and showing that we have interoperability already) - any comments on that approach are welcome. Based on John Resig's tests [1],

widgets 1.0 requirements suggestion

I have an additional suggested revision to the Widgets 1.0 Requirements, dated 28 January [1]: (1) R44. Signature Document Format http://dev.w3.org/2006/waf/widgets-reqs/#r44.-signature-document-format I suggest some changes to clarify to capture the intent that Mark noted [2]. (1a) Repl

RE: Comments on Widgets 1.0 Security requirements

Sorry for the (very) delayed response: Art wrote: >Based on the following "clarifications" and Mark's reply above: > >[[ >0036.html> > >1. It MUST be possible to extract a _copy_ of the digital signature >document(s) from the widge

RE: [widgets] Getting synch'ed up on Widgets Digital Signatures

Hi Art, Some specific responses to your points: >* Is supporting multiple signatures per package a MUST for v1? [mp] Vodafone would say yes. IMHO I don't think it's that hard to specify - depending a bit on how we address other issues. >* Is supporting OCSP and CRL a MUST for v1? [mp] Vodaf

RE: [widgets] Getting synch'ed up on Widgets Digital Signatures

Thomas Roessler wrote: >> Just for clarity, there are two possible requirements around OCSP and >> CRLs: >> >> - support embedding an OCSP response (or a CRL, or a link to a CRL) >> in the mark-up of signatures >> - support querying OCSP responders (and CRLs) as part of >certificate >> vali

Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

I think the problem here is that there's too much syntactic sugar in sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL, and maybe Hixie or others could help to address it). I can easily replace the object (window.sessionStorage={}), but I can't be told when my sessionStorage i

RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property

A very brief response below, marked [mp] Thanks, Mark >-Original Message- >From: public-webapps-requ...@w3.org >[mailto:public-webapps-requ...@w3.org] On Behalf Of Hillebrand, Rainer >Sent: 11 February 2009 08:03 >To: Marcos Caceres >Cc: public-webapps@w3.org >Subject: RE: [widgets] C

Re: [widgets] Agenda for 12 February 2009 Voice Conference: NOTE NEW TIME!

Hi Art, regrets from me -- there is a conflict for me at the chosen time slot. (Apologies for not having sent these earlier, but I only noticed the new times lot now.) Regards, -- Thomas Roessler, W3C On 11 Feb 2009, at 14:10, Arthur Barstow wrote: Below is the draft agenda for

Re: [XHR2] Progress events during synchronous requests

I am sure a developer would like to make use of a consistent API. This would simplify application logic modification: using XHR1 a code would need to be written differently when executing synch/asynch calls. Also, dispatching only "checkpoints" events would probably be sufficient for that matt

Re: [XHR2] Progress events during synchronous requests

On Thu, Feb 12, 2009 at 1:19 AM, Anne van Kesteren wrote: > On Wed, 11 Feb 2009 22:44:17 +0100, Jonas Sicking wrote: >> >> Is there a reason why the spec says to not send progress events >> (upload and download) during synchronous requests, while still saying >> that readystatechange events shou

Re: [XHR2] Progress events during synchronous requests

On Wed, 11 Feb 2009 22:44:17 +0100, Jonas Sicking wrote: Is there a reason why the spec says to not send progress events (upload and download) during synchronous requests, while still saying that readystatechange events should be fired? I guess it can be argued that progress events (especially

RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

Hi Frederick, Some comments inline below. Thanks, Mark >-Original Message- >From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] >Sent: 11 February 2009 23:21 >To: Priestley, Mark, VF-Group >Cc: Frederick Hirsch; Marcos Caceres; Barstow Art >(Nokia-CIC/Boston); public-webapps