ISSUE-37: [Progress] Use unsigned long long for .loaded and .total
ISSUE-37: [Progress] Use unsigned long long for .loaded and .total http://www.w3.org/2008/webapps/track/issues/ Raised by: Olli Pettay On product: Since Progress Events is used also for video, unsigned long long would be better than unsigned long. http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0225.html
Re: [selectors-api] What DOM feature Selectors API belongs to?
Moving to public-webapps from public-webapi. See original thread here.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg35
João Eiras wrote:
if (document.querySelector) {
// Supported
} else {
// Not suported
}
Too bad that only works with ecmascript.
Such syntax is not valid in other languages.
Is there really any demand from implementers of other languages to have
a feature sting defined for hasFeature()? Is there any evidence that
people make use of existing feature strings in their programs, using any
implementation?
Kartikaya Gupta wrote:
Ian Hickson wrote:
Kartikaya Gupta wrote:
What I think *is* inside the scope is to ensure that user-agents have some
unambiguous way to state whether or not they claim to implement the
specification. I think the feature string is much more reliable way to
do that than checking the existence of a querySelector method.
Why would any browser implementor implement one and not the other?
Because they might already be using the querySelector method for some
completely unrelated feature.
This seems like a very unrealistic edge case, considering we went to a
lot of effort to find names that didn't clash with existing features in
many implementations, not only browsers.
Since I've not seen any support for this proposal from any implementers
at all, and no substantial evidence that people actually make use of
existing feature strings in any environment, I'm not prepared to include
it at this stage.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Selectors API comments: section 2
Moved from public-webapi to public-webapps. Original issue raised here: http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0053.html (forgot to change the address to public-webapps, resending to correct list. Sorry for duplicates) Lachlan Hunt wrote: * It's not clear which IDL, if any, is being used when defining the DocumentSelector and ElementSelector interfaces. For example, the DOM Level 2 Core specification has a normative OMG IDL set of interface definitions, with normative text that says that OMG IDL is being used. I see no such normative text here, which I assume is a simple oversight. This issue has not yet been addressed. The spec now defines: | The IDL used in this specification uses the syntax defined in Web IDL | [DOM-BINDINGS]. * I don't see any indication of what the language bindings for this IDL should look like in languages which do not support function overloading based on number of arguments and do not allow functions with variable numbers of arguments. If it has been decided that no one is ever going to implement bindings for this specification in such a language , it might be good to explicitly say so in the specification so that it's clear that the problem has been considered. Another possible solution is to take the approach taken in other existing DOM specifications and tack NS onto the end of the name of a namespace-aware version of a method that is also available in a non-namespace-aware version. If the intent is to indicate that the bindings in some languages may allow omitting the second argument, I think that should be done via some mechanism that doesn't look like normative IDL. I would prefer to address this issue in the IDL, but I'm not yet sure how to fix it. The intention is for the methods to be overloaded, and for implementations that don't support method overloading, then the author will need to pass null as the NSResolver. Cameron, is there or will there be some way to deal with this issue in WebIDL? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] What DOM feature Selectors API belongs to?
Is there really any demand from implementers of other languages to have a feature sting defined for hasFeature()? Is there any evidence that people make use of existing feature strings in their programs, using any implementation? You provide a feature, then others use it, not the other way around. Ecmascript (javascript) programmers go directly for object detection because it's simpler. Still, the entire DOM spec has Java bindings, and one never knows, but in the future we can have other programming languages with DOM bindings, which can be used either in a browser or another kind of program that renders html/xml. Supporting hasFeature is about being forwards compatible. Else you're locking the Selectors API only to bindings that support object detection. (...)
Re: [selectors-api] What DOM feature Selectors API belongs to?
João Eiras wrote: Is there really any demand from implementers of other languages to have a feature sting defined for hasFeature()? Is there any evidence that people make use of existing feature strings in their programs, using any implementation? You provide a feature, then others use it, not the other way around. Ecmascript (javascript) programmers go directly for object detection because it's simpler. In this case, hasFeature() has existed for a while with various strings that can be used to detect other DOM APIs. My question was whether or not these other existing feature strings are used for such detection anywhere, in any language or implementation. If so, then that would serve as useful evidence supporting the addition of a feature string to Selectors API. If, however, hasFeatures is not used for any other features, then there's little evidence that it would be used for selectors api either. Still, the entire DOM spec has Java bindings, and one never knows, but in the future we can have other programming languages with DOM bindings, which can be used either in a browser or another kind of program that renders html/xml. Supporting hasFeature is about being forwards compatible. Vague hypothetical future scenarios do not serve as useful evidence. If the need ever arises for such feature detection to be incorporated into a future language, we can come back and take another look at the issue in a future version of the specification. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [access-control] Update
On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The name Access-Control-Origin is IMHO confusing. It's more or less identical to how it works for Web sockets. (Called Websocket-Origin there.) Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url should not be a full URL, and I don't think we want to depend on HTML5 for it either. Currently we seem to be allowing the syntax Access-Control-Origin: http://foo.com/bar/bin/baz.html which I think is very bad as it seems to indicate that only that page would be allowed to POST, which of course isn't something that we can enforce. This is exactly how postMessage() works and it seems nice to align with that. Additionally, the way the spec was written before we could create a conformat implementation now without having to worry about HTML5 changing things under us. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. Adding a dependency on HTML5 is bad for a couple of reasons: 1. We want to be able to ship implementations now and not change their parsing later as that can have security implications. 2. It has been politically hard to add dependencies to unfinished specs. Weather we think the concerns raised have merit or not, the debate is likely going to cause the spec to get delayed. Mostly I care about 1 above. Again, we want to have code reuse and not have separate concepts for same origin throughout the browser and Web platform. Since it uses exactly the same semantics as several HTML5 features, e.g. postMessage and Web sockets, that are also being deployed and shipped by all browsers who plan to implement this specification, I don't think this is much of a problem. Also, technically it is the superior solution, which should take care of 2. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
RE: [access-control] Update
Jonas said: I have a few comments: The name Access-Control-Origin is IMHO confusing. First of all I would expect allow or grant or something like that somewhere in the syntax to indicate that the header is granting access. I have two counter proposals: Access-Control-Allow-Origin : URL | * or Access-Control : allow URL I would prefer the latter one as that gives us better opportunity for future expansions if needed. That way the future expansions can be made such that existing clients bail due to unrecognized syntax if we so desire. I prefer Access-control: * Access-control: URL In the future, denying a particular URL can be represented using the - sign? Access-control: -URL Thoughts? -Original Message- From: [EMAIL PROTECTED] [mailto:public-webapps- [EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: Wednesday, July 09, 2008 1:23 PM To: Anne van Kesteren Cc: WebApps WG Subject: Re: [access-control] Update Looks great! I have a few comments: The name Access-Control-Origin is IMHO confusing. First of all I would expect allow or grant or something like that somewhere in the syntax to indicate that the header is granting access. I have two counter proposals: Access-Control-Allow-Origin : URL | * or Access-Control : allow URL I would prefer the latter one as that gives us better opportunity for future expansions if needed. That way the future expansions can be made such that existing clients bail due to unrecognized syntax if we so desire. Similarly, should we rename Access-Control-Credentials to Access-Control-Allow-Credentials? This feels less important to me. Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url should not be a full URL, and I don't think we want to depend on HTML5 for it either. Currently we seem to be allowing the syntax Access-Control-Origin: http://foo.com/bar/bin/baz.html which I think is very bad as it seems to indicate that only that page would be allowed to POST, which of course isn't something that we can enforce. Additionally, the way the spec was written before we could create a conformat implementation now without having to worry about HTML5 changing things under us. Note that when I said during the meeting that the URI paring was the hardest part, I didn't mean that URI parsing was hard. I meant it in the sense that the spec was so easy to implement that it was even simpler than URI parsing. So I strongly think we should bring back the language the spec used to have for parsing origins. And then the HTML5 spec can refer to the AC spec for origins if it so desires. Adding a dependency on HTML5 is bad for a couple of reasons: 1. We want to be able to ship implementations now and not change their parsing later as that can have security implications. 2. It has been politically hard to add dependencies to unfinished specs. Weather we think the concerns raised have merit or not, the debate is likely going to cause the spec to get delayed. Mostly I care about 1 above. I haven't reviewed the headers/methods stuff yet. But it looks good at an initial overview. / Jonas Anne van Kesteren wrote: Hi, The WebApps WG had a F2F last week in Seattle. While I'm still a bit buzzed by the jet lag I managed to finish the work I started during the weekend on updating the Access Control for Cross-Site Requests (AC) specification to match resolutions and proposals made during the F2F meeting. The meeting logs of the F2F are not publicly available yet, but since the editor's draft is, I will summarize what I changed and depending on whether you trust me or not, you can infer from that what we decided upon... The draft is available at the same place as usual: http://dev.w3.org/2006/waf/access-control/ Here is what I changed: * ?access-control? is dropped. Might return in AC2. * Access-Control is now Access-Control-Origin which takes * or a URL. In other words, whether or not a site grants access is simplified *a lot*. Implementors who told me this was the most complex part to implement can rejoice. This also makes this specification consistent with Web Sockets and postMessage(), both defined in HTML5. (Access-Control-Origin is not to be confused with the old Access-Control-Origin, which is now Origin.) * Access-Control-Credentials provides an opt in mechanism for credentials. Whether or not credentials are included in the request depends on the credentials flag, which is set by a hosting specification. Preflight requests are always without credentials. * Four new headers are introduced to deal with headers and method opt in. Two request headers (set by the user agent): Access-Control-Request-Method and Access-Control-Request-Headers. And two response headers: Access-Control-Allow-Method and Access-Control-Allow-Headers. (The introduction of these headers also affected the preflight result
RE: [access-control] Update
I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. Why is it less clear? Seems explicit to me. Access-control: -URL What is the use case for this? I suggested this as equivalent to Jonas recommendation... Access-Control : deny URL (Jonas had it at allow) I'd like to keep the simple check simple and stable over time. New features can be added through headers, as we're doing with credentials, headers, and methods I think this proposal is simple. It has the benefits of what I think Jonas meant when he said he would prefer the latter one as it allows for future expansions. Having Access-control as opposed to Access-Control-Allow-Origin enables the header to be flexible. -Original Message- From: Anne van Kesteren [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 3:18 PM To: Sunava Dutta; Jonas Sicking Cc: WebApps WG Subject: Re: [access-control] Update On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. In the future, denying a particular URL can be represented using the - sign? Access-control: -URL What is the use case for this? I'd like to keep the simple check simple and stable over time. New features can be added through headers, as we're doing with credentials, headers, and methods. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Update
On Jul 9, 2008, at 3:17 PM, Anne van Kesteren wrote: On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. I would be in favor of Access-Control or Access-Control-Allow, I think Access-Control-Origin and Origin are confusing in combination. It seems unclear from the names which is a request header and which is a response header. Regards, Maciej
Re: [access-control] Update
Maciej Stachowiak wrote: On Jul 9, 2008, at 3:17 PM, Anne van Kesteren wrote: On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. I would be in favor of Access-Control or Access-Control-Allow, I think Access-Control-Origin and Origin are confusing in combination. It seems unclear from the names which is a request header and which is a response header. Agreed. I also think that putting a somewhat more verbose syntax will give us a better forwards compat story. For example Access-Control: allow-without-query-parameters * or Access-Control: allow-only-tuesdays * I have a hard time believing that we would never find it useful to extend the syntax in future versions of the spec. I also as an implementor don't find it hard to strip out allow before the origin. I also find it very useful that you can just look at the header in order to realize that it is granting some sort of access, which putting the word allow in the syntax does. So either Access-control: allow * or Access-control-Allow: * fulfills that. That said, I would be ok with simply Access-Control: * as well. If we need degradation in the future we can always invent new headers... / Jonas
Re: [access-control] Update
Anne van Kesteren wrote: On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The name Access-Control-Origin is IMHO confusing. It's more or less identical to how it works for Web sockets. (Called Websocket-Origin there.) If only we had the editor of that spec around... ;) Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url should not be a full URL, and I don't think we want to depend on HTML5 for it either. Currently we seem to be allowing the syntax Access-Control-Origin: http://foo.com/bar/bin/baz.html which I think is very bad as it seems to indicate that only that page would be allowed to POST, which of course isn't something that we can enforce. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. Additionally, the way the spec was written before we could create a conformat implementation now without having to worry about HTML5 changing things under us. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. So why not let HTML5 refer to Access-Control? / Jonas
Re: [selectors-api] Selectors API comments: section 2
Hi Lachy (and a question for Anne and Ian at the end). Boris Zbarski: * I don't see any indication of what the language bindings for this IDL should look like in languages which do not support function overloading based on number of arguments and do not allow functions with variable numbers of arguments. If it has been decided that no one is ever going to implement bindings for this specification in such a language , it might be good to explicitly say so in the specification so that it's clear that the problem has been considered. Another possible solution is to take the approach taken in other existing DOM specifications and tack NS onto the end of the name of a namespace-aware version of a method that is also available in a non-namespace-aware version. If the intent is to indicate that the bindings in some languages may allow omitting the second argument, I think that should be done via some mechanism that doesn't look like normative IDL. Lachlan Hunt: I would prefer to address this issue in the IDL, but I'm not yet sure how to fix it. The intention is for the methods to be overloaded, and for implementations that don't support method overloading, then the author will need to pass null as the NSResolver. Cameron, is there or will there be some way to deal with this issue in WebIDL? Two possibilities off the top of my head. First is to handle optional arguments differently from overloading, and then state that bindings for languages that don’t allow overloading should just include the operation with no arguments omitted. For example: Element querySelector ([Null=Empty, Undefined=Empty] in DOMString selectors, [Optional] in NSResolver nsresolver); [Optional] would mean that that argument, and all following it, could be omittied. That would allow you to do things like this: void f([Optional] in any a, in any b, [Optional] in any c); which means you could call f() in three different ways: f() f(1, 2) f(1, 2, 3) A second possibility is either [OmitIfNoOverloading] on the operation to leave out, or [IncludeIfNoOverloading] on the operation to leave in, if overloading is not supported in the language. So that would be either: Element querySelector ([Null=Empty, Undefined=Empty] in DOMString selectors); [IncludeIfNoOverloading] Element querySelector ([Null=Empty, Undefined=Empty] in DOMString selectors, in NSResolver nsresolver); or: [OmitIfNoOverloading] Element querySelector ([Null=Empty, Undefined=Empty] in DOMString selectors); Element querySelector ([Null=Empty, Undefined=Empty] in DOMString selectors, in NSResolver nsresolver); Those names aren’t so nice though; suggestions welcome. I think of those two, I would prefer the [Optional] one. Optional arguments seems to be what overloading is used for in the majority of cases in specs being written at the moment. Anne and Ian (since your specs use overloading for optional arguments): any opinion? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [selectors-api] Selectors API comments: section 2
On Thu, 10 Jul 2008, Cameron McCormack wrote: Anne and Ian (since your specs use overloading for optional arguments): any opinion? Not really. If we want to handle languages that don't have overloading, then we need to make the IDL always require a separate name for the overloaded functions. We could just say that lack of such a name means that the function isn't included, and only the last function in an IDL block with a particular name is included if overloading isn't supported. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[AC] Preflight-less POST
Hi All, During the F2F we talked about doing preflight-less POSTs in order to be compatible with microsofts security model and allow them follow the AC spec for their feature set. Unfortunately when I brought this up at mozilla there was concern about doing cross-site POSTing with content types other than what forms already allow. The concern was that it could make servers exploitable, which weren't today. So I see a few ways forward: 1. Build more confidence about that this would not in fact break servers. I'm working on this method. I've contacted Adobe since I think flash currently allow cross-site POSTing with arbitrary Content-Types. I've also contacted Microsoft to see if they have gotten any feedback on IE8 Beta 1 where XDR allow arbitrary content types to see if they have gotten any feedback there. Silverlight also support this feature. I'd also like to make a general shout-out here to see how people feel about this, or if they know of any other protocols that send arbitrary Content-Types with cross-site POSTs that we could use to gather data about if this makes sites exploitable. If anyone has pointers to any research that has been done on flash in general, or its cross-site posting mechanism in particular would be great, even if it doesn't mention this specific issue. 2. Don't require pre-flight for POSTs 'text/plain', but require it otherwise. The downside of this solution is that it encourages people to use 'text/plain' as Content-Type for everything they send which has its downsides. The upshot is that this would still allow compat with XDR. 3. Always pre-flight POSTs This would abandon any hope of allowing XDR to use Access-Control as securit protocol. Unless microsoft were able to implement preflights in IE8, but it seems like it's really late in their release schedule for such a large change. One thing that I really like about proposal 1 is the simplicity. We would say POST can be done cross origin without any checking, so you need to protect yourself against that. Any other proposal is basically POST can be done cross origin without any checking, but only for these here values of the 'Content-Type' header. Except that it looks like in Access-Control you can rely on those requests not coming in. Oh, and if you are concerned about users of Flash and Silverlight being exploitable you do need to worry about all values for 'Content-Type'. / Jonas
Re: [access-control] Update
As promised, I've discussed the proposal we discussed at the F2F with my extended team and we're excited about making the change to integrate XDomainRequest with the public scenarios specified by Access Control. This means IE8 will ship the updated section of Access Control that enables public data aggregation (no creds on wildcard) while setting us up on a trajectory to support more in the future (post IE8) using the API flag in an XDR level 2. Awesome! I think this is great news for the web community. I just want to say great job to all those involved in seeing convergence being reached. I believe many web developers are going to benefit from this specification, and much more so now that it will be accessible across browsers. Thank you for your efforts, Kris
Re: [selectors-api] Selectors API comments: section 2
On Thu, 10 Jul 2008 01:56:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 10 Jul 2008, Cameron McCormack wrote: Anne and Ian (since your specs use overloading for optional arguments): any opinion? Not really. If we want to handle languages that don't have overloading, then we need to make the IDL always require a separate name for the overloaded functions. We could just say that lack of such a name means that the function isn't included, and only the last function in an IDL block with a particular name is included if overloading isn't supported. I would prefer to not make any changes so in case of a language not supporting optional arguments I suggest that language picks the version with the most arguments. I rather not add additional IDL information for such languages as they're probably a 1% use case. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Update
On Thu, 10 Jul 2008 01:13:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. Let me know how that works out. postMessage() is shipping already in various implementations... I don't want to carry this mistake forward into Access-Control. It seems bad to do something totally different, especially since it's pretty obvious what the net result is. Additionally, the way the spec was written before we could create a conformat implementation now without having to worry about HTML5 changing things under us. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. So why not let HTML5 refer to Access-Control? I don't really see how that would work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
