For debugging performance in Chrome we wrote a high-res stopwatch API.
Specifically, we needed to measure sub-millisecond times. Currently there
is no mechanism for a javascript application to access fine-grained timers.
Is there any interest in standardizing something like this?
Here is the basi
Charles McCathieNevile wrote:
On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan
wrote:
Garrett Smith wrote:
It might be worth discussing the load event;
http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load
Seems that it is "specified" to fire on Document or Element (instead
of window
On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan
wrote:
Garrett Smith wrote:
It might be worth discussing the load event;
http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load
Seems that it is "specified" to fire on Document or Element (instead
of window).
I would also suggest a pr
ok thanks, good to be clear. I'll go ahead and make the change.
regards, Frederick
Frederick Hirsch
Nokia
On Feb 25, 2009, at 5:59 PM, ext Thomas Roessler wrote:
I was not suggesting that we should mandate X509Data (or anything like
it).
The point I was getting at was, that along with our
I was not suggesting that we should mandate X509Data (or anything like
it).
The point I was getting at was, that along with our using of X509
certificates, people really ought to use basic path validation as
specified in 5280 -- no matter where the certificate comes from. I
think your ch
Thanks for the proposal Thomas.
This proposal requiring Basic Path Validation seems to conflict with
X509Data being optional, the current language that I think we
discussed during the meeting:
Generation:
5c) The ds:KeyInfo element MAY be included and MAY include
certificate, CRL and/or O
Garrett Smith wrote:
It might be worth discussing the load event;
http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load
Seems that it is "specified" to fire on Document or Element (instead
of window).
I would also suggest a progress event on document or window.
Ideally it would be t
On Wed, Feb 25, 2009 at 10:16 AM, Olli Pettay wrote:
> On 2/25/09 7:46 PM, Garrett Smith wrote:
>>
>> On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
>> wrote:
>>>
>>> Hi folks,
>>>
>>> unfortunately I have not been able to catch up with Doug (a combination
>>> of
>>> both of us travelli
There were three of us including me, and so the minutes are short.
Mutation events are proposed for next week, and Doug will propose wording
to resolve ISSUE-44 by having languages determine where the load event
fires.
Fuller details in the attached minutes.
cheers
--
Charles McCathieNevi
On 2/25/09 7:46 PM, Garrett Smith wrote:
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
wrote:
Hi folks,
unfortunately I have not been able to catch up with Doug (a combination of
both of us travelling and then I had a minor accident that put me out of
commission for a while), so as
On Wed, 25 Feb 2009 18:46:22 +0100, Garrett Smith
wrote:
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
wrote:
The call is booked:
Telephone: +1.617.761.6200 meeting code 3663 (DOM3).
Pacific time: 11.30am - 1pm
Boston time: 2.30pm - 4pm
UTC: 1930Z - 2100Z
CET: 2030 - 2200
It
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
wrote:
> Hi folks,
>
> unfortunately I have not been able to catch up with Doug (a combination of
> both of us travelling and then I had a minor accident that put me out of
> commission for a while), so as far as I know we have no agenda plan
In short, I agree with all actions below.
I do have some implementation feedback regarding redirects, but I'll
start a separate thread on that.
/ Jonas
On Wed, Feb 25, 2009 at 12:57 AM, Anne van Kesteren wrote:
> Here is an update on my last status messsage.
>
> On Mon, 09 Feb 2009 21:43:54 +09
Hi folks,
unfortunately I have not been able to catch up with Doug (a combination of
both of us travelling and then I had a minor accident that put me out of
commission for a while), so as far as I know we have no agenda planned for
tonight's call.
The call is booked:
Telephone: +1.617.76
Regarding the http redirect security violation steps, the spec (
http://dev.w3.org/2006/webapi/XMLHttpRequest/) says "If async is set to
false raise a NETWORK_ERR exception and terminate the overall algorithm."
I tried out IE7, Firefox 3, and WebKit nightlies and none of them seem to
throw an excep
Hi,
I have a question about the overloaded operations in an effective
overload set in Web IDL. In the example of 'Interface A' in 3.3.3.
Operation, the Draft 19 December 2008 says,
"There are thus no overloaded operation resolution ambiguities for
the interface",
but the following three pai
Just to round out the thread :), I fixed my test for IE and found that IE7
also throws an exception in this case.
On Tue, Feb 24, 2009 at 2:23 PM, David Levin wrote:
> I just got a Firefox nightly and found that it does throw in this case, so
> the behavior changed from FF 3.
> Also, I noticed
Hi Laurens,
As we no longer require user agents that conform the the packaging
spec to support any media types, I have added xhtml as a default start
file (extensions are .xhtml and .xht). This will be in the spec when I
next check the spec in.
Kind regards,
Marcos
2008/12/10 Laurens Holst :
> Ma
I propose that we add te following text in the beginning of 6.2:
The validation procedure given in this section describes extensions
to XML Signature Core Validation. In addition to the steps defined
in these two specifications, user agents MUST perform Basic Path
Validation [RFC 5280] on
On 25 Feb 2009, at 13:50, Frederick Hirsch wrote:
- 5.2 and 5.3 have an issue about additional algorithms. I suggest
just being silent about them.
ok to remove the issues?
To the extent to which these are about unspecified additional
algorithms, that's what I'm proposing. The second has
Thomas
Thanks for the careful review.
comments inline
regards, Frederick
Frederick Hirsch
Nokia
On Feb 25, 2009, at 7:06 AM, ext Thomas Roessler wrote:
In reviewing the latest draft, a couple of comments.
Widgets 1.0: Digital Signatures
Editor's Draft 23 February 2009
http://dev.w3
In reviewing the latest draft, a couple of comments.
Widgets 1.0: Digital Signatures
Editor's Draft 23 February 2009
http://dev.w3.org/2006/waf/widgets-digsig/
(Mostly) editorial:
- I would propose including a table of namespace prefixes and
namespace URIs, and just saying that the pref
On Mon, 09 Feb 2009 21:57:47 +0900, Anne van Kesteren
wrote:
After renaming the specification I decided to go through the normative
parts of the specification again to clean various things up and resolve
some outstanding issues. Since the October 6 editor's draft (last
relatively stable dr
On Tue, 21 Oct 2008 01:05:38 +0900, Nikunj Mehta
wrote:
The currently written text appears normative, but that is misleading
since such sections are usually informative. Pre-flight request results
are also stored to disk and so, it is a good idea to either add
something to the Security Con
Here is an update on my last status messsage.
On Mon, 09 Feb 2009 21:43:54 +0900, Anne van Kesteren
wrote:
[...]
I would very much appreciate it if people involved in CORS (and other
interested parties of course) can read through this e-mail and share
their thoughts. The sooner the bette
On Wed, 11 Feb 2009 13:42:02 +0900, Sean Hogan
wrote:
Ok, I can see that the use case is consistent with what is in the XBL
spec. I prefer the following wording:
A XBL binding allows the document to which it is bound to have full
access to the document in which it is defined; therefore cro
On Fri, 13 Feb 2009 04:57:19 +0900, Jonas Sicking wrote:
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
27 matches
Mail list logo
