Re: [cors] cache-max-age: just 86400s?
On Fri, 13 Feb 2009 04:57:19 +0900, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 12, 2009 at 8:19 AM, Anne van Kesteren ann...@opera.com 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 people still think we should limit it to this I will make it a recommendation in the specification (i.e. a should-level requirement). I seem to recall that we discussed using a solution like this: * Not mention particular limit in the definition for the Access-Control-Max-Age * Have a general rule that said that implementations are allowed to discard entries from the cache at any point for security reasons. (this would also allow emptying the cache when the user switches network from a potentially MITMed cafe to a corporate network) * Mention in the security considerations section that implementations should consider having a limit. I'm a little hazy especially on the last point. Don't remember if we agreed on recommending a particular limit or not. In the firefox implementation i've used 86400 seconds but would be fine with changing that. I changed the specification to allow a limit, but no limit is suggested or required. Implementations are encouraged to set a limit though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [cors] Status
Here is an update on my last status messsage. On Mon, 09 Feb 2009 21:43:54 +0900, Anne van Kesteren ann...@opera.com 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 better. Since this did not happen I tried doing the remaining work myself. http://www.w3.org/2008/webapps/track/products/7 ISSUE-13 Opting into cookies it seems this is part of the specification now in the form of the Access-Control-Allow-Credentials header and credentials flag. I will close this issue unless someone speaks up by next Friday. ISSUE-25 Revocation of cached access grants as I stated in July 2008 (e-mail is referenced from the issue) you can revoke cache entries by simply not allowing the actual request to pass. (Part of this issue became ISSUE-30.) I will close this issue unless someone speaks up by Friday. ISSUE-30 Should spec have wording to recognise that User Agents may implement further security beyond the spec? http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html has suggested additional restrictions user agents may impose. I'm thinking that should be a normative subsection of the processing model. Makes sense? This is now addressed in the specification. I will therefore close this issue unless someone speaks up by Friday. ACTION-11 Draft scenarios for AC + various host specs the use cases section in the specification has some scenarios. Given @font-face and media elements I could add some more there I suppose if that is desired. I will close this action unless someone speaks up by Friday. ACTION-148 Try to find an Editor for the Access Control Primer document I do not think this is worth the time of the WG to be honest. Tutorials for using CORS are already appearing on the Web. E.g. https://developer.mozilla.org/En/HTTP_access_control Having one that is vetted by the WG seems like something that demands more resources than we have. Since this action does cannot possibly stop progress on CORS I will leave this up to Art. (If someone is of the opinion that it can stop process on CORS please speak up by Friday.) ACTION-192 Submit an input that will result in closing Issue #21 that is a Widgets issue. This has been closed already. The Origin header needs to become something that can be referenced. Should I keep the definition in the draft meanwhile? Currently it is commented out. This is an open issue in the draft with text commented out. If we go to Last Call and there is no reasonable progress on the RFC ID I will put the text back in. After all, we already provisionally registered the header through this WG. The security section currently mostly makes redundant requirements (incorrect, it should be non-normative) and requirements that are better moved to the processing model. I thought of maybe introducing a processing model for servers so that the requirements on them become a bit more clear. And the the user agent and server processing model share the syntax section for header definitions on writing and parsing. Does that make sense? I have done this now. Not sure what happens to the security section after that. Ideas? There were a few considerations that did not fit anywhere else. The terms case-sensitive, ASCII case-insensitive, and converting a string to lowercase would ideally be defined in a separate document all kinds of specifications can reference. Although it should be pretty clear from the definitions already, that would strengthen they are indeed identical and can be implemented with the same function. This is just a minor thing though and does not really affect CORS in any way. I proposed drafting a Web Terminology Fundamentals specification for this work on the private list. If there is agreement on that I will start working on it. As mentioned, where these terms are defined should not impact CORS in any way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [cors] Updates
On Mon, 09 Feb 2009 21:57:47 +0900, Anne van Kesteren ann...@opera.com 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 draft) the following things have changed starting January 14: [...] The following changes have been made since February 9: * Improved the non-normative Use Cases appendix. * Introduced a processing model for servers. * Added a section that advices how to write hosting specifications. (Basically which things you need to take into consideration.) * Renamed various internal variable names to be more clear. * Inlined security requirements where possible. * Gave user agents more freedom to not do certain things (e.g. making a request), impose limits on max-age, etc. * Fixed the section on conformance to make sense after all the changes. The following is still true. The only real outstanding issues at the moment are which documents need to be referenced for various terms and the Origin header. And those are not really issues to begin with :-) So please review! I would appreciate feedback from implementors on the changes and in particular on the wording in the latest draft: http://dev.w3.org/2006/waf/access-control/ -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Review of latest Widget Signature Draft
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.org/2006/waf/widgets-digsig/ (Mostly) editorial: - I would propose including a table of namespace prefixes and namespace URIs, and just saying that the prefixes are editorial conventions. The current text in 1.1 and 1.2 is a bit hard to refer to, and the text in 1.2 sounds like it comes from a time when namespaces were new. (It is, since it's lifted straight from XML Signature 1.0. ;-) I thought we needed a namespace section so added one. It can use some refinement. I considered adding a list of namespace URIs used, can do that. - 4.2 claims that the author signature serves to determine whether or not two widgets came from the same author. Actually, author signatures from the same identity can only confirm that they come from the same author; signatures from different identities could still be from the same author. Strike or not. ok - 4.3 mentions that distributor signatures may have implications in security policies. The same isn't said for author signatures. I propose either saying this generically, or striking it from 4.3. I suggest generically in 4.1 - 4.3 says no distributor signatures are to be included. I know what that's supposed to mean, but think this might cause confusion. I suggest to say something along the following lines: The ds:Signature MUST include ds:References for all resources of the widget including any author signatures, but excluding any distributor signatures. In other words, distributor signatures MUST countersign author signatures, but MUST NOT countersign other distributor signatures. good, thanks - 5.1 says as required by [XMLDSIG11] -- I propose striking that, since this specification is making its own, possibly diverging choice of mandatory to implement algorithms. this is an open issue regarding alignment Not so editorial: - In the example in 1.4, the signature doesn't cover the signature properties. oops, thanks - 5.2 and 5.3 have an issue about additional algorithms. I suggest just being silent about them. ok to remove the issues? - The processing model in 6.2 sounds as if it requires implementations to do a deep-dive into other signature files in order to determine whether an author signature, if present, is covered by a distributor signature. That sounds error-prone. I wonder if there should be a simple file name convention to distinguish author and distributor signatures, to make signature validation independent of parsing more than one signature resource. we have a naming convention listed with the property sections. Should mention that here. - The processing model in 6.2 does not currently enforce the MUST NOT on distributor signatures countersigning each other. I'm having a hunch that that might get abused by malevolent distributors in order to interfere with each other; I therefore suggest that distributorr signatures that countersign each other are a reason for validation failure. sounds reasonable - In 6.1, I wonder whether it's worthwhile to rebuild the signature properties piece a bit -- the current description is mildly convoluted (by describing a tree from the leaves, not the root). i think it is complicated , I'll think about better text, suggestions welcome. - We're not currently saying how same-document references are done. The example suggests ID-based references. That should be said explicitly -- or else people might start using complex xpointers. It might also be useful to recommend the use of random strings for the IDs. Corresponding to that, the validation model does not enforce the position of the signature properties within the overall XML document. That might lead to interesting differences in implementations that could cause different implementations to see different things. agree, text on references would be useful. - In 4.4, we currently perform a dance around X.509 version numbers. Thinking this through more thoroughly, it worries me that this came up, for the following reason: You need an X.509 v3 extension to express the basic constraints on a certificate. Without the basic constraints extension, it is impossible to distinguish a CA certificate from an end entity certificate. Which in turn suggests that somebody might have inadvertently generated a CA certificate instead of an end entity certificate... In other words, we shouldn't ever see an end entity certificate that is X.509 v1 or v2. (And if we see one, it's a good idea to break it.) so you suggest simplifying this to v3? - The current draft has a relatively complex set of interacting signatures, but does not timestamp these at all. I'd *really* like us to mandate a timestamp property on each of
Re: Review of latest Widget Signature Draft
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 hash algorithm question is separate, I think. - In 4.4, we currently perform a dance around X.509 version numbers. Thinking this through more thoroughly, it worries me that this came up, for the following reason: You need an X.509 v3 extension to express the basic constraints on a certificate. Without the basic constraints extension, it is impossible to distinguish a CA certificate from an end entity certificate. Which in turn suggests that somebody might have inadvertently generated a CA certificate instead of an end entity certificate... In other words, we shouldn't ever see an end entity certificate that is X.509 v1 or v2. (And if we see one, it's a good idea to break it.) so you suggest simplifying this to v3? I suggest mandating v3 certificates, yes.
Re: [widgets] Content-type sniffing and file extension to MIME mapping
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 lho...@students.cs.uu.nl: Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of ‘widget engine’, but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don’t suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn’t implement this specification anyway (neither do the other browsers, for that matter). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. Also, actually HTML5 does support exactly this (even though Hixie doesn’t like it, last I heard). Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification’s subtitle is “A vocabulary and associated APIs for HTML and XHTML”. You are aware of this, right? I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the ‘HTML good, XML bad’ mantra that seems to be popular among certain groups lately, and not hide behind statements like ‘if implementors request it’. I don’t understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. ~Laurens [1] http://dev.w3.org/html5/spec/Overview.html#relationship-to-html-4.01-and-dom2-html [2] http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com -- Marcos Caceres http://datadriven.com.au
[xhr2] Redirect during send question
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 exception in this case. Won't implementing the spec introduce a significant incompatibility? Or did I miss something? Thanks, Dave PS I'm asking because I doing a change in WebKit in this area.
[WebIDL] On overloaded operations in an effective overload set
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 pairs seem to be not distinguishable to me,
* f2, (DOMString, DOMString) and f3, (long, DOMString)
* f2, (DOMString, DOMString, float) and f3, (long, DOMString, DOMString)
* f2, (DOMString, DOMString, float, float) and f3, (long,
DOMString, DOMString, float)
based on the definition of 'distinguishable':
Two types, t and u, are distinguishable if both are objects
implementing an interface (where two different interfaces are
identified) or if one is an object implementing an interface and the
other is a primitive type.
Since 'DOMString', 'long', and 'float' are primitive types, there is
no index i such that the types at index i are distinguishable in the
above pairs.
We are currently developing a Web IDL based RPC system for Native
Client (*) to facilitate defining interfaces between JavaScript and
Native Client based safe x86 modules, and a little clarification about
this section will help us with our Web IDL compiler development.
(*) http://code.google.com/p/nativeclient/
Also I found two typos in the draft:
3.8.13. [Variadic]
interface IntegerSet {
readonly unsigned long cardinality; # 'attribute' is missing after 'readonly'
void union([Variadic] in long ints);
void intersection([Variadic] in long ints);
};
4.2.5. [Replaceable]
interface Counter {
[Replaceable] readonly attribute unsigned value; # 'long' or 'short'
is missing after 'unsigned'
void increment();
};
Best,
--
Shiki Okasaka
Google
DOM3 Events call today/tonight?
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.761.6200 meeting code 3663 (DOM3). Pacific time: 11.30am - 1pm Boston time: 2.30pm - 4pm UTC: 1930Z - 2100Z CET: 2030 - 2200 If anyone would like to hold a call, please reply to this thread - if there are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm Boston), we will postpone the restart until next week, and Doug and I will coordinate to ensure there is an agenda. sorry about this cheers Chaals On Tue, 17 Feb 2009 01:13:24 +0100, Charles McCathieNevile cha...@opera.com wrote: On Mon, 02 Feb 2009 16:39:18 +0100, Charles McCathieNevile cha...@opera.com wrote: It would be nice to get DOM 3 Events rolling again. Doug is away for three weeks, but we would like to start calls again in the last week of February. Does Wednesdays at 1930Z (11.30am US West coast, 2.30pm Boston, 2030 Eurotime) suit people? Given that a few people are up for this and that I think it is important to get it moving, there will be a DOM3 Events call on Wednesday 25 Feb at 1930Z (11.30 am West Coast US, 2.30pm East Coast US, 2030 Central European Time, 0630 Feb 27 Australian Eastern Summer Time). The call will be booked for 90 minutes maximum, although I would prefer to limit calls to 60 minutes if possible. Logistical details and agenda will follow... -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [cors] Status
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 ann...@opera.com wrote: Here is an update on my last status messsage. On Mon, 09 Feb 2009 21:43:54 +0900, Anne van Kesteren ann...@opera.com 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 better. Since this did not happen I tried doing the remaining work myself. http://www.w3.org/2008/webapps/track/products/7 ISSUE-13 Opting into cookies it seems this is part of the specification now in the form of the Access-Control-Allow-Credentials header and credentials flag. I will close this issue unless someone speaks up by next Friday. ISSUE-25 Revocation of cached access grants as I stated in July 2008 (e-mail is referenced from the issue) you can revoke cache entries by simply not allowing the actual request to pass. (Part of this issue became ISSUE-30.) I will close this issue unless someone speaks up by Friday. ISSUE-30 Should spec have wording to recognise that User Agents may implement further security beyond the spec? http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html has suggested additional restrictions user agents may impose. I'm thinking that should be a normative subsection of the processing model. Makes sense? This is now addressed in the specification. I will therefore close this issue unless someone speaks up by Friday. ACTION-11 Draft scenarios for AC + various host specs the use cases section in the specification has some scenarios. Given @font-face and media elements I could add some more there I suppose if that is desired. I will close this action unless someone speaks up by Friday. ACTION-148 Try to find an Editor for the Access Control Primer document I do not think this is worth the time of the WG to be honest. Tutorials for using CORS are already appearing on the Web. E.g. https://developer.mozilla.org/En/HTTP_access_control Having one that is vetted by the WG seems like something that demands more resources than we have. Since this action does cannot possibly stop progress on CORS I will leave this up to Art. (If someone is of the opinion that it can stop process on CORS please speak up by Friday.) ACTION-192 Submit an input that will result in closing Issue #21 that is a Widgets issue. This has been closed already. The Origin header needs to become something that can be referenced. Should I keep the definition in the draft meanwhile? Currently it is commented out. This is an open issue in the draft with text commented out. If we go to Last Call and there is no reasonable progress on the RFC ID I will put the text back in. After all, we already provisionally registered the header through this WG. The security section currently mostly makes redundant requirements (incorrect, it should be non-normative) and requirements that are better moved to the processing model. I thought of maybe introducing a processing model for servers so that the requirements on them become a bit more clear. And the the user agent and server processing model share the syntax section for header definitions on writing and parsing. Does that make sense? I have done this now. Not sure what happens to the security section after that. Ideas? There were a few considerations that did not fit anywhere else. The terms case-sensitive, ASCII case-insensitive, and converting a string to lowercase would ideally be defined in a separate document all kinds of specifications can reference. Although it should be pretty clear from the definitions already, that would strengthen they are indeed identical and can be implemented with the same function. This is just a minor thing though and does not really affect CORS in any way. I proposed drafting a Web Terminology Fundamentals specification for this work on the private list. If there is agreement on that I will start working on it. As mentioned, where these terms are defined should not impact CORS in any way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: DOM3 Events call today/tonight?
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile cha...@opera.com 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 planned for tonight's call. 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 If anyone would like to hold a call, please reply to this thread - if there are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm Boston), we will postpone the restart until next week, and Doug and I will coordinate to ensure there is an agenda. 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). sorry about this Garrett
Re: DOM3 Events call today/tonight?
On 2/25/09 7:46 PM, Garrett Smith wrote: On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile cha...@opera.com 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 planned for tonight's call. 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 If anyone would like to hold a call, please reply to this thread - if there are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm Boston), we will postpone the restart until next week, and Doug and I will coordinate to ensure there is an agenda. 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). HTML 5 says that If the Document is in a browsing context, then queue a task to fire a load event at the Document's Window object. And that is what at least Gecko does. 'load' is a special event in many ways. 'load' events dispatched somewhere in document (for example for img) don't propagate to 'window'. And the 'load' event which is dispatched to 'window', has 'document' as its target. This all is required for backwards compatibility. This is related to http://www.w3.org/2008/webapps/track/issues/44 -Olli sorry about this Garrett
Re: DOM3 Events call today/tonight?
On Wed, Feb 25, 2009 at 10:16 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 2/25/09 7:46 PM, Garrett Smith wrote:
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
cha...@opera.com 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 planned
for
tonight's call.
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
If anyone would like to hold a call, please reply to this thread - if
there
are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm
Boston), we will postpone the restart until next week, and Doug and I
will
coordinate to ensure there is an agenda.
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).
HTML 5 says that If the Document is in a browsing context, then queue a
task to fire a load event at the Document's Window object.
And that is what at least Gecko does.
'load' is a special event in many ways. 'load' events dispatched somewhere
in document (for example for img) don't propagate to 'window'. And the
'load' event which is dispatched to 'window', has 'document' as its target.
This all is required for backwards compatibility.
I see.
window does implement EventTarget
. It has addEventListener, removeEventListener, and dispatchEvent. The
callback gets the |event| parameter.
In Webkit/Gecko, the |event.target| is document.
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html lang=en
head
titleload/title
script type=text/javascript
window.addEventListener('load', function(ev) {
var m = document.getElementById('m');
m.firstChild.data = this: + this +
\nev.target: + ev.target +
\nev.currentTarget: + ev.currentTarget;
}, false);
/script
/head
body
pre id=mLoading.../pre
/body
/html
Results:
Opera
this: [object Window]
ev.target: [object Window]
ev.currentTarget: [object Window]
Firefox:
this: [object Window]
ev.target: [object HTMLDocument]
ev.currentTarget: [object Window]
Webkit:
this: [object DOMWindow]
ev.target: [object HTMLDocument]
ev.currentTarget: null
This is related to http://www.w3.org/2008/webapps/track/issues/44
I see Jonas' comment along the lines of when we tried to implement it
this way, it broke sites; Arguably, sites that expected event.target
to be document were already broken. Those sites were expecting
nonstandard behavior which does not work in Opera.
The other consideration is that adding a load event to document. Just
use the example above and change window.addEventListener to
document.addEventListener. The result is:
Webkit, Gecko: Loading...
Opera:
this: [object HTMLDocument]
ev.target: [object HTMLDocument]
Opera also (oddly) supports load event on document.body as an
intrinsic event. The target is also window.
!DOCTYPE HTML
html lang=en
head
titlebody onload/title
/head
body
pre id=mLoading.../pre
script type=text/javascript
document.body.onload = function(ev) {
var m = document.getElementById('m');
m.firstChild.data = this: + this +
\nev.target: + ev.target;
};
/script
/body
/html
Opera:
this: [object Window]
ev.target: [object Window]
Opera also supports intrinsic load event on document. Change the
example above to |document.onload = function(ev) |.
Result in Opera:
this: [object HTMLDocument]
ev.target: [object HTMLDocument]
Interesting stuff. I wonder why Opera implemented that.
As an author, I would favor window.addEventListener. In the callback
would not expect anything of ev.target, but could expect |this ===
window|.
Garrett
[1]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces
Re: ACTION-306: Trust anchors
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 OCSP information. If so, it MUST be compliant with the[XMLDSIG11] specification. If certificates are used they MUST conform to the mandatory certificate format. Validation: If a ds:KeyInfo element is present then it MUST conform to the [XMLDSIG11]specification. If present then any certificate chain SHOULD be validated and any CRL or OCSP information may be used as appropriate [RFC5280].. I suggest we could also adopt your text by changing the final sentence above to If present then user agents MUST perform Basic Path Validation [RFC 5280] on the signing key and SHOULD perform revocation checking as appropriate. The set of acceptable trust anchors, and policy decisions based on the signer's identity are established through a security-critical out-of-band mechanism. Question: Should re require use of X509Data to convey certificates? I was suggesting not, since this could be conveyed out of band and it might not always be appropriate to include in every signature. Thoughts on this one? regards, Frederick Frederick Hirsch Nokia On Feb 25, 2009, at 9:23 AM, ext Thomas Roessler wrote: 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 the signing key. The set of acceptable trust anchors, and policy decisions based on the signer's identity are established through a security-cirtical out-of-band mechanism. (If somebody can think of something nicer to say, that's fine as well. Note that the Basic Path Validation requirement isn't really new -- it's implicit to our use of X.509, if done properly. Nevertheless, worth calling out properly.) -- Thomas Roessler, W3C t...@w3.org
Re: DOM3 Events call today/tonight?
Charles McCathieNevile wrote: On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan shogu...@westnet.com.au 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 progress event on document or window. Ideally it would be triggered every 100ms during page-load. I would suggest that the editor of the progress spec get back to dealing with the last issues raised by Ian, but he is writing this email :) Sorry, I don't understand. Is the progress spec anticipated to augment DOM-3-Events for HTMLDocument and Window? However the issue of timing is an interesting one. I am not sure how handy it is to expect a particular frequency, since it will vary pretty wildly depending on networks as well as other stuff. As a data point, I am told that while Australian broadband connections manage to deliver on average almost 2/3 of their advertised speed, which is a relatively good correspondence although advertised speeds for things people pay for are often are often pretty low, in terms of connections to actual offshore services they are getting something like 1/8. So you would get small progress over a long time. The basis for the 100ms event interval is related to the rendering of new content on the web-page. If new content has arrived then scripts should be able to munge it before it is rendered, or at least soon afterwards. It doesn't matter how much content has arrived. When you emit an event it is pretty low cost. But when you deal with a javascript that listens for that event and then does something else, it is more expensive - and when that starts to eat the battery of your mobile phone, maybe 10 times a second is more than people want. Anyway, I leave the issue of whether to request user agents to make a particular timing available to the specs that use progress events, although I have reservations about the wisdom of conditioning authors to expect things just because broadband in a few countries can deliver them easily. I should raise this as a request for HTML5.
