Re: Dedicated Geolocation List and Channel
On Mon, 2 Jun 2008, Doug Schepers wrote: Matt Womer and I have started a new email list for discussing geolocation. The new list, public-geolocation [1], will be archived, and the intent is for it to be the public list for the planned Geolocation WG: http://lists.w3.org/Archives/Public/public-geolocation/ I want to encourage folks not to put off technical discussion on the matter, or wait for the Geolocation WG to form; you can join the email list today, and start your engines. Of particular interest will be initial discussions of what the scope of the deliverables should be, and that will affect the charter. Could we please keep the discussion to this group? It seems like most people on this group agree that the work should happen in this group, and it would be very confusing to have to move stuff back and forth, especially if the charter proposal for geo fails, as seems likely given several browser vendors have requested that it stay in this group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Tue, 27 May 2008 15:44:21 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Tue, 27 May 2008 14:29:16 +0200, Julian Reschke [EMAIL PROTECTED] wrote: You're still avoiding the question whether the URL parameter can be an IRI. I would assume it can't, in which case the spec should require it to conform to RFC3986. It can. I made the specification more clear on this. - Is this actually implemented? Yes. In Opera and Firefix it is, at least. - If the URL parameter can be a IRI, then somewhere later on we need to state that it needs to be transformed to a URI before it's put on the wire. Added a transformation step as per 3.1 and also required throwing a SYNTAX_ERR in case of failure (ToASCII operation failure seems the most likely). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
XHR review extension
Hello webapi-wg, The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, thanks /Erik, (ACTION-2055)
Re: XHR review extension
On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom [EMAIL PROTECTED] wrote: The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Dedicated Geolocation List and Channel
Hi, Folks- Doug Schepers wrote (on 6/3/08 10:24 AM): From an IPR perspective, in order for a large company (or other organization) to get involved in the WG, they would have to do a wide-ranging (and lengthy and expensive) patent search. To join the WG, the company's patent search would have to cover *everything* that the WebApps WG is doing, not just geolocation. Just to clarify, I'm talking about the WebApps WG here... obviously, to join the proposed Geolocation WG, a company would only have to do a patent search and PP commitment on *geolocation*, not everything in the WebApps WG. :) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: XHR review extension
Hi, Anne- Anne van Kesteren wrote (on 6/3/08 9:44 AM): On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom [EMAIL PROTECTED] wrote: The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. If I'm missing some particular urgency, I'm happy to reconsider my two cents. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Dedicated Geolocation List and Channel
At this point I am really confused about where to discuss geolocation APIs, and I would rather not have it bounce back and forth. Maybe we should just wait until the chartering process reaches its conclusion. Regards, Maciej On Jun 3, 2008, at 7:24 AM, Doug Schepers wrote: Hi, Ian- Ian Hickson wrote (on 6/3/08 6:04 AM): On Mon, 2 Jun 2008, Doug Schepers wrote: Matt Womer and I have started a new email list for discussing geolocation. The new list, public-geolocation [1], will be archived, and the intent is for it to be the public list for the planned Geolocation WG: http://lists.w3.org/Archives/Public/public-geolocation/ Could we please keep the discussion to this group? It seems like most people on this group agree that the work should happen in this group, and it would be very confusing to have to move stuff back and forth, especially if the charter proposal for geo fails, as seems likely given several browser vendors have requested that it stay in this group. I appreciate that sentiment, and I see the browser vendors as a vital constituency in a successful Geolocation API specification. However, they are not the only stakeholders. To make this a truly open and universal API with broad uptake, we want to cultivate the participation of other industries in addition to browser vendors; camera manufacturers, GPS vendors, car makers, mobile phone operators, other standards bodies, etc. While some of them may have no direct interest in an API, they are likely to have insight into other aspects of geolocation that will inform an effective API. Many of them have shown interest in this in the past. From an IPR perspective, in order for a large company (or other organization) to get involved in the WG, they would have to do a wide-ranging (and lengthy and expensive) patent search. To join the WG, the company's patent search would have to cover *everything* that the WebApps WG is doing, not just geolocation. As you know, geolocation itself is a very mature technology, and there are hundreds of patents regarding its minutiae; if it turns out that the work we do ends up being contentious and spawning a PAG (Patent Advisory Group), it is better that it be isolated and not slow down the work going on in the rest of the WebApps WG. In addition to this, the vast majority of topics and emails on this list will not concern these other folks at all; it is rather overwhelming to get involved in such a high-traffic (and frankly contentious) list, especially if you aren't already in Web standards culture. So, regardless of where the actual deliverable ends up, it is therefore better to have a dedicated mailing list, for exactly the reason you state: it's confusing to have it move around, and keeping it on one list devoted to the topic will be much easier to track. If it happens that the Geolocation WG chartering fails, then the list can simply be attached to the WebApps WG. Easy. There is no additional burden on the WebApps WG participants to subscribe to one more list (or join one more WG), and there is a substantial burden on other interested parties in monitoring the public WebApps list. Seems like a clear choice to me. So, I'd respectfully ask that geolocation topics be conducted on public-geolocation, rather than slowing down the technical discussion by debating where we should be doing the work. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Dedicated Geolocation List and Channel
Hi, Maciej- Maciej Stachowiak wrote (on 6/3/08 1:53 PM): At this point I am really confused about where to discuss geolocation APIs, and I would rather not have it bounce back and forth. Maybe we should just wait until the chartering process reaches its conclusion. There's nothing to be confused about. Regardless where the deliverable ends up, whether in the proposed Geolocation WG, or the WebApps WG, the *discussion list* will be the same: http://lists.w3.org/Archives/Public/public-geolocation/ [EMAIL PROTECTED] I would strongly encourage folks to join and start discussions now, rather than waiting. A chartering period, with the review from W3C Management and the Advisory Committee, takes at least 6 weeks, and that doesn't include the time have preliminary discussions about it and to write the charter. Hixie indicated that Google did not want to wait even 2 weeks, and I agree that keeping momentum is a high priority. Naturally, if Apple wants to wait until the chartering period is over, that's your prerogative, but it doesn't seem like a good use of time and energy. I sense that, for some reason, people are feeling territorial about this issue, and I'm not sure why. Can you please articulate what your concerns about this happening in WebApps are, rather than in a dedicated WG? Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Dedicated Geolocation List and Channel
On Jun 3, 2008, at 11:19 AM, Doug Schepers wrote: Hi, Maciej- Maciej Stachowiak wrote (on 6/3/08 1:53 PM): At this point I am really confused about where to discuss geolocation APIs, and I would rather not have it bounce back and forth. Maybe we should just wait until the chartering process reaches its conclusion. There's nothing to be confused about. Regardless where the deliverable ends up, whether in the proposed Geolocation WG, or the WebApps WG, the *discussion list* will be the same: http://lists.w3.org/Archives/Public/public-geolocation/ [EMAIL PROTECTED] Well I'm pretty interested in coordinating with Google, Opera and Mozilla on this and it seems like they were interested in keeping the work and discussion here. It's true that you announced a new mailing list but it doesn't seem like anyone here asked for it. If it's going to be a mailing list for the WebApps WG, then maybe it would be good for the WG to discuss whether we want a separate list. I would strongly encourage folks to join and start discussions now, rather than waiting. A chartering period, with the review from W3C Management and the Advisory Committee, takes at least 6 weeks, and that doesn't include the time have preliminary discussions about it and to write the charter. Hixie indicated that Google did not want to wait even 2 weeks, and I agree that keeping momentum is a high priority. Naturally, if Apple wants to wait until the chartering period is over, that's your prerogative, but it doesn't seem like a good use of time and energy. Well, I wasn't that confused about where disucussion should go until you asked everyone to move discussion to a new list, when folks seemed happy to have it here. I sense that, for some reason, people are feeling territorial about this issue, and I'm not sure why. Can you please articulate what your concerns about this happening in WebApps are, rather than in a dedicated WG? I don't have any concerns about this being in WebApps. I think that would be a great option. Regards, Maciej
Re: XHR review extension
On Tue, 3 Jun 2008, Doug Schepers wrote: I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. If I'm missing some particular urgency, I'm happy to reconsider my two cents. Google supports the editor's opinion that we should not continue delaying publication given that the last call for comments was sent out in April and that the draft originally entered Last Call over a year ago. In particular, it is time to send implementors the message that the spec is ready to be implemented, especially given how XHR1 is effectively a basis for our extensions in XHR2, and how XHR2 has suffered innumerable delays in the past few months. However, that isn't to say that we should ignore the SVGWG's feedback. In practice I don't see how it makes any difference which level the spec is in -- if we receive feedback we should fix the spec either way. It is unlikely that the SVGWG would send feedback that requires substantial changes, since XHR1 is mainly aimed at describing existing behaviour. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR review extension
On Jun 3, 2008, at 7:12 AM, Doug Schepers wrote: Hi, Anne- Anne van Kesteren wrote (on 6/3/08 9:44 AM): On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom [EMAIL PROTECTED] wrote: The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. Given the length of time this spec has been in development and under review, I do not see a pressing need to extend LC. Regards, Maciej
Geolocation ideas
Hey Chaals, Could you please confirm that it is acceptable for us to begin unofficially discussing geolocation API requirements on the public-webapi@w3.org mailing list and for us to start noodling on ideas in CVS in the http://dev.w3.org/cvsweb/2006/webapi/ directory? We would like to start today. If yes, then could you maybe please also confirm that the working group will adopt geolocation APIs as a working group work item, at least until the W3C has decided whether to create a new working group for this? As far as I can tell no working group members has expressed their dissent and several have expressed their agreement since I first mentioned this last week, which puts us ahead of most of our working group decisions! :-) I understand that you are travelling; my apologies for making this request when you are indisposed. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR review extension
On Tue, 03 Jun 2008 11:12:21 -0300, Doug Schepers [EMAIL PROTECTED] wrote: Hi, Anne- Anne van Kesteren wrote (on 6/3/08 9:44 AM): On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom [EMAIL PROTECTED] wrote: The SVG WG would like to request a two week extension for reviewing the XMLHttpRequest LC draft. Please let us know if that is acceptable, I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. Actually, it is a process issue... I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. The urgency is based on the fact that people are looking to implement, or update implementations, in part because this spec is an important base for XHR2. We have an upcoming face to face meeting beginning 1 July, where we plan to close any final issues. Microsoft's review has already taken a long time, and has been promised within the week. However I note the request in private for an extension received a week or so ago. Therefore, If the SVG group can please try to produce its review as fast as possible, we can grant the requested extension to 16 June. Please note that we will not be giving a further extension without clear explanation of the exceptional circumstances that should justify it, and we would appreciate every day before then which you can reach. (We would also have appreciated the request coming in well before the deadline, ideally with some explanation...) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: XHR review extension
Hi, Chaals- Charles McCathieNevile wrote (on 6/3/08 4:46 PM): The urgency is based on the fact that people are looking to implement, or update implementations, in part because this spec is an important base for XHR2. We have an upcoming face to face meeting beginning 1 July, where we plan to close any final issues. Microsoft's review has already taken a long time, and has been promised within the week. However I note the request in private for an extension received a week or so ago. Therefore, If the SVG group can please try to produce its review as fast as possible, we can grant the requested extension to 16 June. Thanks, that's a reasonable explanation, and we will work to get our review to WebAPI as soon as possible (hopefully late this week or early next). For the most part, I believe that the current draft looks good, and we will be glad to be able to reference it in later versions of SVG. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
ACTION-250 TRAVIS - provide a simple test for modifier key combinations (specifically the alt key)
Attached test shows that some combinations of alt modifier keys on Windows-based machines are handled in a strangely consistent inconsistent way. Title: Alt S repro Lossy key combinations using the ALT modifier key on Windows-based machines There are several scenarios that will be used for comparison: Scenario 1: down ALT, down x, up ALT, up x Scenario 2: down ALT, down x, up x, up ALT Scenario 3: down ALT, up ALT, down ALT, up ALT Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT x was picked as it is a relatively neutral key in most browsers Directions for repro After this page loads, assuming no other clicks or focus within the webpage area, press the keys in the combinations shown in the scenarios The difference column in the table below should be zero for both rows. If it is not then there is a mismatch between keydown/keyup pairs. The last column indicates the result of the number of keyUp events minus the number of keyDown events. A positive number indicates more key ups and a negative number indicates more key downs, i.e, keyUps are being lost. What is essential in this repro is that the ALT key is the first key processed upon loading this page. In some browsers, pushing F5 is also considered a key that precedes the alt key (despite the page having been reloaded). In order to do a reload where ALT is processed as the first key, one needs to click on the address bar and push enter (assuming the page address is already in there). Testing results--two browsers The following table shows which keys are lost on several browser platforms tested. Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 IE7 x: up ALT: up x: ALT: up x: ALT: 2nd down x: up ALT: 2nd up, 2nd down x: ALT: 2nd up, 2nd down Firefox3RC1 x: ALT: up x: ALT: up x: ALT: 2nd down x: ALT: 2nd up, 2nd down x: ALT: 2nd up, 2nd down Press c to clear the results
DOML3: ACTION-266: TRAVIS - Test addEventListener vs onFoo attribute
Interesting findings (mostly related to IE): This test tries to define if the HTML event handlers (onFoo) are linked to the add/removeEventListener APIs in any way (or to define what the relationship is). Browsers tested: Opera 9.25, Firefox 3 RC1, IE8 Beta1, Safari 3.1.1. (on IE, I substituted attach/detachEvent for add/removeEventListener) The findings appear to indicate that: 1. All tested browsers follow a basic model in that an HTML event handler is maintained separately (perhaps in a separate queue) from event handlers attached via programmatic means (e.g., addEventListener/attachEvent). This can be verified by adding an HTML event handler and then trying to delete the reference to its DOM attribute via removeEventListener. In addition to this basic conclusion, there were a few discrepencies in event handling that should be noted: * IE/Firefox/Opera all keep a reference alive to the HTML event handler via the element's 'onclick' DOM attribute even after the content attribute has been removed. * Safari also keeps a reference to the element's 'onclick' handler, yet the body of the handler may be missing if the element's content attribute is removed (this prevents adding an event listener via the DOM attribute if the content attribute is missing). * IE's attachEvent is cumulative, despite re-applying the same handler over and over. detachEvent works in reverse, removing references until none are left. * IE has a bug that HTML event handlers are not actually removed via removeAttribute (though the attribute itself is removed). This is being fixed in IE8, but does impact this test page :( Title: onFoo versus programmatic event handlers onFoo versus add/removeEventListener(foo) This test checks the relationship between HTML inline event handlers and programmatically-added event handlers for both the Microsoft and W3C event handling models. The box below is the testing area for mouse events. It has no events attached by default when the page loads. The buttons below the box control the adding/removing of the following event handler to the box: onclick - cycle the color of the box from (0)red -> (1)orange -> (2)yellow -> (3)green -> (4)blue The buttons below it control the dynamic addition/removal of the event via the various dynamic mechanisms supported by browsers. 0 Event handler manipulation via the Element Event handler manipulation via the EventTarget Handler Attached: no Event handler manipulation via the EventTarget with references to the Element's DOM property Handler Attached: no
RE: Dedicated Geolocation List and Channel
Inline... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Tuesday, June 03, 2008 11:44 AM To: Doug Schepers Cc: Web API public Subject: Re: Dedicated Geolocation List and Channel On Jun 3, 2008, at 11:19 AM, Doug Schepers wrote: Hi, Maciej- Maciej Stachowiak wrote (on 6/3/08 1:53 PM): At this point I am really confused about where to discuss geolocation APIs, and I would rather not have it bounce back and forth. Maybe we should just wait until the chartering process reaches its conclusion. There's nothing to be confused about. Regardless where the deliverable ends up, whether in the proposed Geolocation WG, or the WebApps WG, the *discussion list* will be the same: http://lists.w3.org/Archives/Public/public-geolocation/ [EMAIL PROTECTED] Well I'm pretty interested in coordinating with Google, Opera and Mozilla on this and it seems like they were interested in keeping the work and discussion here. It's true that you announced a new mailing list but it doesn't seem like anyone here asked for it. If it's going to be a mailing list for the WebApps WG, then maybe it would be good for the WG to discuss whether we want a separate list.[Sunava Dutta] [Sunava Dutta] I think Doug's point is that there are more parties (and industries) that are affected by this. Of course, working with other browser vendors AND other invested parties is important. I would strongly encourage folks to join and start discussions now, rather than waiting. A chartering period, with the review from W3C Management and the Advisory Committee, takes at least 6 weeks, and that doesn't include the time have preliminary discussions about it and to write the charter. Hixie indicated that Google did not want to wait even 2 weeks, and I agree that keeping momentum is a high priority. Naturally, if Apple wants to wait until the chartering period is over, that's your prerogative, but it doesn't seem like a good use of time and energy. Well, I wasn't that confused about where disucussion should go until you asked everyone to move discussion to a new list, when folks seemed happy to have it here. [Sunava Dutta] I think Doug makes some very good points here. MSFT's stand based on the considerations that Doug has raised is that it should go to a new WG. There are teams here that do not need to be randomized with other WebApps conversations (that I participate in) but are nonetheless invested in GeoLocations. There is no additional burden for me to join a new list/WG and I'm glad to do so. I sense that, for some reason, people are feeling territorial about this issue, and I'm not sure why. Can you please articulate what your concerns about this happening in WebApps are, rather than in a dedicated WG? I don't have any concerns about this being in WebApps. I think that would be a great option. Regards, Maciej
Re: Dedicated Geolocation List and Channel
For the record: Where the discussion takes place is of little importance to me and mozilla. It would make sense to me to do it here, but I'm just as happy to discuss it elsewhere too. So I don't prefer it one place or the other. / Jonas
