Invitation to WebApps Mailing List

for the join link): http://www.w3.org/2008/webapps/ Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF

Transitioning to WebApps Mailing List

, if they are on there. This way, we can have a fairly smooth transfer, though for some older issues, you may have to refer to some emails on one of the older lists. Thanks! -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF

Re: Transitioning to WebApps Mailing List

to do. It would take me less time than it did to write this email, for sure. :) Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF

Re: Geolocation ideas

Hi, Folks- Charles McCathieNevile wrote (on 6/5/08 8:01 PM): On Thu, 05 Jun 2008 22:09:30 +0200, Doug Schepers [EMAIL PROTECTED] wrote: Matt Womer set up a (temporary?) playground to submit geolocation API documents for discussion: http://dev.w3.org/geo/ and http://dev.w3.org/geo

Re: Geolocation ideas

, which was perhaps an unluckily sub-optimal choice. Happy birthday! Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Cancelled

Hi, WebAPI Fans- I'm not feeling well today, and I'd like to cancel today's DOM3 Events telcon. I appreciate people closing out their actions, and I will upload my own changes to the spec later today. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

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

Re: XHR review extension

my two cents. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Dedicated Geolocation List and Channel

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

it in later versions of SVG. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Dedicated Geolocation List and Channel

or bad idea. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

[XHR] Dependencies in XHR

that everything in the spec is normative unless marked otherwise, but I just wanted to make sure that none of the references are informative? Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI Ian Hickson wrote (on 5/27/08 4:39 PM): Hi, Google would like to volunteer some resources to work on a specification to provide a Geolocation API for the Web platform. Does anyone on the working group think we should not work

Re: Proposal to work on Geolocation

. The Geolocation API WG is intended to work specifically on a client-side API. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

its creation as far as we can. Don't panic. :) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

Hi, Ian- Ian Hickson wrote (on 5/27/08 6:09 PM): On Tue, 27 May 2008, Doug Schepers wrote: The W3C intends to follow through on that, and to allocate Team resources to this valuable technology. We will announce something formal soon. Rest assured that Mike and I are intent on ensuring

Re: Proposal to work on Geolocation

Hi, Ian- Ian Hickson wrote (on 5/27/08 6:20 PM): On Tue, 27 May 2008, Doug Schepers wrote: I want to reiterate that W3C is *not* dropping the Geolocation API... we merely propose to move it to a dedicated WG. [...] Again, we are actively encouraging all interested parties to join

Re: Proposal to work on Geolocation

and of IPR). For the record, Opera would also like to see the geolocation work take place inside the webAPI group and is unhappy that it has been removed from the proposed charter for Web Apps. Noted. I will convey your sentiments to the Team. Regards- -Doug Schepers W3C Team Contact, SVG

Re: [XHR] Dependencies in XHR

Hi, Anne- Anne van Kesteren wrote (on 5/27/08 6:24 PM): On Tue, 27 May 2008 18:59:38 +0200, Doug Schepers [EMAIL PROTECTED] wrote: It seems that there are multiple dependencies upon HTML 5.0 in the XHR specification. As Team Contact, I would like to caution against this approach

Re: Proposal to work on Geolocation

Hi, Ian- Ian Hickson wrote (on 5/27/08 7:38 PM): On Tue, 27 May 2008, Doug Schepers wrote: That's a very reasonable concern. Since we are hoping for the WebApps WG to be chartered as soon as we hear back from the AC reps (hopefully a couple of weeks or less), it may not be appropriate

Re: [XHR] Dependencies in XHR

Hi, Ian- Ian Hickson wrote (on 5/27/08 8:44 PM): On Tue, 27 May 2008, Doug Schepers wrote: I believe that origin can be defined in the Window Object specification, one of this WG's explicit deliverables. Objects implementing the Window interface must provide an XMLHttpRequest

DOM3 Events Telcon Cancelled, 21 May 2008

Hi WebAPI Fans- Since 2 of us are busy with an SVG F2F meeting, we have decided to cancel the DOM3 Events Telcon this week. We will pick it up again next week. We can also explore different days and times. Any preferences? Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Agenda, 14 May 2008 (Today!!)

/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: DOM3 Events Telcon Agenda, 14 May 2008 (Today!!)

Hi, Folks- I have a conflict later on in the call, so it will be a short D3E telcon. I plan to end at 3:30. Thanks- -Doug Doug Schepers wrote (on 5/14/08 7:41 AM): Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon today, 14 May. Please reply to public-webapi@w3

Re: Mouse wheel feedback

. For SVG in particular, I think such zooming is an important use case. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Mouse wheel feedback

. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Minutes, DOM3 Events Telcon, 16 April 2008

Hi, WebAPI fans- The minutes for the DOM3 Events telcon on 16 April 2008 can be found here: http://www.w3.org/2008/04/16-webapi-minutes.html Or as text below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference

[Fwd: [closed] Re: Publication Request: Language Bindings for DOM WD]

Original Message Date: Thu, 10 Apr 2008 19:23:39 -0400 From: Jules Clement-Ripoche [EMAIL PROTECTED] Hi Doug, Your document has been published, Language Bindings for DOM Specifications W3C Working Draft 10 April 2008 This Version:

Re: Some key event handling issues of interest

or in browser chrome) may move control out from the element, which means that event flow stops. Agreed. Good point, we will make that clear that at any point, the sequence of events may simply be interrupted. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Element Traversal LC] access to element by index

. This might be a good time to talk to them. The SVG WG is not the only stakeholder that I'm trying to get feedback from. I will be posting my research and conclusions very soon. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Minutes, DOM3 Events Telcon, 02 April 2008

] trackbot Created ACTION-270 - Document Key Identifiers on wiki [on Doug Schepers - due 2008-04-09]. Adios Summary of Action Items [NEW] ACTION: Carmelo to cross tests keyup keydown and keypress [recorded in [26]http://www.w3.org/2008/04/02-webapi-minutes.html#action02] [NEW

Re: [Element Traversal LC] access to element by index

needed many times. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Agenda, 02 April 2008 (Tomorrow!!)

and planned telcons, with a brief summary of issues discussed. [3] [1] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time [2] http://www.w3.org/2008/webapps/wiki/02_Apr_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Element Traversal LC] access to element by index

this into a thread on the Selectors API, which I have my own issues with, but AIUI, this should work, and is pretty straightforward. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Element Traversal LC] access to element by index

Hi, Boris- Boris Zbarsky wrote (on 3/28/08 1:41 PM): Doug Schepers wrote: Speaking as an author of many SVG Webapps and a contributor to several SVG script libs, knowing the number of child elements is a really common need; index-based access is less needed, and can be effected by other

DOM3 Events Keyflow

software [2], and the Dot format is really simple to edit. We are hoping to discuss this again at next week's teleconference. [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg [2] http://www.graphviz.org/ Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Agenda, 26 March 2008 (Tomorrow!!)

] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time [2] http://www.w3.org/2008/webapps/wiki/25_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Minutes: DOM3 Events Telcon, 19 March 2008

] trackbot Created ACTION-263 - Draw up state chart diagram for key flow [on Doug Schepers - due 2008-03-26]. OP: Had some questions about the second keyPress ... Why is there another keyDown in the repeat process? TL: You are saying the second keyDown in the list? ... We'll try

Keyboard Review Telcon

#Events-TextEvents-Interfaces Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Agenda, 19 March 2008 (Tomorrow!!)

/webapps/wiki/DOM3Events#Day_and_Time [2] http://www.w3.org/2008/webapps/wiki/19_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Please Review: Mousewheel Event Proposal

Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: IE Team's Proposal for Cross Site Requests

: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html Thanks- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: Accessing Object Parameters from an Embedded SVG

): It would have been great if HTMLObjectElement had an accessible params NodeList readonly attribute :( Yes, indeed. It's not too late to add that! Boris, do you mean that it's not too late to add that to Fx3? What about window.paramList? Regards- -Doug Schepers W3C Team Contact, SVG, CDF

Re: [Element Traversal LC] Editorial: attribute at ECMAScript Language Binding

] http://lists.w3.org/Archives/Public/public-webapi/2007Aug/0035.html Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

different bindings to the same functionality, not the same binding. David's explanation is indeed correct (thanks, David). Does this satisfy your comment? Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Agenda, 12 March 2008 (Today!!)

] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

a Proposed Recommendation. ;) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

to satisfy all Last Call comments before moving on. I just wanted to make sure that that would suffice for you. Thanks again. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Minutes: DOM3 Events Telcon Agenda, 12 March 2008

wrt mousewheel proposal [recorded in [15]http://www.w3.org/2008/03/12-webapi-minutes.html#action01] trackbot Created ACTION-258 - Review Mozilla bug for pixel scrolling and consider wrt mousewheel proposal [on Doug Schepers - due 2008-03-19]. scribe ACTION: Doug to give deadline

Key Event Order

there, I think. http://www.w3.org/2008/webapps/wiki/Key_event_order Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

DOM3 Events Telcon Minutes, 27 Feb 2008

] trackbot Created ACTION-247 - Provied test template [on Doug Schepers - due 2008-03-05]. DS: Test should work on every Browser ... Test should figure out if person Double Click ... How can we actually check for that? ... We should make a framework for the test scribe ACTION: TL

Re: ElementTraversal comments

Hi, Anne- Anne van Kesteren wrote (on 2/26/08 4:52 AM): On Tue, 26 Feb 2008 06:42:49 +0100, Doug Schepers [EMAIL PROTECTED] wrote: Anne van Kesteren wrote (on 2/25/08 4:25 PM): * It's not clear from the introduction why we need childElementCount. Having both linked list and array like

Re: ElementTraversal comments

Hi, Ian- Ian Hickson wrote (on 2/26/08 3:42 PM): On Tue, 26 Feb 2008, Doug Schepers wrote: * I don't understand A User Agent may implement similar interfaces in other specifications, but such implementation is not required for conformance to this specification, if the User Agent

DOM3 Events Telcon Agenda, 27 Feb 2008 (Tomorrow!)

, with a brief summary of issues discussed. [3] [1] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time [2] http://www.w3.org/2008/webapps/wiki/27_Feb_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI

Re: [waf] New Charter proposal

concerns, but I think we can address them within the framework of a single WG. [1] http://www.w3.org/2007/12/WebApps-Charter/WebApp-Charter-2007-proposed#communication Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI

Re: future/draft/current W3C specs on multi-cursor / multi-touch ?

will come out of that. http://www.w3.org/2007/08/mmi-arch/cfp.html Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI

Re: [ElementTraversal] Remarks on http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.10

references to DOM Level 2 Range Traversal and DOM Level 3 Core Done. Meant to do that earlier and forgot. Thanks for the reminder. Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI

Re: [ElementTraversal] Editorial: property vs. attribute

the ElementTraversal interface which has five attributes as its members. However it refers to them as properties. This is inconsistent with other DOM specs. Why are they called properties in this spec? Could it be changed for consistency with other specs? Regards- -Doug Schepers W3C Staff Contact, SVG, CDF

Re: [ElementTraversal] Not a set of properties on Element

navigate between elements in a document. In conforming implementations of ElementTraversal, all objects that implement Element must also implement ElementTraversal. Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI

Selectors API Names (was: CSS Query API: selectorQuery(...))

Hi- Just to alleviate any confusion, Bjoern is referring to the Selectors API spec [1] (not CSS Query API, which is not the name of a WebAPI spec). [1] http://www.w3.org/TR/selectors-api/ Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI Bjoern Hoehrmann wrote: Hi

Re: Selectors API Method Names

Hi- Maciej Stachowiak wrote: I don't have a strong objection either way, but I think the case against Lachy's original names (selectElement, etc) has been laid out more clearly than the case against cssQuery. I think selectorQuery (as suggested in follow-ups) would also be ok. I think

Re: Selectors API Method Names

Hi, Maciej- Maciej Stachowiak wrote: Similarly, with selectorQuery() (which is better), you lose the verby action word of the existing naming convention (getAByB); selectorQuery sounds more like a property than a method. querySelector or matchSelector or similar would keep the verb phrase

Re: [selectors-api] The Naming Debate

Hi, Jean-Yves- Jean-Yves Bitterlich wrote: We find it unfortunate that past resolutions within the working group are being invalidated (unless of course there are new evidences/information that justify this act) in particular because this behavior leads to rehashing issues instead of

Re: [selectors-api] The Naming Debate

Hi, Martijn- Martijn wrote: 2007/6/28, Doug Schepers [EMAIL PROTECTED]: Martijn wrote: Sorry, I meant that I won't participate anymore. I'm just getting unhappy by this and it's affecting the work that I really should be doing. I'm very sorry to hear that. I don't want you to feel

Re: Comments on element traversl specification (multiple responses)

Hi, Ray- Ray Whitmer wrote: Doug writes: It doesn't seem to me that what you are looking for is in scope for ElementTraversal. The whole point of ElementTraversal is that it ignores all non-element content. This is most useful for languages such as SVG where most content is not markup per

Re: Comments on element traversal specification...

Hi, Ray- Thanks for your feedback. Ray Whitmer wrote: I just saw an element traversal API draft, which is a good, powerful idea that is quite close to the helper functions I write every time I use DOM for serious work. My main comment: I could not use unless it does not do something

Re: ElementTraversal spec draft

Accidentally sent offlist to Boris. Repeating here. Boris replied to me as well, but I'll leave it to him to send that to the list if he wishes. Regards- -Doug Original Message Subject: Re: ElementTraversal spec draft Date: Fri, 16 Mar 2007 18:33:22 -0400 Hi, Boris-

Re: ElementTraversal spec draft

Stewart Brodie wrote: Boris Zbarsky [EMAIL PROTECTED] wrote: Doug Schepers wrote: Sure, on a established code base for a desktop browser, that makes sense. But on mobile devices with limited memory, maintaining a live list is more overhead. I agree that it can sometimes be more processor

Re: ElementTraversal spec draft

Hi, Maciej- Thanks for the feedback. Maciej Stachowiak wrote: On Apr 3, 2007, at 9:50 AM, Doug Schepers wrote: The functionality I was requesting primary feedback on was whether or not to include an interface in the ElementTraversal spec which would provide a list of elements (not nodes

Re: XMLHttpRequest for Last Call

Hi- I think we should rename it .getOrPostRemoteContentByHttp(). Ok, just kidding. But I did want to remind you to take out the following: Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the

Re: Proposal: getElementsBySelector()

Hi, Anne- Anne van Kesteren wrote: Given the input from Björn I suppose there's no real need for a method that returns a single element node (assuming implementations make that optimization). It might be worthwhile to add an informative note to the spec describing this optimization to

Re: Key events...

Thanks. I, for one, welcome my new legacy keyboard overlords. -Doug Charles McCathieNevile wrote: These are horrid. There are some outstanding action items - ACTION-174 and ACTION-175, and although it has been closed you could see the thread associated with

Re: Selectors API naming

Hi, Ian- Ian Hickson wrote: On Fri, 26 Jan 2007, Doug Schepers wrote: A way to reduce the number of typos might be to drop the trailing s from both method names. It's equally clear what it does IMHO. Hmmm... that's a reasonable point, but Selector (singular) is a bit misleading. You can

Re: Selector API names - strawman

Hi- Robin Berjon wrote: Here is a proposal that is intended to satisfy both the brevity nazis, and those who like meaningful method names. I don't really like them myself, but I can live with them. - Document.css() - Document.cssAll() - Element.css() - Element.cssAll() Same length,

Re: Selectors API naming

Hi, Alex- Alex Russell wrote: document.matchAll is deviating from that. Document.getElementsBySelector has a higher readability in that regard I think. I disagree. It's perhaps easier to *introduce*, but it's actually harder to read since it makes lines longer and therefore increases the

Re: Selectors API naming

Hi, Anne- Anne van Kesteren wrote: Currently the following methods exist: * document.getElementsByTagName() * document.getElementsByName() (HTML only) * document.getElementById() The following method is proposed by the WHATWG: * document.getElementsByClassName() I'd really like to

Re: Selectors API naming

Hi, Maciej- Maciej Stachowiak wrote: - Microsoft representatives endorse a longer name -- I don't think Microsoft's track record in design of web APIs for JavaScript justifies treating them as an authority. I hope their arguments will be evaluated on their merits, not the credentials of

Re: Selectors API naming

Hi- Ian Hickson wrote: This thread is going nowhere. I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. I agree that most of the useful arguments have been made.

Re: Selectors API naming

Hi- Some context... Ian Hickson wrote: I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. [...] I have confidence in Anne; I'm sure he would not design by theology,

Re: Selectors API naming

Hi- I agree. I think getElementsBySelector() is a good name that follows a meaningful naming convention. Having a slightly longer name for a method doesn't prevent people from making shorter aliases, but having an unclear name does prevent people from understanding it intuitively.

Re: Selectors API naming

Hi- Robert Sayre wrote: On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote: That those methods have failed is not conclusive. Well, the possibility has certainly been widely discussed. http://www.google.com/search?q=DOM+sucks Huh? The first 2 pages (at least) of that search seemed

Re: Selectors API naming

Hi, Robert- Robert Sayre wrote: On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote: Huh? The first 2 pages (at least) of that search seemed to complain about the lack of consistency in support among different browsers, not about the supposed failure of the longer DOM method names. [1

Re: Liason statement from JSR 280: WheelEvent and ProgressEvent usage

Hi, All- Charles McCathieNevile wrote: The MouseMultiWheelEvent is for the case where there are multiple wheels in play. I believe that MouseMultiWheelEvent is rather for the case where a single wheel has multiple axes, not when there multiple wheels. This is a separate issue which needs

Adobe Flash Cross-Domain Access

Hi, folks- I'm following up on the action to research how Adobe Flash handles cross-domain access. This is done by the use of an XML file on the target server, crossdomain.xml. The security model is described in a PDF whitepaper [1]: The Cross Domain Policy File mechanism is a simple XML

Re: Welcome to the group

Hi, Cedric- Welcome to the WebAPI WG! Charles McCathieNevile wrote: Hi folks, please welcome Cedric Thienot to the working group. He is, like Robin, from Expway, and we look forward to working with him. (Please let us know how many deliverables you would like... :) ) Regards- -Doug

Pressure Sensitivity for Tablets

Hi, WebAPI WG- Many tablet devices, including graphics peripherals and tablet-laptops, have varying levels of sensitivity which measure not only the position of the pen on the canvas, but also how hard it is being pressed. This would be an easy thing for us to add, I think. I propose that we

RE: Proposal for mousewheel events

Oops... I submitted an alternate multiple-device proposal before I read Stéphane's. Looks like we were thinking similar things, but he went a bit farther. Regards- Doug Doug Schepers wrote: | | A related idea is to indicate which wheel this is, on a | device with multiple | wheels. I think