Re: Dedicated Geolocation List and Channel

[Ian Hickson]

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

[Anne van Kesteren]

On Tue, 27 May 2008 18:22:23 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

Anne van Kesteren wrote:
On Tue, 27 May 2008 18:12:25 +0200, Bjoern Hoehrmann  
<[EMAIL PROTECTED]> wrote:

* Julian Reschke wrote:
Yes, the I18N problems of Basic Authentication need to be fixed, but  
XHR

is not the right place to do it.


Agreed, I've repeatedly suggested to simply point out it is up to the
scheme to define how the unicode sequences are encoded in the message.
 This is what XMLHttpRequest says. It just has UTF-8 as fallback in  
case the authentication scheme doesn't define anything. (Which per  
Julian shouldn't affect this case so I'm not sure what the issue is.)


Well, you yourself claimed that the defaulting applies to Basic; and  
that XHR implementations use UTF-8.


So are you disagreeing that this is confusing, if you were confused  
yourself just a few hours ago?


Can you give an example of an authentication scheme to which the  
defaulting *would* apply?


You're right. I removed the encoding sentence leaving it up to the  
relevant specifications.



--
Anne van Kesteren

Re: XHR LC comments

[Anne van Kesteren]

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

XHR review extension

[Erik Dahlstrom]

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

[Anne van Kesteren]

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

Re: Dedicated Geolocation List and Channel

[Doug Schepers]

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: Dedicated Geolocation List and Channel

[Doug Schepers]

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: XHR review extension

[Doug Schepers]

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

[Maciej Stachowiak]

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

[Doug Schepers]

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

[Maciej Stachowiak]

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

[Ian Hickson]

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

[Maciej Stachowiak]

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

[Ian Hickson]

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

[Charles McCathieNevile]

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

[Doug Schepers]

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)

[Travis Leithead]

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

[Travis Leithead]

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

[Sunava Dutta]

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

[Jonas Sicking]

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