Re: Transitioning to WebApps Mailing List
Hi, Maciej- Maciej Stachowiak wrote (on 6/10/08 12:18 PM): Would it be possible to just automatically subscribe members of both old lists to the new list, to smooth the transition? Yes, it is possible. I had thought of doing that, and got as far as concatenating a list of all subscribers to all lists and diffing that with the current subscribers to public-webapps... there's about 266 people subscribed to public-webapi and public-appformats that aren't yet on public-webapps. It would be easy enough for me to add them manually, with a notification email sent to all new subscribers. However... 1) some people may object to being autosubscribed 2) I don't know if there are IPP implications I will check with our legal/comm people on the IPP issue tomorrow. As for being subscribed to a list without being asked... I don't know. On the one hand, these people are presumably already interested in the topics because they subscribed to at least one of the lists (and there was a lot of overlap), and they can easily unsubscribe... but on the other, well, people are weird. What does everyone else think? Like I said, I'm happy to do it if it's seen as a reasonable thing 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
Transitioning to WebApps Mailing List
Hi, WebApps Fans- As a follow-on to my previous invitation, I just wanted to give a tip about what I see as the easiest way to do this transition. Step 1: Join public-webapps ( http://lists.w3.org/Archives/Public/public-webapps/ ); you need to do this explicitly even if you're a members of the WebApps WG; Step 2: When replying to an email thread on either public-webapi or public-appformats, add public-webapps to the recipients list; Step 3: When replying to an email thread on public-webapps, remove public-webapi or public-appformats from the recipients 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
Invitation to WebApps Mailing List
Hi, WebAPI and WAF fans! The kings are dead! Long live the king! As planned a few months ago, we have successfully merged the Web Application Formats and WebAPI WGs into a single powerful new group, the Web Application Working Group (WebApps WG to its friends). We made front page news at W3C: http://www.w3.org/News/2008#item107 If you are a member of the public interested in participating in discussions, please join the public-webapps mailing list: http://lists.w3.org/Archives/Public/public-webapps/ If you wish to join the WG, you can find more info on the home page (look for the "join" link): http://www.w3.org/2008/webapps/ 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/api All of Chaals' caveats above apply to the new repo, too, of course... as do any IPR issues you can think of. And any documents can be sent to the public-geolocation email list as attachments, too, if that is more convenient. Although there is a W3C policy on what kind of attachments are acceptable. In short, please use HTML if you have to do this. (Having versioned documents is far better than attachments IMHO) True. FYI, if anyone needs a CVS account for Geolocation, please contact Matt or me. If you need one for WebApps, contact me. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Geolocation ideas
Hi, Chaals- Charles McCathieNevile wrote (on 6/5/08 11:21 AM): If there is no apparent movement in the time between now and our face to face meeting, that may be time to take it up again. In the meantime why not give the W3C Team a little credit for acting in good faith, and the time to do their work at a reasonable rate? Thanks for the support. I am conscious of the potential delay, and I'm trying to mitigate it as much as possible. Since the webspace at dev.w3.org/2006/webapi is just a set of addresses for convenience, and since we are discussing something that is clearly some kind of WebAPI, unless there is some process reason I don't know of or you do something blatantly stupid like trying to make a document look like it has more W3C support than it does through inappropriate use of stylesheets, missing or misleading status statements and so on, I don't see that it is impossible to put a proposal for a spec into that space. Indeed, there is no reason I can see that a geolocation group could not continue using a chunk of that space, given that there is trust between the members of the two groups not to step on each other's work. 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/api All of Chaals' caveats above apply to the new repo, too, of course... as do any IPR issues you can think of. And any documents can be sent to the public-geolocation email list as attachments, too, if that is more convenient. Well, the reply gets out according to the vagaries of net access and my time, which is the same rule that always applies. You just picked the moment I finished work and went to celebrate my birthday as the time to send mail, 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: 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
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
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
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
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
Dedicated Geolocation List and Channel
Hi, Folks- 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. In parallel, we will be working on the charter in public, and will present it to W3M and submit it for AC Review. We already know that there is considerable Member interest in this activity, so we anticipate a smooth review period, and will announce the new WG as soon as possible. We will keep the public-geolocation list informed every step of the way. We've also started a new W3C IRC channel, #geolocation. Please feel free to have discussions there, as well. We are interested in keeping logs of the chat there on the W3C servers, so chime in if you think that's a good or bad idea. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Minutes, DOM3 Events Telcon, 28 May 2008
Hi, WebAPI fans- The minutes for the DOM3 Events telcon on 28 May 2008 can be found here: http://www.w3.org/2008/05/28-webapi-minutes.html Or as text below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 28 May 2008 [2]Agenda [2] http://www.w3.org/2008/webapps/wiki/28_May_2008 See also: [3]IRC log [3] http://www.w3.org/2008/05/28-webapi-irc Attendees Present [Microsoft], Carmelo, Doug, aemmons, smaug, +47.21.65., hallvors Regrets Chair SV_MEETING_CHAIR Scribe Travis Contents * [4]Topics 1. [5]Issue/action review 2. [6]onFoo vs. addEventListener * [7]Summary of Action Items _ Date: 28 May 2008 Scribe: Travis [8]http://www.w3.org/2008/webapps/wiki/Special:Listusers [8] http://www.w3.org/2008/webapps/wiki/Special:Listusers scribeNick: Travis Issue/action review Travis is a bit lazy. [9]http://www.w3.org/2005/06/tracker/webapi/products/2 [9] http://www.w3.org/2005/06/tracker/webapi/products/2 71 open actions (all overdue) [10]http://www.w3.org/2005/06/tracker/webapi/actions/open [10] http://www.w3.org/2005/06/tracker/webapi/actions/open [11]http://www.w3.org/2005/06/tracker/webapi/actions/276 [11] http://www.w3.org/2005/06/tracker/webapi/actions/276 Reviewing various action items in Tracker... Mouse wheel event is pretty much done... Doug: legacy mousewheel + the "nice way" event with multi-deltas ... will add nice combination of legacy behavior for all implementations ... wrt mousewheel stuff ... Pixel scrolling vs. Line scrolling olli: should check out mozilla info on pixel scrolling Doug: will continue to checkin with olli offline to incorporate info into spec. ACTION: Doug to incorporate info on mousewheel event in conjunction with Olli's info. [recorded in [12]http://www.w3.org/2008/05/28-webapi-minutes.html#action01] Created ACTION-280 - Incorporate info on mousewheel event in conjunction with Olli\'s info. [on Doug Schepers - due 2008-06-04]. Doug: May not be able to close a lot of my actions. aemmons: proposal to tighten the wording for double click--this could be low-hanging fruit to add doug: Please all, go through your actions and resolve 2 of them by next week. Here here! doug: implementers should work on items most important to them first. ... who can start looking into making tests for DOM 3 events? carmelo: I can do that. I can possibly auto-generate a lot of the test from the spec. ... will define the test in terms of XML... doug: BitFlash (aemmons) has implemented DOM L3 Events aemmons: SVG has published new tests. I can send to this list tests that overlap DOM L3 Events space. carmelo: what's our time frame for CR? doug: goal is late summer Carmelo: late aug/sep/? doug: I'll have a better idea about a realistic timeframe after I start editing. Carmelo: Planning on leaving last half of June... can send into before then. Doug: should go through section by section and identify how we plan to test. ... will tag "must", "should", etc. to identify testible chunks Carmelo: When can we expect that? doug: possibly in two weeks. Carmelo: Excellent. Travis: Should we consider WebIDL markup? Doug: There are a few risks with taking that now (i.e., WebIDL not done/could destabalize implementations/normative reference?) ... aemmons any suggestions on how to make better progress? aemmons: Our current plan looks good. Small steps. Doug: Olli, same question? olli: We should move forward on key events Doug: Yes, I should add a section to the spec talking about that. I should prioritize this. ... Travis? Travis: Microsoft should weigh-in on the draft once some of these changes are in. onFoo vs. addEventListener Doug: Ian's recent mail indicated that it should be specified more clearly ... however, I want it to be spec'd more generically. a/more clearly/more specific and detailed/ does anyone have link to that Ian's email? [13]http://lists.w3.org/Archives/Public/public-webapi/2008May/0470.h tml [13] http://lists.w3.org/Archives/Public/public-webapi/2008May/0470.html hallvors: when designMode is on, inline event handlers should not run. "Do you have a plan for how to resolve the dependency between event handler DOM attribute processing and the designMode DOM attribute? Also, please remember to deal with the mouseover event's quirk when doing this." hallvors: there might be a security issue if browsers run inline
Re: DOM3 Events Telcon Agenda, 28 May 2008 (Today!!)
Whoops! Got it right in the subject line, but not the body... indeed, 28 May 2008, in a few hours... Doug Schepers wrote (on 5/28/08 10:57 AM): Hi WebAPI Fans- Sorry for the late reminder and lame agenda... I've been traveling a lot lately and I'm still catching up. This is a reminder that we will have a DOM 3 Events telcon today, 16 April. Please reply to public-webapi@w3.org to express regrets if you cannot attend. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Prioritizing For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/28_May_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI -- Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Agenda, 28 May 2008 (Today!!)
Hi WebAPI Fans- Sorry for the late reminder and lame agenda... I've been traveling a lot lately and I'm still catching up. This is a reminder that we will have a DOM 3 Events telcon today, 16 April. Please reply to public-webapi@w3.org to express regrets if you cannot attend. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Prioritizing For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/28_May_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
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() constructor." Again, see Window Object spec. Um, if we're going to be moving the references away from HTML5, could we at least move them to specs that have a chance of actually getting maintained sometime this decade? Obviously, we would only move references if there were a spec that adequately covers the necessary material. If the Window Object spec is not taken up, then clearly it would be inappropriate. We have discussed adding consideration for "event handler DOM attribute" in the DOM3 Events spec, such that a host language can define what that means in its context That would be great, I'd love to offload this part of HTML5. Do you have a plan for how to resolve the dependency between event handler DOM attribute processing and the designMode DOM attribute? Also, please remember to deal with the mouseover event's quirk when doing this. (This seems like a sarcastic and combative reply, for no good reason.) Perhaps I misunderstood the issue. My impression was that Anne was referring to the definition for the "onfoo" event handlers, as stated in the HTML 5.0 spec: "Event handler DOM attributes, on setting, must set the corresponding event handler attribute to their new value, and on getting, must return whatever the current value of the corresponding event handler attribute is (possibly null)." [1] We had discussed, in the DOM3 Events telcons, that we might define the general mechanism for "onfoo" attributes, and their relationship to named events, addEventListener, et al. A host language, such as HTML or SVG, would define the specific event handler attributes appropriate to that language, and provide details about the event. The host language would also cover the particulars of the quirks you mention (so, sorry, but you're stuck with that task). Are you saying that this is not a useful addition to DOM3 Events? Or that you don't think that this adequately covers what is needed for XHR (which seems only to require a definition, from my reading)? I'm interested to hear your feedback on what would be useful for the DOM3 Events spec to say on the matter, beyond (on in contradiction to) what I have already described as the intent. [1] http://www.w3.org/html/wg/html5/#event4 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 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 to do it here... To clarify, we do consider two weeks to be a "wait". Hey, it's only a week more than your original proposal. :) To be honest we're worried that with vendors already working on products that do Geolocation stuff, we may have waited too long already. The sooner we can get people together to discuss this the better. Sure, agreed as a general sentiment. But honestly, is there some time pressure such that an extra week or two will cause serious problems? Vendors have been working in this space for many, many years (especially in Japan) and there are already tons of patents and different approaches... is there some particular issue that has more urgency than is generally known, which you'd care to share? Or more likely, is it a case of momentum (which is certainly enough for me)? In fact, would it be possible to unofficially use this mailing list to discuss proposals while we wait for a formal decision from Chaals on whether Geolocation can (even temporarily) be a WebAPI work item? I don't see why not. I have some meager thoughts on it myself, having spent some time reading up on it recently. FWIW, the resources Google has to offer here aren't locked to working groups, they're locked to work items. So insofar as Google is concerned, it would make no difference if there was one group or ten, we'd have the same amount of resources. The list of deliverables that matters is the total of all the deliverables we're interested in, not the deliverables that a particular working group is tasked to work on. Sure, makes sense. In that light, it's not a burden on Google to work in a different WG, if that's what ends up happening. Having said that, I personally do think it would be wiser to keep all DOM APIs intended for browsers in one working group. That was my initial impetus for proposing it in the draft charter. The confusion we had with two working groups (WebAPI and WAF) led to us merging them, it would be sad to then immediately forget the lesson we had learnt and split work up again. I don't think that's the case here. I, for one, would not want all DOM interface work done in the HTML WG, nor would you want it all done in the SVG WG. There is a sane level of separation of concerns that benefits all parties. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [XHR] Dependencies in XHR
Hi, Anne- Anne van Kesteren wrote (on 5/27/08 7:17 PM): On Wed, 28 May 2008 00:58:45 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote: Vendors have actually requested this. The problem is summarized here: http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html Well... that's not quite a normative reference. :) It was not a reference for that claim, it was a reference for the issue we have. It seems you're suggesting you rather leave it underdefined? No, I want it defined somewhere that there isn't a long wait on a dependency chain. I assume you're not claiming that vendors have asked for the opposite... but I'd be entertained by a link to that reference. :) Seriously, I'm not sure what your point was here... I explained that commercial browser vendors prefer stable, mature specs, without unresolved dependencies... could you clarify why that isn't a concern? We have discussed adding consideration for "event handler DOM attribute" in the DOM3 Events spec, such that a host language can define what that means in its context Again, HTML5 currently has a better definition. Okay, I'll work on that. Great, though note that we reference DOM Level 2 Events currently as that is more stable and does everything XMLHttpRequest requires. Referencing DOM Level 3 Events instead would actually increase the number of instable dependencies. Yes, let's reevaluate that in light of progress on DOM3 Events shortly. Sure. Is there some reason this can't be made generic and left to the host language to define? I'm not sure what you're talking about here. I'm asking for an explanation about the nature of the dependency, vis a vis the necessary level of details in XHR. Note that we also rely on HTML5 for document.innerHTML to define proper serialization of a Document object. Noted. Any proposal on how that can be resolved? Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
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, as the HTML 5.0 specification is a long time from being stable, and this hinders implementation (particularly for vendors who sell their browsers, and must therefore market them). Vendors have actually requested this. The problem is summarized here: http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html Well... that's not quite a normative reference. :) Could you please point to a specific request from a vendor requesting that, rather than to your own email stating the claim? If possible, I would like to identify all dependencies and see if we can remove them, or move them to a smaller, more manageable deliverable. Anne (the editor) has helpfully marked these in the spec, which I applaud as excellent speccing best practice. "The terms origin and event handler DOM attribute are defined by the HTML 5 specification." I believe that "origin" can be defined in the Window Object specification, one of this WG's explicit deliverables. In theory it could, yes. Until someone has done that it seems better for implementations to reference HTML5 as that has a better definition at the moment. I'm not convinced that it's better, since this is an LC draft. That means the WG thinks it's done, and thus that dependency will persist. We have discussed adding consideration for "event handler DOM attribute" in the DOM3 Events spec, such that a host language can define what that means in its context Again, HTML5 currently has a better definition. Okay, I'll work on that. "Objects implementing the Window interface must provide an XMLHttpRequest() constructor." Again, see Window Object spec. The Window Object specification is not being maintained. True. Maybe we need to reprioritize, then. Hey, Browser Implementors! Anyone got an editor to spare? "If there is a Content-Type header which contains a text/html MIME type follow the rules set forth in the HTML 5 specification to determine the character encoding. Let charset be the determined character encoding." This is not, strictly speaking, a dependency. It is a matter of each host language defining its own value for charset. Am I missing something here? It's about determining the character encoding out of a stream of bytes. Sure. Is there some reason this can't be made generic and left to the host language to define? I know that everything in the spec is normative unless marked otherwise, but I just wanted to make sure that none of the references are informative? There is one non-normative reference to HttpOnly cookies in the editor's draft, see: http://dev.w3.org/2006/webapi/XMLHttpRequest/#bibref Okay, thanks. -- Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Proposal to work on Geolocation
Hi, Chaals- Charles McCathieNevile wrote (on 5/27/08 6:34 PM): On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: I could not find record of any such objection in the Advisory Committee mailing list archives, or any record of an official W3C decision on this point. As Team contact, could you please explain who made this decision and on what basis? In which case I presume that someone used their ability to reply to the Team privately instead of being open about what they wanted. This disturbs me a little since it increases the resources and coordination required, IMHO, to do what is a pretty simple piece of work. I think you may be overstating how simple this is, for what it's worth. Exposing coordinates sounds simple, sure... but the security and privacy implications are stickier, as is the legal landscape (both in terms of privacy laws 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, CDF, and WebAPI
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 this new Geolocation WG, and we will expedite its creation as far as we can. Do you know when the AC review for this new WG will start? Not at the moment, but we are looking into it aggressively. I'll keep you posted as we make progress. 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 that there is no scope creep for this API, and that the Geolocation API WG will take a pragmatic, vendor-aware approach, and will act quickly. Sure, the proposal to work in the Web API working group is only intended to be a stop-gap measure while we wait for the wheels of the W3C to turn. It would be sad to delay this while we wait for charters to be written and so forth. 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 to do it here... let me do some digging regarding an appropriate forum at W3C, and get back to you in the next couple of days. In trying to manage expectations, I may have overstated the case, for what it's worth... there hasn't been a formal decision by W3M on this matter, merely a proposal for moving forward effectively, in a manner that best serves all parties. It's not a fait accompli, and I shouldn't have represented it that way. But a new Geolocation API WG seems a sensible solution, on the face of it, and I hope that you'll all support the idea. In the meantime, I've removed the proposed Geolocation API from the WebApps charter. Regarding proposed deliverables in general, I've provided a mechanism for that which I hope will be more agile, while providing due oversight... rather than rechartering the WG, we can merely present a proposal to the AC (based on initial use cases, requirements, research, etc.), and formally add it to our list of deliverables upon approval. I anticipate steady progress in this group, so as we free up resources, we should keep looking forward for useful things that we can work on. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Proposal to work on Geolocation
Hi, Maciej- Maciej Stachowiak wrote (on 5/27/08 5:38 PM): I could not find record of any such objection in the Advisory Committee mailing list archives, or any record of an official W3C decision on this point. As Team contact, could you please explain who made this decision and on what basis? There was a substantive AC Representatives review comment regarding this deliverable, but it was a Team-only comment, and thus there's not much I can say about it. It's not my favorite way of operating, and I wish I could say more, but at the same time, I have to honor Member confidentiality. You can see my original charter proposal here (an earlier draft that includes the Geolocation API): http://www.w3.org/2007/12/WebApps-Charter/WebApp-Charter-2007-proposed http://www.w3.org/2007/12/WebApps-Charter/webapps-deliverables.html I want to reiterate that W3C is *not* dropping the Geolocation API... we merely propose to move it to a dedicated WG. I am ambivalent about this myself: on the one hand, I think there is considerable momentum and interest in doing this in the WebApps WG; on the other, it's a subject that many Members may want to join, who are not necessarily interested in other WebApps deliverables. There is something to be said for having a subject covered exclusively by a dedicated WG with a manageable mailing list load, too. :) Again, we are actively encouraging all interested parties to join this new Geolocation WG, and we will expedite 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, Olli- Olli Pettay wrote (on 5/27/08 4:57 PM): Ian Hickson wrote: Google would like to volunteer some resources to work on a specification to provide a Geolocation API for the Web platform. Sounds great! Yes, we're hoping that Google joins the dedicated Geolocation API WG (when it forms, assuming there's no unforeseen difficulties). Just wondering why WebAPI WG and why not UWA[1]? It would have been logical to work on it in WebApps, since it is a client-side API, but it is admittedly a complicated subject (especially in terms of the IPR), and it won't hurt to have it in a dedicated WG. Obviously, anyone in this WG is also welcome to join the Geolocation API WG. How is this work, or is it, related to DCCI[2]? Only related by subject. There is some work on geolocation in DCCI, but it is more generic, and currently they are working only on the ontology. 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
Hi, Ian- Thanks for this proposal. I strongly believe that W3C should be working on this, and over the last few weeks, Mike Smith and I have been talking to key vendors and other parties to bring together the proper resources to do this, including some discussion at Google. We have identified several interested parties. In fact, I proposed on the WebApps WG charter to add this deliverable. However, the Advisory Committee's review of the charter indicated that the Membership wants this to happen in a dedicated Geolocation API WG. 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 that there is no scope creep for this API, and that the Geolocation API WG will take a pragmatic, vendor-aware approach, and will act quickly. 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 on this? If not, please consider this a formal proposal from us to adopt a Geolocation API as a work item. Since we need broad working group agreement to add a work item, I propose that we set a deadline of June 4th for dissent, though as Chaals always says, positive assent would be preferred. :-) Chaals, could you do the honours of making this formal? Thanks! Background: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0011.html http://code.google.com/p/google-gears/wiki/GeolocationAPI Cheers, --
[XHR] Dependencies in XHR
Hi, WebAPI WG- 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, as the HTML 5.0 specification is a long time from being stable, and this hinders implementation (particularly for vendors who sell their browsers, and must therefore market them). If possible, I would like to identify all dependencies and see if we can remove them, or move them to a smaller, more manageable deliverable. Anne (the editor) has helpfully marked these in the spec, which I applaud as excellent speccing best practice. "The terms origin and event handler DOM attribute are defined by the HTML 5 specification." I believe that "origin" can be defined in the Window Object specification, one of this WG's explicit deliverables. We have discussed adding consideration for "event handler DOM attribute" in the DOM3 Events spec, such that a host language can define what that means in its context "Objects implementing the Window interface must provide an XMLHttpRequest() constructor." Again, see Window Object spec. "If there is a Content-Type header which contains a text/html MIME type follow the rules set forth in the HTML 5 specification to determine the character encoding. Let charset be the determined character encoding." This is not, strictly speaking, a dependency. It is a matter of each host language defining its own value for charset. Am I missing something here? I know 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
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
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.org to express regrets if you cannot attend. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Halvord Steen's "legacy" key events proposal 4. Adding an editor For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/14_May_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI -- Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Agenda, 14 May 2008 (Today!!)
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.org to express regrets if you cannot attend. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Halvord Steen's "legacy" key events proposal 4. Adding an editor For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/14_May_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Mouse wheel feedback
Hi, Ian- Ian Hickson wrote (on 4/17/08 5:52 PM): Yeah, sorry about that -- the mails mostly date from long before the WebAPI group existed. Not at all. I'm glad you did forward them on, and certainly didn't expect you to forward them individually... just meant to encourage individual emails. (Note that your e-mail didn't cc the original commentors, so they may not have seen the replies.) Right, I should have mentioned that I BCC'd all of them (and the WHAT WG list). I don't like getting multiple copies of long threads myself, so I try to trim down recipient lists. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Mouse wheel feedback
them to the equivalent event listener. The current thinking is that we
will state that a host language with attribute-based listeners should do
this.
So, I guess I'd like to see this happen:
| element.addEventListener("mousewheel",
| function (e) { document.title = getWheelDelta(e); },
| true);
|
| function getWheelDelta(e) {
| return e.wheelDeltaY;
| }
> I had planned to propose this at some point but hadn't gotten
> around to it yet.
I'm hoping you aren't referring to the blatantly nonstandard IE event model
shown in Chris Griego's IE example...
I think that we will be providing a clean model going forward, and
anticipate that all the major browser vendors will implement it. This
will be a good step forward for authors (though for legacy browsers they
may wish to use a script library that covers those bases).
On Tue, 21 Jun 2005, Erik Arvidsson wrote:
Mikko Rantalainen wrote:
> I assume that in the future, mouse wheels will not have huge discrete steps
> anymore. So moving towards "px" is required. However, the "page" setting
> will be preferred by some and it cannot be cleanly emulated with a single
> "px" value so we need an unit in addition. Also, I selected word "char"
> instead of "row" so that the same unit name is usable with both X and Y
> axis. I'm not sure if "char" unit should be included, though - it can be
> nicely emulated with "px".
It seems "em" describes row better? However, it might be a bit weird due to
changes in font size depending on where you are in the document. (But I guess
that is already an issue with scrolling Y rows.)
If a unit is added it should probably support the other CSS units as well...
Erik, we don't anticipate adding @units, but if compelling evidence is
presented, we will consider it.
On Tue, 21 Jun 2005, David Hyatt wrote:
We actually have not implemented wheelX and wheelY yet... we just did
wheelDelta. So the other two are open for specifying. :)
David, see above.
On Mon, 25 Jul 2005, Chris Griego wrote:
Just to update this thread, Microsoft's new Virtual Earth uses the
mouse wheel for zooming.
http://virtualearth.msn.com/
Chris, we don't consider fringe cases like that important...
Seriously, yes, the wheel event is not irrevocably yoked to a scroll
event, though it should be the default action.
For SVG in particular, I think such zooming is an important use case.
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
16 Apr 2008
See also: [2]IRC log
[2] http://www.w3.org/2008/04/16-webapi-irc
Attendees
Present
[Microsoft], Doug, aemmons, Carmelo
Regrets
Chair
Doug
Scribe
Travis
Contents
* [3]Topics
1. [4]event iterator proposal
2. [5]wiki access
3. [6]key events and key identifiers
* [7]Summary of Action Items
_
Date: 16 April 2008
[8]http://www.w3.org/2008/webapps/wiki/D3E_Scraps
[8] http://www.w3.org/2008/webapps/wiki/D3E_Scraps
script: Travis
scribe: Travis
scribeNick: IRC Travis
AE: Meeting has started
... planning next meeting.
shepazu: Carmelo have you started testing keyboard related
stuff?
Carmelo: have made keycode/charcode progress...
aemmons: Let's chat about event iterator discussion from
the list
... much of discussion was around use-cases...
event iterator proposal
mjs, are you interested in discussing event iterator?
shepazu: I don't have much to add besides what I said already,
and wanting to hear the use cases that justify it
mjs, ok
those use cases would be better presented in email, but I'd be
happy to hear them by phone too
[9]http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.ht
ml
[9]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.html
[10]http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.h
tml
[10]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.html
shepazu: so please let me know if I can contribute anything
useful, and I'll gladly call in for that topic
ok, thanks
aemmons: previous proposal for hasEventListener
shepazu: less usefull in my opinion
aemmons: mjs wants to really discuss if we need it at all
(use-case analysis)
shepazu: I find strong case for this iterator--others don't
seem to think so.
shepazu: It's potentially problematic for some UA's because
the use the API internally for adding listeners...
... we could just get DOM events out and then add the
iterator later (in its own spec)
... don't want to delay DOM3 Events for this. Rather settle
on keyevents, etc. and publish this spec...
unless can resolve iterator open issue quickly.
Travis: I agree generally with what is said about not
delaying...
... unexpected resistence.
shepazu: App internal use, seems easy to hide events...
... for extensions in FF, may be more complicated
Travis: the page may not want to see stuff added by
extensions.
shepazu: Rather UI doesn't want to expose that to whomever
controls the page.
Travis: possible security/privacy issue for scripted
extensions. Maybe a profiling problem.
shepazu: problem could also exist for a framework/mashup.
Travis: frameworks want to control enumeration
Travis: Almost requires the addEventListener api to specify
whether an event should be enumerated.
shepazu: It complicates scenarios.
... Travis, please gather use-cases, reqs., etc., to
continue to drive conversation.
... continue out of context of DOM3 Events (so as to not
block progress).
Travis: I think that's fine.
aemmons: It makes a lot of sense to identify the use cases.
shepazu: anyone opposed to this?
Resolution: Don't add event iterators in DOM3 Events,
continue research for a later spec
Rationale: Don't want to delay DOM3 Events.
Travis: mjs what do you think of this?
mjs, are you fine with this resolution?
I am fine with not including it for now
I do think we should still add it later if there is a use case
Travis: addEventListener('click', fCallback, false, 'don't
enumerate'); :)
for future reference
wiki access
shepazu: Proceedure to get wiki access
... 1- make an account.
... 2 - tell shepazu
... 3 - he will grant access if the stars align
[11]http://www.w3.org/2008/webapps/wiki/Main_Page
[11] http://www.w3.org/2008/webapps/wiki/Main_Page
key events and key identifiers
[12]http://www.w3.org/2008/webapps/wiki/Key_Identifiers
[12] http://www.w3.org/2008/webapps/wiki/Key_Identifiers
shepazu: I added those 2 things for review
... that link defines key identifiers (by Cameron)
shepazu: I think we should add this to the spec
[13]http://www.w3.org/2008/webapps/wiki/D3E_Scraps
[13] http://www.w3.org/2008/webapps/wiki/D3E_Scraps
shepazu: we need to send mail to folks t
DOM3 Events Telcon Agenda, 16 April 2008 (Today!!)
Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon today, 16 April. Please reply to public-webapi@w3.org to express regrets if you cannot attend. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Wiki Access 4. Event Iterator: discussion on email list 5. Keyboard events and key identifiers: implementation reports 6. keyCode and charCode: test results For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/16_Apr_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [DOML3Events] ACTION-267 Proposal for event iterator
Hi, Jonas- Jonas Sicking wrote (on 4/14/08 5:58 PM): Like Boris points out, there is no need to expose debugging APIs to web pages. Browsers can expose those thorough internal APIs to their tools. Actually, I've seen Web apps that allow creation and debugging of content, and I think that's a perfectly legitimate use case. I would like to have this list of event listeners available. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
[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: http://www.w3.org/TR/2008/WD-DOM-Bindings-20080410/ Latest Version: http://www.w3.org/TR/DOM-Bindings/ Regards, Jules
Minutes, DOM3 Events Telcon, 09 April 2008
o find one behavior that works well and
specify that
(and one that has been implemented cross-OS would be
insightful)
DS: Do not think we'll find one
... Regarding the offhand comment above, I can think of multi-modal
situations where it is useful
... If I press A key and P key at the same time, may have different
meaning
TL: You could write it in script but have no way to know if a key
was released
DS: perhaps key state information with each event would be useful in
this scenario
... Not compatible with DOM 2 events, but interesting
Agree--put keyboard use cases in the spec.
ACTION: Doug to place keyboard use cases into the wiki
[recorded in
[14]http://www.w3.org/2008/04/09-webapi-minutes.html#action02]
Created ACTION-272 - Place keyboard use cases into the
wiki [on Doug Schepers - due 2008-04-16].
anne distracts the call via SuperMario.
ACTION: Andrewe to add keyboard use cases into the spec
[recorded in
[15]http://www.w3.org/2008/04/09-webapi-minutes.html#action03]
Sorry, couldn't find user - Andrewe
ACTION: AEmmons to add keyboard use cases into the spec
[recorded in
[16]http://www.w3.org/2008/04/09-webapi-minutes.html#action04]
Created ACTION-273 - Add keyboard use cases into the spec
[on Andrew Emmons - due 2008-04-16].
keyCode and charCode
DS: OP, how differnt is keyCode and charCode in Moz vs IE?
OP: IE has only keyCode I think
... Mozilla uses charCode only for keyPress
... I think Safari uses a mixture of both
... Opera reports very different key codes, at least on windows
DS: Is MS intending to implement keyCode and charCode?
TL: I think keyIndenifiers is the superset
... Move from charCode and keyCode in the long run
... Would just assume not do it
AE: I agree
DS: Is it useful to define keyCode and charCode in terms of
keyIdentifiers?
... Chart of keyIndeitifers, keyCode and charCode that are normally
associated with it
TL: Sounds great
... Call out differences between browsers
OP: Should be ok, non-normative is better
ACTION: Doug to start keyIdentifiers chart on the wiki for
various charCode and keyCode values and browsers [recorded in
[17]http://www.w3.org/2008/04/09-webapi-minutes.html#action05]
Created ACTION-274 - Start keyIdentifiers chart on the
wiki for various charCode and keyCode values and browsers [on Doug
Schepers - due 2008-04-16].
DS: Any other issues with Dom3 Ev we need to solve?
TL: I would like a return value for add/remove event listener
OP: Why?
... Not backward compatibile also
Thanks all for the feedback!
Summary of Action Items
[NEW] ACTION: AEmmons to add keyboard use cases into the spec
[recorded in
[18]http://www.w3.org/2008/04/09-webapi-minutes.html#action04]
[NEW] ACTION: Andrewe to add keyboard use cases into the spec
[recorded in
[19]http://www.w3.org/2008/04/09-webapi-minutes.html#action03]
[NEW] ACTION: Doug to place keyboard use cases into the wiki
[recorded in
[20]http://www.w3.org/2008/04/09-webapi-minutes.html#action02]
[NEW] ACTION: Doug to start keyIdentifiers chart on the wiki for
various charCode and keyCode values and browsers [recorded in
[21]http://www.w3.org/2008/04/09-webapi-minutes.html#action05]
[NEW] ACTION: Travis to send revised model to the mailing list
[recorded in
[22]http://www.w3.org/2008/04/09-webapi-minutes.html#action01]
[End of minutes]
_
Minutes formatted by David Booth's [23]scribe.perl version 1.133
([24]CVS log)
$Date: 2008/04/09 19:54:06 $
_
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[24] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [25]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/-shit/-shift/
Found Scribe: Andrew
Found ScribeNick: aemmons
Default Present: [Microsoft], aemmons, Doug, Carmelo, smaug, anne, Trav
is, Anne_van_Kesteren
Present: [Microsoft] aemmons Doug Carmelo smaug anne Travis Anne_van_Ke
steren
Agenda: [26]http://www.w3.org/2008/webapps/wiki/9_Apr_2008
Found Date: 09 Apr 2008
Guessing minutes URL: [27]http://www.w3.org/2008/04/09-webapi-minutes.h
tml
People with action items: aemmons andrewe doug travis
[26] http://www.w3.org/2008/webapps/wiki/9_Apr_2008
[27] http://www.w3.org/2008/04/09-webapi-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
End of [28]scribe.perl diagnostic output]
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Re: Some key event handling issues of interest
Hi, Olli- Olli Pettay wrote (on 4/9/08 7:57 AM): Specifying default handling is important, sure. Some default handling is defined in HTML5/WebForms2 and that is perhaps the right place for the rest of the default handling issues. Yes, the host language should define this level of default handling. One important question is that what is the target for DOM Level 3 Events? Is it only for browsers? If yes, then defining default handling in it makes lots of sense. But I'm not at all sure the browsers are the only ones to implement DOM 3 Events. Correct, they aren't. This is something to remember also when specifying for example mousewheel handling (the latest proposal isn't browser-specific at all, IMO) and key event flow/handling. Yes. About key event flow: I think if or when defining key event flow, it must be made clear that event handlers (for example in web page 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: Some key event handling issues of interest
Hi, Alexey- This is indeed very valuable information. A few comments inline... Alexey Proskuryakov wrote (on 4/3/08 5:12 AM): - Default handlers are different for different elements. E.g. a space bar results in a space inserted from keypress default handler in an editable area; a button highlighted from keydown and a click event dispatched from keyup, a pop-up button menu displayed from keypress, or the page being scrolled down from a top-level keypress handler if the event bubbled without having been handled otherwise. Default handlers should be defined by the host language (for example, HTML or SVG). I don't think that SVG will actually define default handlers for any keys, other than specialized zoom or pan keys (though it's conceivable that the arrow keys might be overloaded for this); HTML, however, has a lot of controls and expected behaviors for them. Sometimes, these differences are arbitrary (e.g. there is no technical reason for a pop-up button to necessarily display its menu from keypress, not keydown), but they are important for compatibility. Clearly, this is mostly an issue with highly overloaded keys, such as Space, Enter, Tab, Backspace, or arrow keys. Yup. Again, that's out of scope for DOM3 Events, but it should be made clear that a host language should define these default handlers, and how to do it. - Interaction of DOM and browser chrome has to be considered. Keyboard shortcuts (such as Ctrl+F or Alt+F4 on Windows) are handled after DOM event dispatch, and some of them can be prevented, but not all. Similarly, the browser chrome can perform an action that disrupts normal event flow. E.g., Ctrl+F moves focus to a search window, and thus a keydown event is not followed with a keyup one. Yes, we've already resolved that we will explicitly warn authors that the OS and the browser may not pass all events through to the DOM/script context. - Access keys are handled after keydown event dispatch, but they cannot be prevented. This behavior has been one of the most problematic parts for us because of a conflict with platform-supplied editing shortcuts on Mac OS X (such as Ctrl+A == move to beginning of line). I believe some other vendors have considered using another modifier combination for access keys (e.g. Ctrl+Shift), perhaps we should do the same. I think it would be worthwhile for us to consider hotkeys/accesskeys/etc. in the WebApps context, whether it is specified in DOM3 Events or not. Maciej put forward an interesting proposal in WebAPI or HTML... I'll hunt it down. - On Windows, the underlying platform provides two events for keystrokes (plus variations), one for physical key (WM_KEYDOWN == keydown), and another for a character that it corresponds to (WM_CHAR == keypress). It is hard, or maybe even impossible, to second-guess which event comes when, because there are cases where they occur almost independently. Ouch. Perhaps the emulation layer, if we mandate one, will simply have to have some known flaws. We discussed making an informative appendix with some similar known issues. So, we have removed physical key information (keyIdentifier, keyLocation) from keypress events. For compatibility, they still have keyCode, but it is equal to charCode. Since keypress has not been previously defined in DOM3 Events, either behavior is compliant :) Under the circumstances, that seems reasonable. If both IE and Safari (at least) have the same charCode and keyCode charts, publishing those as an informative list seems to have legacy value. - Preventing default handling of keydown has no effect on IME input; keypress is not dispatched. Also, keyCode is set to 229 (VK_PROCESSKEY) in the keydown event. This was done just to provide IE compatibility, I do not have any other support for this rather counter-intuitive behavior. Let's discuss this during the telcon. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Agenda, 09 April 2008 (Today!!)
Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon today, 09 April. The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. Keyboard events and key identifiers: implementation reports 4. keyCode and charCode For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/9_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
Hi, Bjoern- Bjoern Hoehrmann wrote (on 4/3/08 6:30 PM): * Simon Pieters wrote: The result of (2) probably also means that there's both childElementCount and childElements.length to do the same. If the SVG Working Group wants the count but not the NodeList, you end up with that either way. 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
Doug: IPhone doesn't have typical UI. Rationale for longpress on this phone is not very clear. ... Rationale on mobile is that keys are limited, and keys do different things if pressed for a long time. ... From IPhone perspective, (and more interesting) is how softkeys are implemented. Alexey: Don't know much about IPhone... Doug: Goal is probably to emulate MacOS. ... All feel free to review items listed above. [19]http://www.w3.org/2008/webapps/wiki/Joystick [19] http://www.w3.org/2008/webapps/wiki/Joystick Doug: mobile guys requested joystick/mobile keypad location (similar) ... Pull out your phone and observe 4-way/8-way toggle button. ... Originally, requested specific key identifiers (Joystick-up, etc.) KeyboardEvent.keyLocation Doug: However, after discussion, best idea was to use up/down/left/right keys, and use a keyboard event keylocation... DOM_KEY_LOCATION_MOBILE Alexey: Use same event interface for joystick/mousewheel? not Alexey... Doug: Don't think a joystick on a mobile phone, is quite the same as what I was thinking... ... Probably using arrow keys and keyrepeat. ... But is probably device dependent. Travis: Joystick events may be out-of-scope...(in tranditional joystick sense) Doug: Suspects that arrow keys would work just fine on mobile... Travis: Are there diagonal arrow keys (for an 8-way direction keypad?) Doug: Short answer: yes. [20]http://www.w3.org/TR/DOM-Level-3-Events/keyset.html#KeySet-Set [20] http://www.w3.org/TR/DOM-Level-3-Events/keyset.html#KeySet-Set Hm. I see "Left", etc., Doug: I added them though... not in the above link yet. ... Some keyboards have diagonals. ... I will make the full list of keyboard identifiers. ... Alexey, what is the identifier for the Apple key? Alexey: It reports as the Meta key. Travis: Windows keyboards usually have a 'righ-click' or context menu key. (Is that supported?) [21]http://people.w3.org/rishida/utils/keyevents/ [21] http://people.w3.org/rishida/utils/keyevents/ Doug: Can't wait for key identifiers. Travis: returns the keycode 91 '[' Doug: Don't think mobile implementers really needed a joystick event. ... I'm expecting some feedback on that. ... (Mobile guys could use arrow keys + key location=mobile key pad) ... I want to write a new spec for 'pen' events. (for tablets, etc.) ... Something like an 'alternate devices' spec that maps to events and defines new ones. ... I think having the up/down + key location is fine for mobile. ... Ollie, do you think this is OK? Ollie: yes. Doug: Reviewing action items... [22]http://www.w3.org/2006/webapi/track/ [22] http://www.w3.org/2006/webapi/track/ ACTION: Carmelo to cross tests keyup keydown and keypress [recorded in [23]http://www.w3.org/2008/04/02-webapi-minutes.html#action02] Created ACTION-269 - Cross tests keyup keydown and keypress [on Carmelo Montanez - due 2008-04-09]. ACTION: document Key Identifiers on wiki [recorded in [24]http://www.w3.org/2008/04/02-webapi-minutes.html#action03] Sorry, couldn't find user - document ACTION: schepers to document Key Identifiers on wiki [recorded in [25]http://www.w3.org/2008/04/02-webapi-minutes.html#action04] 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] ACTION: document Key Identifiers on wiki [recorded in [27]http://www.w3.org/2008/04/02-webapi-minutes.html#action03] [NEW] ACTION: Item to To Carmelo to cross tests keyup keydown and keypress as described on [recorded in [28]http://www.w3.org/2008/04/02-webapi-minutes.html#action01] [NEW] ACTION: schepers to document Key Identifiers on wiki [recorded in [29]http://www.w3.org/2008/04/02-webapi-minutes.html#action04] [End of minutes] _ Minutes formatted by David Booth's [30]scribe.perl version 1.133 ([31]CVS log) $Date: 2008/04/02 19:58:01 $ _ [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [31] http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at [32]http://dev.w3.org/cvsweb/~checkout~/2002 /scribe/ [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Allie/Alexey/ Found Scribe: Carm
DOM3 Events Telcon Agenda, 02 April 2008 (Tomorrow!!)
Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon tomorrow, 02 April. The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] NOTE: Because of Daylight Savings Time, the times may have adjusted in your locality. The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. key event sequence model: discussion (State Chart vs. Default Handlers, Fight!) 4. Keyboard events and key identifiers: implementation reports 5. Mobile-specific events: ISSUE-51 (I will try to have concrete proposals to discuss on the wiki) For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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
Hi, Henri-
Henri Sivonen wrote (on 4/1/08 10:36 AM):
c. just remove the childElementCount attribute
It seems to me that checking if an element has *any* element children is
going to be the most common use case for childElementCount and that can
be checked by checking if firstElementChild is null.
I very much like the idea having firstElementChild, lastElementChild,
previousElementSibling, nextElementSibling. In particular, I think using
var e = p.firstElementChild;
while (e != null) {
...
e = e.nextElementChild
}
to iterate over child elements is a cleaner idiom than introducing an
index that isn't used for random access but only for forward iteration.
How often do people pick a single child by index (with a number know a
priori) instead of iterating over children and testing each one for an
interesting trait?
Again, childElementCount is not intended for index access. It's
intended as a preprocessing convenience for script authors. This saves
the costly DOM operation of having to process the loop twice in script,
once to count the elements, and another to set values based on the total
number of elements.
As an SVG author, this is something I've needed many times.
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] access to element by index
Hi, Daniel- Daniel Glazman wrote (on 3/28/08 4:24 PM): Doug Schepers wrote: The question is, can we revisit it in light of existing implementations in JSR-280 and in deployed code in mobile devices? At the very least, we would have to leave 'childElementCount', and add an additional nodeList (be it static or live). At that point, yes, it does seem like it might be getting a little heavy, and may also lead to non-interoperable content. I will liaison with JSR and with the SVG WG to see how they feel about this decision. I can see both sides, so I'll abide by the will of the WebAPI WG and the dependent groups. Let me summarize that : vendors implemented something that is not even a CR yet, so it's an-risk document, and you should take that as an argument against changes ??? My answer is clearly NO. Drafts are well DRAFTS. Their introduction explicitely states it's not recommended to assume the specification is firm and will remain as is. I agree that any implementation takes on risks when it does not respect the instability of a draft document. In fact, I just said so. [1] But let's be realistic, as well. Implementation schedules and market pressures also play into the big picture; the standards process, for all its benefits, is known to be slow. So we're faced with a situation in which a core set of functionality and design goals were established, and a feature set specified; it then left the original spec it started in, and was generalized to be more broadly applicable as its own spec. It went through lengthy review by authors and implementors, and was thought to be stable; the very issue you point out was discussed and decided against. This whole thing took place over the course of 3 or 4 years. I think in this case, the implementors were not unreasonable to jump the gun a bit. And regardless of whether what the implementors did is justifiable, if content is created that uses the nodeList, it will be incompatible with existing deployed implementations, which I think we can all agree defeats the point of standards. It's also disrespectful to the implementors who proposed, supported, and implemented this spec. Speaking of jumping the gun, I haven't yet heard back from the implementors or the WGs in question, so I'm asking you to exercise some patience for a formal response to your comment. It's possible that when all is said and done, there may be a favorable judgment regarding adding a nodeList. If you would please provide some detailed and concrete use cases where you think that your proposed functionality is needed, that would certainly make for a stronger case. I also think it's within scope for us to examine whether this functionality should go into the Selectors API spec instead. [1] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0231.html Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] access to element by index
Hi, Daniel- Daniel Glazman wrote (on 3/28/08 3:15 PM): Doug Schepers wrote: Since Selectors API is meant to be a more comprehensive API than Element Traversal, I would expect it to be able to deal with this more general use case Daniel mentions, and personally would prefer to increase the comprehensive functionality of that spec over Element Traversal, which is meant to be more lightweight. Ah. Adding NodeListchildElements; is not lightweight ? It's incredibly simple, totally coherent with what the DOM already offers, and web authors are perfectly used to NodeList. I'm open to changing it, since as I said, I introduced that functionality in an earlier version of the spec, but removed it because of negative feedback, primarily from Björn Höhrmann and Maciej Stachowiak. I had other feedback from Boris Zbarsky and Stewart Brodie that said linked lists could be implemented efficiently with clever coding, but I took that as weaker advocacy than the stronger objections. I'll also note that while Stewart and Boris are active contributors to public-webapi, Björn and Maciej were WG members, and that played a small factor in my decision. Maybe that was a bad design choice. The question is, can we revisit it in light of existing implementations in JSR-280 and in deployed code in mobile devices? At the very least, we would have to leave 'childElementCount', and add an additional nodeList (be it static or live). At that point, yes, it does seem like it might be getting a little heavy, and may also lead to non-interoperable content. I will liaison with JSR and with the SVG WG to see how they feel about this decision. I can see both sides, so I'll abide by the will of the WebAPI WG and the dependent groups. [1] http://lists.w3.org/Archives/Public/public-webapi/2007Oct/0050.html 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 means. I would just like to point out, from my perspective as an implementor, that implementing this as a nodelist would have taken all of 15 minutes of programming time. Implementing the specification as written, while having acceptable performance on traversal, will take a good bit more work, and either a lot more complexity or additional space used by every single Element in the DOM. I realize that this is due to the fact that I'm working with an implementation that already has a generic NodeList implementation... Nevertheless, the issue is there. I have the feeling that I already mentioned this in the past, so I assume it's been considered in making the decision that the linked-list-only API is the one to use, but I wanted to mention it in case I hadn't before. Yes, you did, and I pointed out that not all implementations have existing nodeList implementations, and that one of the design goals was to work with mobile UAs that don't already support nodeList (live or static). [1] After some discussion in the same thread, I then put the direct question to the list as to whether or not to include a nodeList [2], and the only reply I got was from Maciej, in support of removing it. [3] This was last April, and the spec has not changed appreciably since then, so I assumed the issue was closed, and that you appreciated the design goal. P.S. Oddly enough, in typical DOM authoring authors use index-based of childNodes a _lot_ more than the linked-list accessors Has anyone looked into why? My guess is that undifferentiated navigation to any node type is simply not that useful, which is why Element Traversal was made. Also, without knowing the number of child nodes of the target type, there are some pre-processing operations that aren't easily done, so again it's less useful; by the time you bother getting a nodeList to find out the number of children, you may as well iterate through the list. Also, it may be that casual authors simply don't know about those accessors, since looping structures are themselves so widely used. [1] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html [2] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0012.html [3] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0013.html Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] access to element by index
Hi, Daniel-
Daniel Glazman wrote (on 3/28/08 1:55 PM):
Boris Zbarsky wrote:
Daniel Glazman wrote:
myFooElement.querySelector("*:nth-child(3)") does NOT work since
there can be another 3rd child in traversal order before the
3rd child of myFooElement.
Being devil's advocate for a sec, having a :scope pseudo-class or some
such would help here, right?
myFooElement.querySelector(":scope > :nth-child(3)")
That would require an addition to the Selectors spec and that comes
too late in the process of that spec.
Selectors API is at the same point in the process as Element Traversal,
Last Call; while the official Selectors LC period is over, there's been
no WG decision about publication as CR.
Since Selectors API is meant to be a more comprehensive API than Element
Traversal, I would expect it to be able to deal with this more general
use case Daniel mentions, and personally would prefer to increase the
comprehensive functionality of that spec over Element Traversal, which
is meant to be more lightweight.
I would recommend changing
the Selectors API on document.querySelector and
document.querySelectorAll to allow a second argument being a node or
null. If it's a node, then the results simulate your :scope > SELEC
above, the scope being that node and SEL being the selector passed as
the 1st argument. If it's null, well, it does what it does today.
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] access to element by index
Hi, Daniel-
Daniel Glazman wrote (on 3/28/08 12:55 PM):
Ok, guys, let's see it that way : we have one given element and we
want to find its 3rd element child. Very simple and common query,
right ?
I'm actually not sure. How often do authors want to get the third child
without knowing anything more about it than that it's an element?
Iterating through the kids (by means of ET or '.childNodes') gives you
much more context information (what type of element it is, what it's
bbox is, whether or not it has text/child content, etc.). Not trying to
be a pain, but can you identify a concrete use case?
2. using Selectors API :
myFooElement.querySelector("*:nth-child(3)") does NOT work since
there can be another 3rd child in traversal order before the
3rd child of myFooElement. I have no way of querying the 3rd child
of myFooElement alone if myFooElement has no ID, no class, nothing
since the :root pseudo-class does NOT apply to myFooElement in such
a query but still represents the root of the document.
Querying :first-child+*+* does not work either for the same reason,
there can be a 3rd child deep in the subtree being before the 3rd
child of myFooElement in traversal order of the document...
This is a limitation of the Selectors API I detected long ago.
Mentioned it a few times, too.
Couldn't you do this?
var kids = myFooElement.querySelectorAll("*");
var middleChild = kids.item( 3 ); //or kids[ 3 ];
I don't want to turn 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, Jonas- I addressed Daniel's comments in another email, but I wanted to address your additional points specifically. Jonas Sicking wrote (on 3/28/08 12:23 PM): I agree with Daniel here. I'm not really following your argument. Are we trying to keep compatibility with the SVG spec here? Is the interface as designed now 100% compatible with SVG? SVG dropped Element Traversal from its spec, and gave it to the WebAPI WG to spec out, so it only references it, thus there can be no incompatibilities per spec. In pragmatic terms, UAs, libraries, and related JSRs which focus on SVG Tiny 1.2 have already adapted to the only change I introduced, 'childElementCount'. So, there are no incompatibilities by implementation either. (See my other email for the wisdom of waiting for spec stability.) If we're not 100% compatible with SVG, why would they oppose an improvement like the suggested one? Indeed, I did introduce a nodeList in an earlier version of the spec to add this functionality, but was convinced to remove it by general consensus of this WG and by merits of argument. There are pros and cons to each approach, but within the scope of the larger context of available Web APIs, I think the more compelling argument is to leave the spec as is. If we don't provide a way to grab elements by index I don't really see a purpose of the childElementCount attribute. The use for 'childElementCount' is laid out in the spec, most explicitly in one of the examples [1], and in the introduction: "The DOM Level 1 Node interface also defines the childNodes attribute, which is a live list of all child nodes of the node; the childNodes list has a length attribute to expose the total number of child nodes of all nodeTypes, useful for preprocessing operations and calculations before, or instead of, looping through the child nodes. The ElementTraversal interface has a similar attribute, childElementCount, that reports only the number of Element nodes, which is often what is desired for such operations." Though the example uses HTML, this is really a more common scenario in SVG, where more of the content is element-based, rather than text-based. 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 means. [1] http://www.w3.org/TR/ElementTraversal/#example-3.2 Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] access to element by index
Hi, Daniel- I definitely see your use case and think it would be a valuable addition, but I agree with Björn's characterization. Part of the rationale with not having a nodeList was to make this a very lightweight interface, and that was reinforced through comments on this list. I had initially introduced a nodeList in this incarnation of the spec, but received negative feedback about it, which is why I did the next best thing (from my perspective) in adding 'childElementCount' instead. Björn is also correct that the Selectors API spec will add that kind of discrete itemized access to browsers, so I am reluctant to reintroduce a nodeList to Element Traversal. There are also existing implementations that follow the spec as it is, so while that's an unfortunate situation --implementations should really only be shipped in production code after the spec is considered stable, in CR-- it is contraindicative of so fundamental a change. It would also necessitate another LC period. However, I am merely the editor, so I leave it to the WG to decide. On the other hand, if you're satisfied that your desired functionality will be otherwise available via the Selectors API or XPath, as Björn points out, then you could withdraw your comment. Please let me know your preference. Bjoern Hoehrmann wrote (on 3/28/08 11:47 AM): * Daniel Glazman wrote: 1. congrats for this spec, I love it ; I can't count how many times in page or chrome script I am filtering out nodes that are not element nodes. 2. the ElementTraversal interface has a |childElementCount| attribute but misses access to an individual childElement based on its index. That would be really useful. Two solutions here : a. you remove the childElementCount attribute in favor of a readonly attribute NodeListchildElements; and that NodeList has all we need It was the SVG Working Group that originally came up with the interface and they, as I understand it, decided against having any NodeList in the SVG Tiny 1.2 DOM. They rather introduced the interface to allow imple- mentations to discard some nodes like comments and text nodes with only white space while keeping compatibility with implementations that keep them. I would imagine they would be unhappy with such a change. b. you add Nodeitem(in unsigned long index); but that is not really consistent with the existing way of querying list of nodes. My very strong preference goes to solution a. At the least you would need a different name as this would go on all element nodes and you would probably run into name clashes quickly, and confuse authors (NodeList.item vs. Element.item for example). However, you could also just use XPath, or Selectors, or one of the many other methods for this particular case, I don't think this addition is needed. -- Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Keyflow
Hi, WebAPI fans- This past week in the DOM3 Events telcon, we discussed the order of key events for the DOM3 Events specification, with attention paid to IME. We are hoping to model the most platform-independent event order, and are seeking active feedback from Apple, Microsoft, Mozilla, Opera, and anyone else with experience in implementing keyboard events (especially with regards to internationalization). I've made a trial schematic to get us started [1]. I've also modeled it in Graphviz, and I've included the Dot format file here (attached). Graphviz is free open source 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 DOM3Events-keyflow.dot Description: Binary data
Minutes, DOM3 Events Telcon, 26 March 2008
Hi, WebAPI Fans- The minutes of the DOM3 Events Telcon Agenda, 26 March 2008 can be found at: http://www.w3.org/2008/03/26-webapi-minutes.html Or as textInput below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 26 Mar 2008 [2]Agenda [2] http://www.w3.org/2008/webapps/wiki/26_Mar_2008 See also: [3]IRC log [3] http://www.w3.org/2008/03/26-webapi-irc Attendees Present Doug, Carmelo, aemmons, [Microsoft], smaug, Travis, +1.408.996. Regrets Chair Schepers Scribe Olli Pettay Contents * [4]Topics 1. [5]key event sequence model: 2. [6]Issue/Action review 3. [7]HTML4 vs DOM events 4. [8]Keyflow 5. [9]cmd +/- * [10]Summary of Action Items _ Date: 26 March 2008 Zakim: who is on the phone Scribe: Olli Pettay scribeNick: smaug key event sequence model: [11]http://www.w3.org/2008/webapps/wiki/Key_event_order#Proposed_Ord er_for_Key-Related_Events [11] http://www.w3.org/2008/webapps/wiki/Key_event_order#Proposed_Order_for_Key-Related_Events [12]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-k eyflow.svg [12] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg DS: (the diagram does look right on firefox) ... going through the diagram TL: will look how this work on IE DS: everybody should look how "their" browser work ... I'm happy modify the diagram some more ... the middle textInput, currently there isn't repeat in DOM. We should probably add it ... repeat="true" might only happen on character keys ... not sure where IME should go Issue/Action review [13]http://www.w3.org/2005/06/tracker/webapi/products/2 [13] http://www.w3.org/2005/06/tracker/webapi/products/2 [14]http://www.w3.org/2005/06/tracker/webapi/users/41 [14] http://www.w3.org/2005/06/tracker/webapi/users/41 DS: going through the actions OP: I don't think I can take actions officially yet [15]http://www.w3.org/2005/06/tracker/webapi/users/37 [15] http://www.w3.org/2005/06/tracker/webapi/users/37 DS: TL any progress on that action? I'll try to find my old test and post it. [16]http://www.w3.org/2005/06/tracker/webapi/users/46 [16] http://www.w3.org/2005/06/tracker/webapi/users/46 [17]http://www.w3.org/2005/06/tracker/webapi/users/44 [17] http://www.w3.org/2005/06/tracker/webapi/users/44 AE: I was going to work on mousewheel event today but got some email from smaug about that [18]http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0202.h tml [18] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0202.html DS: reviewing the email ... It shouldn't be hard to test if wheelDelta is zero ... the new event wouldn't break existing pages the previous proposal [19]http://lists.w3.org/Archives/Public/public-webapi/2006May/0029.h tml [19] http://lists.w3.org/Archives/Public/public-webapi/2006May/0029.html from apple TL: [20]http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0202.h tml might be the best compromise ... but need to specify the order of the events [20] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0202.html DS: everybody seem to be ok with the wheel event ... I'll modify the wheel event proposal CM: it could help SVg DS: we're getting rid of the mega-multi-mousewheel HTML4 vs DOM events TL: what the HTML4 event listener behaviour is vs DOM event listeners OP: we should look at HTML5 hihi heyeh sprry for being late very sprry indeed :p gonna call in? [21]http://www.whatwg.org/specs/web-apps/current-work/#event3 [21] http://www.whatwg.org/specs/web-apps/current-work/#event3 victory HTML5 on events: [22]http://www.w3.org/html/wg/html5/#events [22] http://www.w3.org/html/wg/html5/#events TL: IE keeps separete list for HTML event listeners "inline handler" TL: html event listeners fires first "When scripting is enabled, all event handler attributes on an element, whether set to null or to a function, must be registered as event listeners on the element, as if the addEventListenerNS() method on the Element object's EventTarget interface had been invoked when the element was created, with the event type (type argument) equal to the type described for the event handler attribute in the list above, the namespace (namespaceURI argument) set to null, TL: could set listener using html attribute and then remove using removeEventListener? DS: SVG has the same issue ... TL, are you willing to change how IE does t
DOM3 Events Telcon Agenda, 26 March 2008 (Tomorrow!!)
Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon tomorrow, 26 March. The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] NOTE: Because of Daylight Savings Time, the times will be different for anyone living outside North America. The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. key event sequence model: graph model 4. Keyboard events and key identifiers: review and discussion 5. cmd +/- ISSUE-79 6. mobile-specific events ISSUE-51 For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/25_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Keyboard Review Telcon
Hi, Web API fans- We will be holding a telcon next Wednesday to review and discuss the keyboard aspects of the DOM3 Events spec, specifically the Keyboard events and key identifiers [1] and Text events types [2]. There is good work in these, but they are not yet complete. I would appreciate if everyone, specifically implementors, read through these sections of the spec and come prepared next week with open questions, criticism, and preferably proposed solutions. [1] http://www.w3.org/TR/DOM-Level-3-Events/keyset.html [2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-TextEvents-Interfaces Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Minutes: DOM3 Events Telcon, 19 March 2008
of 0
DS: That is correct, content out there will have to check that the
wheel delta is not zero
if ( !evt.wheelDeltaX && 0 == evt.wheelDelta) {...}
AE: Having two events makes content creation harder
TL: Generally speaking the fewer events fired the faster performance
can be
[18]http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0169.h
tml
[18]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0169.html
"For existing apps, it doesn't seem like it would be that
hard to short-circuit the mousewheel event handlers to check for a
non-zero wheelDelta before continuing with the code."
DS: If you look at any code that deals with the wheel, their all
using something different
... (reads various events)
... I htink it would be great is we supplied a 'patch' library
... Here is the old way, here is the new way, here is the patch
between
TL: Examples, non-normative
Key event sequence model
[19]http://www.w3.org/2008/webapps/wiki/Key_event_order
[19] http://www.w3.org/2008/webapps/wiki/Key_event_order
TL: Doug and I took a look at the proposal, an informative section
to describe typical flow of key events
... Tried to express in a linear progression
... Due to complications like keyRepeat, IME editors, etc,
... thought it would be better to express in a state transition
diagram
DS: Talked a little about this last week
TL: I like having an example proposal out there - is a should
requirement with an emulation layer for example to achieve it
DS: I would go so far as to say it would be normative
... should for emulation layer
... May just give events in device sequence
... I will draw up state chart diagram
TL: I like having it clearly specified
... Much easier to get it right if it is clear and specific
OP
OP: I like this as well
ACTION: Doug to draw up state chart diagram for key flow
[recorded in
[20]http://www.w3.org/2008/03/19-webapi-minutes.html#action01]
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 and get it in a form we can visualize better
DS: I understand the rationale for a single keyDown
TL: Some browsers have keyPress AFTER keyUp
DS: I would like for this to be a neat model, if it has to get messy
to account for what web apps depend upon, so be it
TL: go for least common denominator, or most common feature, for
exmaple
DS: I think we should take content with a grain of salt
... - existing content being developed and maintained can be altered
... - older content not miantained and is not active looses
relevance as time goes on
... - for every piece of content which relies on one behavior,
changes there is another piece that breaks in another area
TL: Minute changes for the better always breaks somebody
... Some cases argue it is appropriate given the progress being made
cmd +/-
scroll event
DS: Pressing because we're already talking about mousewheel
[21]http://www.w3.org/2008/webapps/wiki/Scroll
[21] http://www.w3.org/2008/webapps/wiki/Scroll
TL: Related to OnScroll, related to HTML4?
[22]http://www.w3.org/TR/html401/interact/scripts.html#events
[22] http://www.w3.org/TR/html401/interact/scripts.html#events
TL: Doesn't look like it is in the HTML 4 spec
CM: Perhaps Netscale 3.0
DS: I came up with a few use cases and requirements
... Would be good if you could come up with more and add them
... Would be nice to have scrollX, scrollY, offset, whatever in the
vent
... Now they get the event and ask the window how much
... I put the idea in for a mode ( pixel, page, screen, etc )
... Things that Mozilla does
... ex: line scrolls one line of text
TL: A web-page can have all sorts of fonts and styles
DS: May be contextual - only for drop-downs, etc
... Should this happen at the level of mousewheel?
... Have a dropdown - scrolling
... If I send a wheel event to browser, that gives one thing
... Default action of mousewheel is to through a scroll event
... Scroll event knows the element on which it was activated
... Can determine what mode it is going to be in
... Even a whelleDelta of 4 or 1 is sufficient to scroll a line, for
a dropdown
TL: If you can cancelledthe wheelevent, you would not fire the
default action of scroll event
OP: Scroll event happens after an event has occurred, cannot cancel
... Scroll event is about how much some content has been scrolled
... If you look at our pixel scrolling bug, a Mac can generate a
pixel event and a line event
... There are both
DS: This
Re: Please Review: Mousewheel Event Proposal
Hi, Olli- Thanks for your comments. Replies inline... Olli Pettay wrote (on 3/18/08 6:29 PM): "It should allow authors to override the default action for either x or y activity independently. " I think also z. Yes, added. It is open what wheelDelta means. Is it "mousescroll clicks"? Moving finger over touchpad? Yes, it has to stay open, because it is device- and system-dependent and usually user-configurable. I also changed "clicks" to the more generic "rolls", to avoid confusion with the mouseclick event. But what if system can generate several kinds of data - line scrolling and pixel scrolling, maybe even page scrolling or screen scrolling. Should we have different event names for different kinds of scrolling. That is a related matter, but should be defined in the 'scroll' event [1], not the 'mousewheel' event. I'll write some tests to see what browsers do. Anyone else is also welcome to help with this, or report findings you've already made. As far as I can see, the 'scroll' and 'DOMScroll' event don't have any specific properties, but maybe we could add some, like scrollEvent.mode="line | pixel | page | screen". Or perhaps it could be quantified in scrollDeltas, or reflect the window.scrollX/scrollY or window.pageXOffset/pageYOffset. I'm open to any suggestions, as long as we keep it simple. Should web application know somehow that what is the default action of mouse wheel scrolling: scrolling or zooming... On my browser ctrl+wheel is zoom, alt+wheel is slower-than-normal- scrolling. The 'mousewheel' event is separate from the 'scroll' event, though the default action of the 'mousewheel' event is normally to throw a subsequent 'scroll' event. We clearly need to define this relationship better. We also clearly need to better specify the 'scroll' event; in addition to generation by a 'mousewheel' event, it may also be triggered by using the scrollbars or arrow keys, or by a script-generated event, for example. It also doesn't seem to have (It might be useful to let the user know where the 'scroll' event was generated, whether from a scrollbar, mousewheel, arrow-key, generated event, etc sorta like keyLocation... No, wait, they can more or less already do that by listening for those other events. Never mind, thinking out loud. Well... hmm... given that we may at some point allow multiple mouse inputs simultaneously, for multi-touch inputs, or devices like the Wii, maybe... no, no, no.) "For both mouseomniwheel and mousewheel, MouseEvent.relatedNode must indicate the element over which the pointer is located" Why? element.target should indicate that already. MouseOmniWheelEvent needs some examples. In which case is that event used? MouseOmniWheelEvent was part of the other, original, much more complicated proposal. I've updated the wiki to make it more clear that there are 2 different proposals. [1] http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-scroll Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Please Review: Mousewheel Event Proposal
Hi, WebAPI fans- We believe that we have a workable model for the 'mousewheel' event, which greatly simplifies the previous proposal. I've made a wiki page which contains both proposals, the new one first: http://www.w3.org/2008/webapps/wiki/Mousewheel Please review the proposal and give us feedback. We intend to resolve during tomorrow's telcon to put this proposal in the DOM3 Events spec. (Obviously, subject to comments up to and including Last Call.) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Agenda, 19 March 2008 (Tomorrow!!)
Hi WebAPI Fans- This is a reminder that we will have a DOM 3 Events telcon tomorrow, 19 March. The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] NOTE: Because of Daylight Savings Time, the times will be different for anyone living outside North America. The tentative agenda is as follows: 1. Convene, take roll, review agenda, plan next meeting 2. Issue/Action review 3. mousewheel: closing action 4. key event sequence model: proposed model 5. cmd +/- (ISSUE-79) 6. mobile-specific events (ISSUE-51) For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/19_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: IE Team's Proposal for Cross Site Requests
Hi, Sunava- Could you please resend this as an HTML attachment, rather than as the body of the email? Many people use text-based email clients (I myself normally view emails as text-only, though I can switch on HTML), making this very hard to read. It also looks crummy in the archives: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html Thanks- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: [Element Traversal LC] Editorial: "attribute" at ECMAScript Language Binding
Hi, Takeshi- Thanks for your feedback. KUROSAWA, Takeshi wrote (on 3/12/08 9:10 AM): Element Traversal Spec uses "attribute" word at ECMAScript Language Biding[1]. firstElementChild This read-only attribute is of type Element. But it is prefered to use "property" rather than "attribute" in ECMAScript world. Other DOM Specs use "property" at ECMAScript Language Binding (ex. DOM Level 1[2], ...). The biding should be something like below: firstElementChild This read-only property is of type Element. ... childElementCount This read-only property is of type Number. Indeed, that is how I defined it before, modeling it on earlier DOM specs. I changed it in response to an earlier comment. [1] I was perhaps overzealous in my changes. Since "property" is JS terminology, while "attribute" is IDL terminology, I should in fact use both terms. I'll correct this, thanks! [1] http://lists.w3.org/Archives/Public/public-webapi/2007Aug/0035.html Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Accessing Object Parameters from an Embedded SVG
Hi, Folks- Hallvord R. M. Steen wrote (on 3/13/08 10:08 PM): On Fri, 14 Mar 2008 05:24:45 +0900, Jonas Sicking <[EMAIL PROTECTED]> wrote: The proper fix here is IMHO to add something to the window object. So that you don't have to reach out into documents that are from a different domain. Agree. Would window.paramList be a good name? An object with name:value mappings would be useful, and one could iterate over it with for..in as usual. Agreed. I think this should be specified in the Window spec (and maybe to the HTML5 spec?). Boris Zbarsky wrote (on 3/13/08 3:11 PM): 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, and WebAPI
Minutes: DOM3 Events Telcon Agenda, 12 March 2008
Hi, WebAPI fans- The minutes for the DOM3 Events telcon on 12 March 2008 can be found here: http://www.w3.org/2008/03/12-webapi-minutes.html Or as text below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 12 Mar 2008 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0050.html See also: [3]IRC log [3] http://www.w3.org/2008/03/12-webapi-irc Attendees Present aemmons, Doug Regrets Carmelo Chair Doug Scribe aemmons Contents * [4]Topics 1. [5]Issue / Action review 2. [6]Mouse Wheel 3. [7]Key Event Order * [8]Summary of Action Items _ Date: 12 March 2008 be right there Zakim: ??P0 is me Olli Pettay Scribe: aemmons ScribeNick: aemmons [9]http://www.w3.org/2008/webapps/wiki/12_Mar_2008 [9] http://www.w3.org/2008/webapps/wiki/12_Mar_2008 Issue / Action review Public issue tracker: [10]http://www.w3.org/2006/webapi/track/ [10] http://www.w3.org/2006/webapi/track/ [11]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event s.html [11] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html DS: I had two actions Mouse Wheel [12]http://www.w3.org/2005/06/tracker/webapi/actions/252 [12] http://www.w3.org/2005/06/tracker/webapi/actions/252 ACTION-252: Send mousewheel proposal to list [13]http://www.w3.org/2008/webapps/wiki/Mousewheel [13] http://www.w3.org/2008/webapps/wiki/Mousewheel DS: I added proposal to the wiki ... Olli, have you reviewed this yet? OP: No, not yet DS: (describes proposal) ... Single event has all wheelDelta information ... The default value for wheelDelta wil always be the larger of x or y or z ... A flaw in this plan - wheelDelta may not be available in Firefox OP: Firefox has mousescrollevent DS: Do you have issues with using a new event? OP: There will be regressions, that is a problem ... Perhaps event Google Maps, for exmaple DS: Will be a problem for some deployed web applications ... I wonder if we can have feedback from Google maps about this ... Perhaps we can come up with a way - suggest scripts non-normatively for work arounds ... Easy? Check if mousewheelevent interface exists, use that instead OP: Yes, it may still break some sites DS: YEs, any change will break sites ... Goal is to have least amount of breaks OP: In Firefox we have stopped support for some features, there are warning messages that some features are depricated and then removed ... Some very old NS 4 stuff DS: Mose user of mouse whell are fairly modern cases ... IN that case, these are the ones probably still live and can change to adapt ... If you find there is a way you can 'alias' domwheelscroll that would be very interesting ... The wheelDelta is unitless - there is no range of particular numbers OP: Somebody was trying to implement pixel scrolling, pixel quite different than normal wheelDelta values [14]https://bugzilla.mozilla.org/show_bug.cgi?id=350471 [14] https://bugzilla.mozilla.org/show_bug.cgi?id=350471 DS: I wonder if the term click is wrong here ... There is mouse click then delta - could be confused ... You can also click a mouse wheel AE: Makes sense to try and find something different DS: I think we MS in on this, they were the ones who wanted to unify it into one mouse event ACTION: Doug to review Mozilla bug for pixel scrolling and consider wrt mousewheel proposal [recorded in [15]http://www.w3.org/2008/03/12-webapi-minutes.html#action01] Created ACTION-258 - Review Mozilla bug for pixel scrolling and consider wrt mousewheel proposal [on Doug Schepers - due 2008-03-19]. ACTION: Doug to give deadline for next week regarding mouse wheel [recorded in [16]http://www.w3.org/2008/03/12-webapi-minutes.html#action02] Created ACTION-259 - Give deadline for next week regarding mouse wheel [on Doug Schepers - due 2008-03-19]. Key Event Order DS: Regarding mousewheel, Ollie are there more comments OP: If the mousewheelevent is cancelled, only vertical is cancelled. Why only vertical? DS: That is for mouseomniwheel event ... Someone may want to cancel default action just for x or y or z ... My proposal is if person wants to do that, they cancel the even and generate a new one with just wheel delta values that they want ... Does this differ from DOMScrollWheel significantly? ... Would you mind reviewing it? OP: Yes, sure DS: My hope is that it is a superset of the Firefox equivalent ... I think we use detail OP: Called DOMM
Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?
Hi, Slim- Slim Amamou wrote (on 3/12/08 6:59 AM): yes. sorry. I thought I'd better not increase the mailing list bandwidth with a lone "Thank you" in a mail. :-s I was mistaken. Thanks to everybody. Not at all... thanks for your feedback. As a matter of standardization process, we have 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
DOM3 Events Telcon Agenda, 12 March 2008 (Today!!)
Hi WebAPI WG- This is a reminder that we will have a DOM 3 Events telcon today (I should have sent this yesterday, again... I've now set an alarm on my calendar to remind me). The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] NOTE: Because of Daylight Savings Time, the times will be different for anyone living outside North America. The tentative agenda is as follows: # mousewheel # key event sequence model # test progress For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/12_Mar_2008 [3] 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?
Hi, Slim- liorean wrote (on 3/7/08 10:59 AM): On 07/03/2008, Slim Amamou <[EMAIL PROTECTED]> wrote: hi, the ElementTraversal interface is bound to readonly attributes in ecmascript, whereas it is bound to methods in java. why? Because having things like this as as properties is normal the ECMAScript way, but having getter and setter functions is the normal Java way. it would be more convenient if it was bound to methods in ecmascript either. i can think of two arguments for this : - the bindings will be more consistent (so that you don't have "getChildElementCount" and "childElementCount" representing the same binding) Having getter and setter functions using method syntax is a distinctly foreign way of doing this in JavaScript. Plus, these properties analogously match the way it's done for the node traversal bindings in our earlier DOM versions. And thirdly, those would be two 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
Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?
Hi, Simon- Simon Pieters wrote (on 3/7/08 11:14 AM): FWIW, I made a javascript implementation a while ago: http://simon.html5.org/sandbox/js/elementtraversal.js Very cool... It's been implemented several other places, as well. Now we just need a test suite, and we've got ourselves a Proposed Recommendation. ;) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Geolocation API proposal
Hi, Aaron- Aaron Boodman wrote (on 3/6/08 8:55 PM): I work on Google Gears team. If you're not familiar with what Gears is, you can learn more here: http://code.google.com/apis/gears. We've been working on an API that will allow an application to obtain (with permission) the user's current location. I posted this to the WhatWG mailing list, but it was suggested that this might be a more appropriate place. Anyway, here's our current design: http://code.google.com/p/google-gears/wiki/LocationAPI We think there's a lot of potential for interesting applications with a API like this. Some examples would be recommendations for nearby restaurants, turn by turn directions, or city walking tours. Are there any other vendors interested in implementing something like this? If so, we'd like to work together to come up with a standard. Otherwise, I'll just put this out there for comment for the time being. We'd appreciate any feedback on the design, one way or the other. This is interesting stuff, and I agree it is very useful to have. There is already some activity happening in this area, in the Ubiquitous Web Applications Working Group (UWA or UbiWeb). [1] It's obviously a hot topic, and one I personally hope can be specified and deployed quickly (since we're already about 15 years behind Japan in this stuff ^_^ ). I think you hit the nail regarding vendors... that's a crucial next step. I'm happy to facilitate bringing your insight in this area to W3C, and I'm sure we can find the best way to move this forward, and get involvement from other vendors. Feel free to drop me a line offlist, and I can do a bit more research and point you in the right direction. [1] http://www.w3.org/2007/uwa/ Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Key Event Order
Hey, WebAPI fans- I went through the archives and looked at past discussions, and put together what I think should be the event order for key and textInput events. Please review it and comment. It's still in the rough stages, and doesn't properly account for IME stuff, but it's getting there, I think. http://www.w3.org/2008/webapps/wiki/Key_event_order Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
MouseWheel Proposal
Hi, WebAPI fans- I looked through all the issues and proposals, did some testing, and came up with what I hope will be a solid proposal for final wording on the issue of mousewheels. [1] This is a solution that was discussed in a recent DOM3 Events telcon, and was favored by BitFlash and Microsoft, because it doesn't require as deep a hierarchy of interfaces as does the current model. [2] For the sake of argument, I put both models in the wiki [3], but I'm only asking for feedback on the first. This interface is simpler for authors and for implementors, and I believe it covers the great majority of use cases. It is also, afaict, compatible with what's implemented today. The one use case this doesn't seem to address is the canceling of wheel events along a single axis. I believe there is a suitable workaround, which I outline in the proposal. My suggestion is that we specify this interface per my proposal, and if after implementation we find from author feedback that the more complex MouseOmniWheel/MouseMultiWheel interface is still needed, that can be implemented without causing conflicts (this would simply occupy the role that the existing MouseWheelEvent does). [1] http://www.w3.org/2008/webapps/wiki/Mousewheel#Single_Event_With_Multiple_WheelDeltas [2] http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/events.html#Events-eventgroupings-mousemultiwheelevents [3] http://www.w3.org/2008/webapps/wiki/Mousewheel#Multiple_WheelDelta_Events_With_Hierarchy Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Agenda, 05 March 2008 (Today!!)
Hi WebAPI WG- This is a reminder that will will have a DOM 3 Events telcon today (I should have sent this yesterday). The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: # mousewheel issues For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/5_Mar_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
DOM3 Events Telcon Minutes, 27 Feb 2008
Hi, WebAPI fans- The minutes for the 27 Feb 2008 DOM3 Events telcon can be found here: http://www.w3.org/2008/02/27-webapi-minutes.html Or as text, below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 27 Feb 2008 [2]Agenda [2] http://www.w3.org/2008/webapps/wiki/27_Feb_2008 See also: [3]IRC log [3] http://www.w3.org/2008/02/27-webapi-irc Attendees Present Carmelo, Andrew_Emmons, Doug, Travis Regrets Chair Doug Scribe Carmelo Contents * [4]Topics 1. [5]DoubleClick 2. [6]Double Click 3. [7]lets differ wheels to next week 4. [8]dblclick Tests 5. [9]'alt'-key 6. [10]mousewheel overview * [11]Summary of Action Items _ Date: 27 February 2008 Scribe: Carmelo ScribeNick:Carmelo Here I am. TL: Changes his name to Travis DS: We decided not to talk about Key events ... We need to decide how to handle keyboards and that sort of things ... Lets start with Double Click DoubleClick Double Click [12]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0050.h tml [12] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0050.html AS: Two issuus Regarding Doubing Click DS: Can u summarize? AS: Should the detail value be for Double Click? ... Consensus is should be teh same as click ... Described and explained teh link above TL: Can an example be provid? R: detail for double click will be the same a the click RESOLUTION: detail for double click will be the same a the click RESOLUTION: We accept the current wording in the spec regarding what the current click count means ACTION: aemmons to add informative examples of different click counts for dblclick [recorded in [13]http://www.w3.org/2008/02/27-webapi-minutes.html#action01] Created ACTION-246 - Add informative examples of different click counts for dblclick [on Andrew Emmons - due 2008-03-05]. DS: We are finish with double Click lets differ wheels to next week DS: Let's review the DoubleClick Test [14]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.h tml [14] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.html dblclick Tests test 1: [15]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.h tml [15] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.html DS; If red shown in the test it means failure DS: Green usually a pass ... Instruction For each test ACTION: Doug to provied test template [recorded in [16]http://www.w3.org/2008/02/27-webapi-minutes.html#action02] 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 ACTION: TL to give us a script library that will add listener events. [recorded in [17]http://www.w3.org/2008/02/27-webapi-minutes.html#action03] Created ACTION-248 - Give us a script library that will add listener events. [on Travis Leithead - due 2008-03-05]. ACTION: Travis to provide simple abstraction layer for addEventListener [recorded in [18]http://www.w3.org/2008/02/27-webapi-minutes.html#action04] Created ACTION-249 - Provide simple abstraction layer for addEventListener [on Travis Leithead - due 2008-03-05]. DS: We will build a script layer for testing Carmelo: How critical is add eventListener? DS: not sure? TL: addEventListener is one of the key pieces different from implementations ... Another piece that is different Scope of the event object itself TL; Will be happy to provide a small library to buil on TL: Will be happy to provide a small library to buil on [19]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0164.h tml [19] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0164.html AE: Above link is an SVG version of the NIST test AS: Lets Move on DS: Ok 'alt'-key [20]http://www.w3.org/2005/06/tracker/webapi/issues/122 [20] http://www.w3.org/2005/06/tracker/webapi/issues/122 TL: ALT key events is sometimes loose. ... Explained the issue and the scenarios for "ALT" handling DL: propoesed two options sub/DL/TL/ sub /DL/TL/ DS: Thsi behavious is somehow address in DOM 3 events ... maybe this should be on next week's agenda DS; None of this should be dependent on any OS DS: We cna have a non- normative appendix for somer key sequences TL: That will be a
DOM3 Events Telcon Agenda, 27 Feb 2008 (Tomorrow!)
Hi WebAPI WG- This is a reminder that will will have a DOM 3 Events telcon tomorrow. The regular time is Wednesdays, 19:30-21:00 UTC. See the DOM3 Events wiki page for timezones adjustments. [1] The tentative agenda is as follows: # dblclick test review # Close dblclick issue # Discussion of mousewheel issues # Open discussion of Issue-122 on 'alt'-key For each week's telcon, we will maintain an agenda page [2] so you can track what the discussion will be, add agenda topics, and see the minutes afterward. We will also maintain a list of all the past 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/27_Feb_2008 [3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: ElementTraversal comments
Hi, Simon- Simon Pieters wrote (on 2/26/08 12:39 PM): On Tue, 26 Feb 2008 17:27:01 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote: I'm not sure how I can make it more clear without imposing undue restrictions on UAs. I'd suggest to take a similar approach as HTML5: The language in this specification assumes that the user agent expands all entity references, and therefore does not include entity reference nodes in the DOM. If user agents do include entity reference nodes in the DOM, then user agents must handle them as if they were fully expanded when implementing this specification. For example, if a requirement talks about an element's child text nodes, then any text nodes that are children of an entity reference that is a child of that element would be used as well. That is very specific, which is good. But I'm not comfortable with imposing such specificity on a UA, especially for what I see as an edge-case. It may simply be ignorance on my part, but I don't know how all UAs handle that situation, and I don't have a good sense of what the implications of that are for a UA that might behave differently. HTML5 may be able to dictate terms like that, since it defines the parsing model as well as the API, but I don't feel that DOM-related specs should make such decisions. I don't feel extremely strongly about this, so if I got corroborating feedback from more UAs (a non-browser UA that implement DOM would be great), I'm willing to change my mind. Alternately, I'm willing to change the spec if that's the will of the WebAPI WG as a whole. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
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 > > > is designed for a minimal code footprint." I suggest dropping this > > > sentence. > > > > That's an odd request. A better suggestion might be to clarify the > > sentence, since I wouldn't have put it in if I didn't think the > > point needed to be made. > > > > Most of the functionality of this spec is an optimized subset of > > DOM2 Traversal & Range, and it is intended that a UA could implement > > both by aliasing; however, this isn't required for conformance to > > this specification. I hope that clarifies it for you. > > It's not a subset at all. Clarification is ok too, but I think the > sentence is a distraction. It can be implemented as a subset of functionality. If others agree with you, I will rework of remove the sentence in question, though. For what it's worth I didn't understand the sentence either, before you explained it. Even now, it sort of reads as saying that if you're not a "minimal code footprint" UA (who isn'?), you are not allowed to implement other similar specs. Or possibly, you are required to implement them, it's not clear. It certainly seems like confusing use of RFC2119 terminology. Hmmm... well, if you say so. It seems clear to me, but maybe that's because I wrote it. Given that I already mention DOM2 Traversal & Range elsewhere, so people are familiar with the distinction, maybe it's best I remove it. I don't think I intended that as a testable assertion, anyway. Ok, I'll consider something like that. Incidentally, from one fellow spec writer to another, in particular one who has to deal with an ungodly amount of feedback :-), I would recommend replying to each e-mail _after_ having made all the changes that you plan to do in reply to the e-mail, rather than before -- that way, you have a clear way of telling how much feedback you have left, and the commentors have a clear way of knowing when to look at the spec to see if they are happy with the new text. Just a suggestion, take it or leave it as you wish, I just find it helps. :-) I appreciate the feedback. I had indeed already made the changes, but problems with CVS prevented me from updating the public CVS copy temporarily. The changes were in the soon-to-be-published version, though, as I'd said. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
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 traversing for the DOM is already slightly unclear to me, but childElementCount seems to provide neither. I've reworded the introduction slightly, in hopes of making it more clear. I've also added explanatory text to example 3.2, which demonstrates the use of childElementCount. Where is the draft located that contains these changes? It seems you haven't updated the editor's copy which makes it hard for me to revew the changes. I've uploaded it to public CVS now [1]. I was having some trouble with that last night. * 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 is designed for a minimal code footprint." I suggest dropping this sentence. That's an odd request. A better suggestion might be to clarify the sentence, since I wouldn't have put it in if I didn't think the point needed to be made. Most of the functionality of this spec is an optimized subset of DOM2 Traversal & Range, and it is intended that a UA could implement both by aliasing; however, this isn't required for conformance to this specification. I hope that clarifies it for you. It's not a subset at all. Clarification is ok too, but I think the sentence is a distraction. It can be implemented as a subset of functionality. If others agree with you, I will rework of remove the sentence in question, though. * It's not clear to me how "For the purpose of ElementTraversal, an entity reference node which represents an element must be treated as an element node." works. Does this mean that an EntityReference node also implements this interface? I suggest dropping this sentence or stating that this interface assumes that all entities are normalized away or something. I put this in as a response to an earlier comment [1]. While I think it's an edge case, the commenter was satisfied by the response. That may very well be so, but I don't understand what it's saying. I'm reluctant to mandate how a UA implements the solution, whether by implementing this interface on the entity reference node or only on the expanded resulting DOM, because I don't know how every UA does so. I don't think it effects interoperability, so I prefer to leave it as is. Leaving it as does not satisfy me as I think the sentence is unclear. I'm not sure how I can make it more clear without imposing undue restrictions on UAs. * "Accessing this attribute of an element must return a reference to the first child node of that element which is of nodeType 1, as an Element object." I don't think ", as an Element object." makes much sense in this sentence. (Likewise for similar sentences.) I don't agree, but if you care to suggest alternate wording, I'll consider it. "Getting this attribute of an element must return the first Element child node of that element or null if there are no Element child nodes." Ok, I'll consider something like that. * I don't think the IDL should be in the appendix. It's a useful overview of what the draft defines. I think this is a stylistic change that doesn't affect the readability or usefulness of the specification. I prefer to keep it as is, since it makes more sense to me this way. It would tell you upfront what the interface is and what members it introduces and provide pointers to the definitions of those members. I think that would make the draft more readable. There are only 5 attributes, and I describe them in the introduction (in broad strokes), again (verbosely) in the interface description prose, and again (tersely) in the IDL. I find it hard to credit that they are somehow unclear. I don't agree that changing the structure of the document would make it more readable, and I think it would make it less discrete. Since I made only editorial, non-normative changes, I published them in the upcoming LCWD document, to be published next Monday. I don't understand why it's not in the editor's draft. Everything what this group does, including editorial work, is captured in public documents nowadays. See above. Relax, Anne, nobody's trying to pull anything shady. [1] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.12 Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: ElementTraversal comments
Hi, Anne- Thanks for your feedback. Anne van Kesteren wrote (on 2/25/08 4:25 PM): Some comments on http://dev.w3.org/2006/webapi/ElementTraversal/publish/ElementTraversal.html below * As mentioned on IRC, node types should probably be capitalized. E.g. Text instead of text. Yes, I think I've caught all these now. * It's not clear from the introduction why we need childElementCount. Having both linked list and array like traversing for the DOM is already slightly unclear to me, but childElementCount seems to provide neither. I've reworded the introduction slightly, in hopes of making it more clear. I've also added explanatory text to example 3.2, which demonstrates the use of childElementCount. * I don't understand why 1.1 is marked as informative and section 1. is not. Fixed. * 2. talks about implementing methods where you mean attributes. They are methods in Java (see appendix C), but I've changed it to say attributes. * In 2. ElementTraversal is not marked up. I've made an extensive check for stuff that should be marked up and linked, and I think I've caught everything now. * 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 is designed for a minimal code footprint." I suggest dropping this sentence. That's an odd request. A better suggestion might be to clarify the sentence, since I wouldn't have put it in if I didn't think the point needed to be made. Most of the functionality of this spec is an optimized subset of DOM2 Traversal & Range, and it is intended that a UA could implement both by aliasing; however, this isn't required for conformance to this specification. I hope that clarifies it for you. * It's not clear to me how "For the purpose of ElementTraversal, an entity reference node which represents an element must be treated as an element node." works. Does this mean that an EntityReference node also implements this interface? I suggest dropping this sentence or stating that this interface assumes that all entities are normalized away or something. I put this in as a response to an earlier comment [1]. While I think it's an edge case, the commenter was satisfied by the response. I'm reluctant to mandate how a UA implements the solution, whether by implementing this interface on the entity reference node or only on the expanded resulting DOM, because I don't know how every UA does so. I don't think it effects interoperability, so I prefer to leave it as is. (We should really get rid of syntactic sugar in the DOM in due course...) I'm not sure I'd consider entities as "syntactic sugar". On the other hand, I'd totally consider this spec as syntactic sugar (making it easier for authors while not changing the underlying functionality of the language), so I disagree with the premise. * "Accessing this attribute of an element must return a reference to the first child node of that element which is of nodeType 1, as an Element object." I don't think ", as an Element object." makes much sense in this sentence. (Likewise for similar sentences.) I don't agree, but if you care to suggest alternate wording, I'll consider it. * I don't think the IDL should be in the appendix. It's a useful overview of what the draft defines. I think this is a stylistic change that doesn't affect the readability or usefulness of the specification. I prefer to keep it as is, since it makes more sense to me this way. I would also like to see pointers from the IDL bits to their definitions. As we've done in the XMLHttpRequest specification. As stated above, I've added many more links and markup, so I hope that helps. As far as I can see, though, XHR doesn't contain an IDL per se. Since I made only editorial, non-normative changes, I published them in the upcoming LCWD document, to be published next Monday. [1] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: IE Team's Feedback on the XHR Draft
Hi, Folks- To be clear, I'm not critiquing the spec itself, or advocating any specific action. Rather, I'm trying to manage expectations and ensure that the various participants of this WG can work smoothly with one another. I'm acting purely as a Process wonk here. Sunava, as you see, there is considerable, and reasonable, incentive to make the XHR spec as detailed as possible, even where it may not match the IE implementation precisely. Maciej's request for more specific details on potential conflicts (in implementations or content) is appropriate, I think. I don't know if you are familiar with the W3C Recommendation Track [1], so briefly, you should know that LC (Last Call) is not the end of the process. It simply indicates that the specification is believed to have satisfied its technical requirements; it's not considered stable enough for implementation, and in practice, this is when most comments are made. Thus, I see little harm in advancing to LC, since you will still have an opportunity to submit additional technical comments. [1] http://www.w3.org/2005/10/Process-20051014/tr Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: IE Team's Feedback on the XHR Draft
Hi, Anne- I'm stepping in here to inform on a matter of process. This is not a judgment on the technical merits of either position. Anne van Kesteren wrote (on 2/7/08 5:42 AM): o As per our agreement in the tech plenary the spec will conform to IE's implementation of XHR (with the exception of constants) and will be changed accordingly. The tests are important for us and other UAs as it's the guarantor of that. We have had no such agreement. I indicated that we have followed the IE for a lot of scenarios, but there are some deviations. It is true that there was no formal resolution on this issue. (As an aside: Sunava, for future reference, it's most expeditious to request a formal resolution on matters about which you feel very strongly. This clears up any ambiguity, makes a point of reference for future discussion, and gives opponents an opportunity to present counter-arguments. ) However, I seem to recall general agreement about this point among the majority of participants; alas, this was not clearly captured in the minutes (though the minutes are good, it's hard to grab general sentiment). Moreover, this is, in fact, what this WG was chartered to do regarding XHR: "This deliverable should begin by documenting the existing XMLHttpRequest interface." The question becomes, is IE's implementation to be considered canonical, or is it up to interpretation vis a vis later implementations (FF, Opera, Safari, et al)? Pursuant to that, is there a way to document the existing behavior such that it does not make existing implementation retroactively "non-conforming"? Or that does not affect existing content? I don't know whether or not the existing specification meets these criteria, but I think that would be the best path forward. [1] http://www.w3.org/2006/webapi/admin/charter Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Minutes, DOM3 Events telcon for 6 Feb 2008
Hi, WebAPI fans- Here are the minutes for the DOM3 Events telcon for 6 Feb 2008. Sorry for the funky formatting. http://www.w3.org/2008/02/06-webapi-minutes.html Or as text, below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 06 Feb 2008 See also: [2]IRC log [2] http://www.w3.org/2008/02/06-webapi-irc Attendees Present Regrets Chair SV_MEETING_CHAIR Scribe shepazu Contents * [3]Topics * [4]Summary of Action Items _ Date: 06 February 2008 shepazu: Zakim, this is DOM3 [2:27pm] Zakim: shepazu, I see IA_WebAPI(DOM3)2:30PM in the schedule but not yet started. Perhaps you mean "this will be DOM3". [2:27pm] shepazu: sigh [2:27pm] shepazu: Zakim, this will be DOM3 [2:27pm] Zakim: ok, shepazu; I see IA_WebAPI(DOM3)2:30PM scheduled to start in 3 minutes [2:27pm] Zakim: IA_WebAPI(DOM3)2:30PM has now started [2:27pm] Zakim: +Carmelo [2:27pm] shepazu: Zakim, code? [2:27pm] Zakim: the conference code is 3663 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), shepazu [2:28pm] anne: hmm, office us is just starting [2:28pm] Zakim: +Andrew_Emmons [2:29pm] shepazu: sorry, phone problems, just a couple minutes [2:31pm] anne: Zakim, who is on the phone? [2:31pm] Zakim: On the phone I see Carmelo, Andrew_Emmons [2:31pm] • anne waits for shepazu [2:35pm] anne: Zakim, who is on the phone? [2:35pm] Zakim: On the phone I see Carmelo, Andrew_Emmons [2:35pm] Zakim: +??P0 [2:35pm] shepazu: Zakim, +??P0 [2:35pm] Zakim: I saw ??P0 just arrive [2:35pm] Carmelo: Hello Everyone [2:35pm] shepazu: Zakim, +??P0 is me [2:35pm] Zakim: sorry, shepazu, I do not recognize a party named '+??P0' [2:35pm] shepazu: Zakim, +??P0 is Doug Schepers [2:35pm] Zakim: I don't understand '+??P0 is Doug Schepers', shepazu [2:36pm] Zakim: +anne [2:36pm] shepazu: Zakim, +??P0 is me [2:36pm] Zakim: sorry, shepazu, I do not recognize a party named '+??P0' [2:36pm] shepazu: Zakim, ??P0 is me [2:36pm] Zakim: +shepazu; got it [2:37pm] shepazu: anne, can you join [2:37pm] shepazu: ? [2:37pm] aemmons: Scribe: Andrew Emmons [2:38pm] aemmons: ScribeNick: aemmons [2:38pm] aemmons: Chair: Doug Schepers [2:38pm] aemmons: Topic: Introduction meeting [2:38pm] aemmons: DS: Introducing Andrew Emmons [2:39pm] aemmons: DS: Known for some time [2:39pm] aemmons: DS: Motivated to get DOM3 Events published [2:39pm] aemmons: DS: Anticipate that it is largely done [2:39pm] aemmons: DS: Goal of meetings to establish what is left to be done [2:39pm] aemmons: DS: Find out what is implemeted [2:40pm] aemmons: DS: Find out what is different than what is implemented [2:40pm] aemmons: DS: I would like to see spec as CR in 4-6 months [2:40pm] aemmons: DS: CR is when you need a good test suite [2:41pm] Lachy joined the chat room. [2:41pm] Lachy left the chat room. (Quit: Leaving) [2:41pm] aemmons: DS: Andrew Emmons is from BitFlash [2:41pm] Lachy joined the chat room. [2:41pm] aemmons: DS: Implements SVGT 1.2 and thus DOM 3 Events [2:42pm] aemmons: DS: Anne works for Opera, well informed regarding DOM 3 Events [2:42pm] aemmons: DS: I work for W3C, staff contact for WebAPI [2:43pm] aemmons: DS: Carmelo works for NIST [2:43pm] aemmons: DS: Has done some DOM testing in the past [2:44pm] aemmons: CM: Will DOM LEvel 3 Events be using the same framework as DOM LEvel 2 Events? [2:44pm] aemmons: CM: I was looking at the previous frameworks [2:44pm] aemmons: DS: W3C specifications do implementability testing [2:44pm] aemmons: DS: No focus on interopability [2:45pm] aemmons: DS: There has been a new focus to have interopability between implementations [2:45pm] • anne has to go in ~15 min for a WAF meeting [2:45pm] aemmons: DS: Want to make sure the DOM3 Events Test suite has a focus for interopability [2:46pm] aemmons: DS: Worth our time on how to setup the testing framework [2:47pm] aemmons: CM: I could not find a DOM Level 2 events test suite [2:47pm] aemmons: DS: I do not think one exists [2:47pm] aemmons: CM: How wass this tested in the past? [2:47pm] aemmons: DS: Not sure [2:47pm] aemmons: CM: How did it become a Recommendation [2:48pm] aemmons: Av: The requirements were more loose at that time [2:48pm] aemmons: CM: Should we have tests for DOM Level 2 Events? [2:48pm] aemmons: DS: May be useful, where there is overlap [2:50pm] aemmons: DS: My goal is to get the spec out with features that are compatible or easy to do with existing browsers [2:50pm] aemmons: DS: Implem
Re: [waf] New Charter proposal
Hi, Mark- Thanks for your feedback. Mark Nottingham wrote (on 1/6/08 8:48 PM): My feedback is that the proposed charter is far too broad. There's already a substantial spread in the existing working groups, and combining them multiplies it; you'd be working on protocols, APIs, security mechanisms, DOM extensions, widgets and a major new XML language. We're already working on each of these things, and are finding the overlap makes that harder. Doing so would advantage a few people who are involved and interested in all of these efforts, but would disadvantage those who are not -- including people with valuable expertise -- by overloading them with e-mail and forcing them to sit through meetings where items not of there interest were discussed. I agree that needs to be avoided. I am particularly sensitive to this issue, because I participated in a WG in which each spec was discussed during each telcon, and it led to a lack of focus that drove the WG apart. This is why I included the clause, "Most Web Application Working Group Teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis." Perhaps I could have articulated that better. The plan is to have a dedicated telcon for each spec, periodically. The topic of discussion will always be announced ahead of time. Only that spec (or specs, in cases of coordination) will be discussed. Does that address your issue? Please note that I am a big fan of telcons, so I do want regular meetings. As far as email goes, each spec is discussed in a thread prefaced with the name of that spec, so it should be easy to prioritize the particular emails. Maybe we could set up list conventions to aid this? It also puts constraints on the amount of things that can be discussed simultaneously, with perhaps the unintended side effect of increasing the group's reliance on a few key contributors. Assuming that W3C is going to be working on all these things, I don't see how this introduces any more need for discussion. A much better result would be achieved by splitting the efforts further, into more focused working groups. This would undoubtedly increase the burden on a few people who do want to be involved in all of these efforts, I suspect that the majority of the people who are involved are already intertwingled. as well as perhaps the Team (although it may be possible to mitigate that), Can you describe how? Honestly, I think this will reduce the load on both Mike and me, because we can collaborate. We will need only 2 chairs and around 2 team contacts, rather than the several of each it would require for multiple groups. but would increase the likelihood of high-quality participation and a standard that truly reflects consensus. Consensus is most valuable when it is inclusive of all the factors involved. We desperately need to make sure these specs work well together. It's easy to get consensus when you limit the scope, but it's also less useful for the final "product". Alternatively, if there's some intent of serialising the output, the charter(s) could be written to only address the immediately upcoming deliverable, with the understanding that later rechartering will move the focus of the group(s) onwards. The chartering process, while necessary, slows down the real work of the WG, and takes several weeks of review and approval. To change that, we would need to change the policy of the W3C on chartering, and that would itself take time. I'm not dismissing your 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 ?
Hi, Ruud- Ruud Steltenpool ( http://svg.startpagina.nl ) wrote (on 9/19/2007 7:32 PM): How ready are webstandards for multi-cursor and multi-touch GUIs ? Technologies becoming more popular, which W3C standards don't cover enough?: - tabletPC with a stylus with 10bit sensitivity levels - iPhone, making multi-touch technology popular - tablePC, big screens with multiple people (and objects) interacting simultaneously - on-line cooperative whiteboards There is a Multimodal Architecture and Interfaces Workshop being held near Tokyo next month. I'm hoping some good activity 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
Hi, Mohamed- Thanks for your review and corrections. Replies inline. Innovimax SARL wrote (on 10/21/2007 2:58 PM): s/provides a attribute/provides an attribute/ s/english/English/ Why is "element" not written "Element" ? same for "text" ? All fixed. Isn't "ChildrenElementsCount" better ? No, for mysterious reasons of collective nouns, conjoined words, and pluralization in English. ;) (Waves hands in a hypnotic way) Trust a native speaker on this one. Anyway, please add some verbing to explain why this has been added to the original SVG proposal Added a brief note in the Change Log section. The actual explanation is throughout the body of the specification. In short, I prototyped the specification in JS, did some scripting tests using past projects of my own, and found that I needed a way to get the number of elements. Et voila. Please add informative 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] Not a set of properties on Element
Hi, Cameron- Thanks for your suggested wording. I've updated v1.10 of the spec in CVS to incorporate your changes, used "attribute" throughout, and made some editorial fixes. Cameron McCormack wrote (on 10/3/2007 10:46 PM): Hi. In ElementTraversal section 2, there is this sentence: The ElementTraversal interface is a set of properties on the Element object, which allow an author to easily navigate between elements. This isn’t really accurate. I think this should be changed to: ElementTraversal is an interface with a set of attributes, which allow an author to easily 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
Re: [ElementTraversal] Editorial: property vs. attribute
Hi, Simon- Thanks for your input. I've updated v1.10 of the spec in CVS to refer to "attributes" instead of "properties". Simon Pieters wrote (on 8/4/2007 5:29 PM): http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html This spec defines 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, and WebAPI
Re: DOM3 Key events
Hi, Bjoern- Bjoern Hoehrmann wrote (on 8/1/2007 10:11 PM): Second, the Working Group agreed long ago to define a keypress event (and possibly a "longkeypress" event and legacy context information like .charCode and such), but not as part of the DOM Level 3 speci- fication, but rather as separate document. That is primarily so be- cause nobody has yet come up with specification text for them, which in turn is largely because some things are not particularily inter- operable about them. I believe Doug Schepers is the latest volunteer to work on this. In light of further input by a large number of other groups, the decision to split this off into another spec was reversed. The intent is now to integrate this all into Dom3-Events. I'm working on this right now, which is why I'm coordinating with the implementors. This behaviour is not something that should be used to standardise on as it has been designed with the goal of website compatibility rather than to be "nice". There seem to be only three options: a) we do not standardize in the area, b) we standardize whatever is implemented, c) browser vendors change their browsers, probably sacrificing web site compatibility in the process. I don't think A is a realistic choice. We have this mess now because it wasn't standardized. B is only possible if there is already interoperability, since anything else means that at least one browser will have to change; in fact, Oliver reports that WebKit is already changing in this regard. As politically unpopular as it is, I think we should give a serious look at C; we should figure out what the scope of any possible damage would be (both in terms of raw numbers of pages, and in how badly they would be broken), and minimize that. Pages can usually be changed, especially if we offer a coherent transition strategy (that is some sort of tutorial that explains how to get the functionality they need).If we can get all vendors to work interoperably going forward, it's worth a small amount of legacy breakage. So, realistically, the choice lies somewhere between B and C, where we specify the most coherent model from what browsers already do and what behavior pages rely on (which may not be exactly the same thing). As for your other points, is there anything in the specification that we absolutely must change, or that Apple would have to change in order comply with the specification where Apple is unlikely to do so? They need keypress, which I agree should go into the specification. Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI
Re: DOM3 Key events
Hi, Oliver- Oliver Hunt wrote (on 8/1/2007 6:48 PM): Really? By my testing it matches Firefox 2 behaviour on both mac and windows. IE behaviour results in the keypress not being fired. Oh, sorry, i didn't clarify (because that was just a note to be taken in the context of the earlier event handler definition) the textInput event is distinct from keypress, the sequence of events is (in vageuly regex-like syntax): (keydown -> (keypress -> textInput?)?)+ -> keyup We do plan on adding keypress (though I'd like to deprecate it), and will be defining the event order. As we discussed, it will look pretty much like this: (keydown -> (keypress -> textInput?)?)+ -> keylongpress? -> keyup longkeypress is optional, and has been requested by mobiles; we're also adding a few other mobile-specific things. Note that depending on the platform/device/etc., one or more of these events may not fire (for instance, you may have only keydown or keyup); but per this spec, if the environment supplies these events, they must happen in that order. According to the spec as it stands, if there is an input method editor, it happens after this sequence, which should look something like this (note that the current spec doesn't have keypress, so I omitted it here): keydown -> keyup -> [IME/textInput] Assuming that we fit keypress in there, does this cause any problems for any browser? Finally, we discussed the IME more extensively offlist... maybe you'd like to share your opinions about how/whether/where this should be specified? 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, The WebAPI Working Group is considering to conduct a poll to finally put the method naming issue in the CSS Query API specification to rest; Charles asked us to propose alternatives to selectElement/selectAllEle- ments. To this end, I would like to propose using two [1] of selectorQuery(...) / .selectorQueryAll(...) / .selectorQueryOne(...) instead. I believe these names offer the following benefits: * This is the only set of names where I know of no working group member with a good reason to strongly dislike them. * Many working group members have indicated these names work for them. Even Anne! * They are lexically distant from the selectNodes and select- SingleNode XPath methods that serve a very similar purpose. * They are lexically distant from DOM Range manipulation methods like DOM T&R's .selectNode, Dojo's .selectElement * They are quite unlikely to clash with other future DOM methods and attributes designed for other purposes. * In particular, DOM attributes that reflect XML attributes; selectElement='' is much more likely than selectorQuery='', c.f. SVG's targetElement='...' * They are just as long as the .select(All)Element(s) names. I understand somebody has to make the same proposal (or second this one) for it to be considered; if you think these names should be considered, or even think these would be better than selectElement, you are very welcome to do that. [1] There have been arguments that the shorter name should return a single element so authors write possibly more efficient code, and that the shorter name should return many elements because that is required more often and saves a few keystrokes. I think this is out of scope of the proposal and should be a separate question in the poll, if we are going to conduct one. Thanks, --
Re: New staff contact - Doug Schepers
Hey, Chaals, everyone- Charles McCathieNevile wrote: > >> Doug Schepers, who you all know, is now the WebAPI staff contact. > > YAY!! Welcome Doug... Thanks!!! > so, this means that the person responsible for any > delays in getting your element traversal spec published is... > > > ... You! :) > > Hopefully we will have a lot more specs to publish in the next few > months. Sorry, but I prefer that to not publishing. Looking forward to it. I'm still coming up to speed on these things, but I hope to be more using in a couple weeks. Regards- -Doug
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
pattern.
True. Of those, I would much prefer matchSelector()... which is, for me
at least, easier to type and less ambiguous.
Not that this is at all evidential, but querySelector sounds like you're
asking the selector a question ("Hi, Selector, how's your day?"), while
selectElement and matchSelector sound like commands ("Selector, go get
me some elements!").
I still much prefer selectElement*(), fwiw.
Regards-
-Doug
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 that the chief problem with cssQuery*() for me is that it is rather confusing. Such a name would indicate functionality related to CSS (that is, something presentational or style-oriented), rather than the accident of a historical relationship. It totally fails the criteria of being functionally descriptive, which selectElement() meets (other merits notwithstanding); this is a point on which I think we can build consensus and compromise (and hopefully a speedy resolution). 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. Frankly, I'm not a fan of any of the present crop of names, but in the interest of keeping forward momentum, I least object to what we currently have, selectElement*(). Regards- -Doug
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 like you were forced out of the process, and I hope that with time you will participate again. I do feel I was forced out of the process. No, no one has been forced out of the process. If you choose not to participate, it's unfortunate, but it is your choice. Apparently things were decided without informing anyone subscribed on the mailing list. Decisions get made all the time without informing the public list. The decision to create this spec in the first place was not a public decision. Most of the wording and functionality of the spec was the work of a small group of people. Only when an issue is raised does the debate start. Informing people on the decision progress is an essential thing. How could this happen? It should have never happened. It happened through a miscommunication and through an inconclusive decision process. It's unfortunate in my view, but it's not something to lose sleep over, in this case. The issue was voted upon, there was an outcome. No, there was no vote. I was in the room, so I think I would know. The names that were chosen by the group were selected by group process of elimination, not by voting. As it says in the process document [1], "A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock." The keys there are "substantive" and "compromise". This is *not* a substantive issue; the functionality remains the same. And the means by which the names where chosen was a kind of compromise, as is the process going on now. Several people are not thrilled with the new names, but they aren't pressing it further; if you think you can come up with a new name that hasn't been considered, and which you think will satisfy the most or all of the people involved, by all means submit it. This spec is not even in FPWD (First Public Working Draft) yet, nothing is set in stone... but judging from the heat of this debate, I'd say you'd have to come up with a pretty compelling set of names. Now, the opposite is being done of what the outcome was. Actually, that's not true. The new names are a substantial improvement over get() and getAll(), as well as most of the other alternatives. I can't believe that is normal. How often does that happen within the W3C? About as often as you might expect in a loosely-run group of enormous size and of diverse opinions where everyone contributes. You win some, you lose some... I'm personally going to save my energy for something more important to me. [1] http://www.w3.org/2005/10/Process-20051014/policies.html#Votes Regards- -Doug
Re: [selectors-api] The Naming Debate
Hi, Martijn- 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 like you were forced out of the process, and I hope that with time you will participate again. Well, the way I see it is different. There was a vote on it, the editor didn't like it and went his own way. Just to clarify, it's not the policy of the W3C to vote on issues. We conduct strawpolls to judge consensus, which is not quite the same thing. Voting, I think, would create a mess of power blocs and lead to all sorts of divisiveness and rancor. Ideally, striving to get everyone on the same page has a better, more technically sound outcome and promotes cooperation. But it's slow and sometimes frustrating, I agree. Regards- -Doug
Re: [selectors-api] The Naming Debate
Hi, Martijn- Martijn wrote: 2007/6/27, Doug Schepers <[EMAIL PROTECTED]>: I could not agree more with this sentiment. I know of no reason this issue should have been reopened, since there was no new evidence. But ultimately, it is not that important, which makes it all the more frustrating that it was reopened and effort was wasted. Yeah, this is a "me too". However, I do think this is important. So basically, I'm just really unhappy about this. Just posting a new proposal, without even mentioning about what was decided before, it's just very frustrating to me :( I feel being treated very unfairly :( I understand and sympathize with your frustration. But I'd ask you to consider the relative weight of the importance of the naming convention. In my view, it is far more important that this API be specified and implemented (and made available to authors) than to continue the debate about names. Considerable energy has already been invested in this debate, and though the outcome is not what I'd have thought best, the mere fact of the names being (in my view) suboptimal doesn't change the underlying functionality. > However, and for the sake of progress, we will go along with the new > decision taken in consensus by the WebAPI WG. That's very gracious of you. It's important that we use consensus to move forward, rather than to block progress. Well, I won't "block any progress" from now on :( I didn't imply that dissent blocks progress. If anything, I contend that reopening an issue that was closed by the group had the potential to block progress, and that the editor is fortunate that others have not sought to press the issue. That some people were not happy with the naming convention decided by the group was insufficient cause to reopen the issue, since an equal number of people are now unhappy with the new names; it's worth saying that consensus is not the same as unanimity, but is a process whereby people decide the manner in which they will cooperate toward a mutually beneficial end. Regards- -Doug
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 moving forward. I could not agree more with this sentiment. I know of no reason this issue should have been reopened, since there was no new evidence. But ultimately, it is not that important, which makes it all the more frustrating that it was reopened and effort was wasted. However, and for the sake of progress, we will go along with the new decision taken in consensus by the WebAPI WG. That's very gracious of you. It's important that we use consensus to move forward, rather than to block progress. Regards- -Doug
Re: Comments on element traversl specification (multiple responses)
Hi, Ray- I think you have attributed to malice what can more accurately be attributed to ignorance. I apologize if I unintentionally gave you the impression that I was dismissing your use case, when what I was trying to do was give you an opportunity to suggest a new API that addresses it, since it is (as you agree) out of scope for ElementTraversal. Maybe I simply didn't correctly understand what you're trying to accomplish, since (as I admitted), I've never encountered your use case. By the same token, I'd ask you to adopt a less accusatory tone, and to assume all parties are acting in good faith. You catch more flies with honey than with vinegar. Replies inline... Ray David Whitmer wrote: Doug Schepers wrote: I'm sorry that the ElementTraversal Spec doesn't meet your needs. What you are describing seems to be a sort of mixed-content processing/clean-up functionality, not "element traversal". I have no idea how common this use-case is; I've never encountered it myself, but maybe it's really common in mash-ups? If it's common enough, and if the code to deal with it is difficult to write, hard to maintain, too slow, or is otherwise problematic, perhaps we should consider writing different specification to address that. Do you think that's the case, or are do your own utility functions do the job correctly? You have significantly mis-characterized the use case. So let me make my own characterization of the API model, which obviously are free to disagree with: The API approaches the problem of element processing in an attitude that doesn't care if there happens to be text chunks floating around in your element content. Correct. I find this slip-shod, and part of a wider set of attitudes responsible for the state of markup content on the internet not being interoperable or accomplishing what the authors set out to do. I honestly fail to see how. But enough people program that way that you will probably find a willing audience who says, yes, that is exactly what I want, because content is slip-shod on the internet due to browsers that allow you to get away with anything and interpret it one way or the other. Browsers do tend to be forgiving, but again, I'm not sure how an API that skips over non-element nodes would contribute to this. There were exactly two cases I mentioned: 1. processing element content (with error reporting when it turns out to not be mixed content, which should never be out of scope, unless content is prevalidated) It's become clear to me that I may not understand what you mean by this, and why you feel it is of such importance. I gave you an example to try to illustrate my point; did that not represent what you're addressing? If not, I'd appreciate a concrete example. If I have misunderstood you (as it seems I may), perhaps there is a place for it in this spec (though I admit I am skeptical). Either way, it will be good to get on the same page. 2. processing mixed content with an extra optional argument (which I admitted might be out of scope, and I was and am happy to stop discussing). I do believe this to be out of scope. My first and most important use case is simple element traversal, of the most-common sort, and your attempts to characterize it otherwise is not justifiable. What the API describes allows accidental traversal of mixed content when you intended to process element content, which is seldom, in my experience, what anyone actually wants because non-whitespace content is always relevant, even if you thought you were processing element content -- enough that I would recommend that no one attempting traversal of element content use the API. Again, I think an example would clear this up for me. Yes, I can perform element processing today by making my own utility functions. It is not because I am solving different problems, I believe, but because I insist on tighter processing and not silently ignoring chunks of text that happen to be floating around in the content I am processing. ...while this API is designed to do exactly that: ignore any content that is not an element. If I didn't make that clear in the spec, can you point to what gives any other impression? When I mentor people on processing XML content using APIs, I will continue to characterize an API such as yours as slipshod because it ignores significant chunks of stuff that should seldom be ignored floating around in the input stream, but whatever you like, you will ultimately get. A responsible specification of an API of this sort would at least warn people of this problem. Why do you think it shouldn't be ignored? You've said that a few times now, but you haven't offered a concrete example of something that is relevant to iterating through element nodes. As was mentioned before, even though this API only allows you to step
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 se (that is, where elements are themselves the content, and are not primarily used to encapsulated text content). Of course, there are uses in HTML as well, where most elements are in fact marking up text content (for example, it might be used to walk a collection of elements, while ignoring any whitespace or comments between them)." Response: If SVG can always count on the content having been validated so that there is never any significant mixed content floating around in what should have been element content, I accept that it was not intended to be useful enough for general processing of element content, and this is just an SVG-centric spec I should not expect to find useful. Again, it's not SVG-centric; it will work in any language, including HTML. It happens to be most useful in a language where a large proportion of the content is elements (as one might expect in an element traversal specification). It does not rely on SVG having been validated. SVG's rendering model is such that any text (including comments) that is not contained in a text content element (such as 'text', 'tspan', 'textPath', etc.) is not rendered. For example, the following fragment causes no problems for SVG: xmlns:xlink='http://www.w3.org/1999/xlink'> This is junk, so it shouldn't be rendered. This is not junk, so it will be rendered. In this case, ElementTraversal will only ever "see" the and elements, ignoring the others. As you say, this to be the most common use case for traversing elements. You are correct that it is not meant to be used for "general processing" of mixed-content, but rather the optimized navigation of element content (thus "element traversal"). But for my purposes, any API like this would at least have to be able to raise an exception or otherwise easily detect the (erroneous) presence of non-element content, or it is of no use to me, since I generally do not rely on pre-validated XML and it is essential for the application to reject things that are so obviously wrong with the content like having chunks of text sitting where they should not be. So, I continue to rely on my own methods for easy element traversal. I'm sorry that the ElementTraversal Spec doesn't meet your needs. What you are describing seems to be a sort of mixed-content processing/clean-up functionality, not "element traversal". I have no idea how common this use-case is; I've never encountered it myself, but maybe it's really common in mash-ups? If it's common enough, and if the code to deal with it is difficult to write, hard to maintain, too slow, or is otherwise problematic, perhaps we should consider writing different specification to address that. Do you think that's the case, or are do your own utility functions do the job correctly? Regards- -Doug
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 reasonable with skipped intervening content, which it could do with little disruption. For my purposes, if the application is processing element content, it needs to raise an error if non-whitespace text is found. If it is processing mixed content, it needs to pass the skipped content back to the caller. I cannot think of the case where non-whitespace text should ever be silently ignored. 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 se (that is, where elements are themselves the content, and are not primarily used to encapsulated text content). Of course, there are uses in HTML as well, where most elements are in fact marking up text content (for example, it might be used to walk a collection of elements, while ignoring any whitespace or comments between them). As Jonas points out, you can use ElementTraversal in combination with the Node interface (myElem.nextElementSibling != myElem.nextSibling) to achieve more flexible results. It's worth noting that this interface is specified on the Element object, not on the Node object, so it cannot be called from a text node in any case. With respect to other issues: it would be nice to have both Java and ECMAScript bindings, The most recent version of the spec has both bindings. and I think you should not provide a child list attribute in this API (waste of effort). If anyone insists on a better list, make a Java iteratable or a real non-live array, not a non-standard live list interface (like DOM V1), but who really needs it anyway? Not me. In response to feedback, the ChildElementList has indeed been removed. Instead, a childElementCount attribute (an unsigned long) provides the most crucial functionality of ChildElementList while reducing the implementation overhead. Regards- -Doug
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, which could include spaces and line breaks, etc.) that are children of the context element. I suggest leaving this out, because it's not possible to implement both next/previous and indexed access in a way that is efficient for all cases (it's possible to make it fast for most cases but pretty challenging to make it efficient for all). This is especially bad with a live list and an element whose contents may be changing while you are iterating. This is why I suggested making it a static list. If all you care about is looping through once, writing the loop with nextElementSibling is not significantly harder than indexing a list. But that doesn't get you the number of child elements. I'm speaking as an author when I say that this would be extremely useful, particularly (but not only) for SVG. Laying out elements (and thus needing the number of them) is a very common task. Regards- -Doug -- Regards- -Doug Research and Standards Engineer 6th Sense Analytics www.6thsenseanalytics.com mobile: 919.824.5482
Re: ElementTraversal spec draft
Hi-
The issue of live vs. static lists is actually orthogonal to my main
question (though that would be a relevant argument to bring to the
Selectors spec, which uses a static list... I think that ship may have
sailed, though).
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, which could include spaces and
line breaks, etc.) that are children of the context element.
This would be a shorter list (using a bit less memory), would let
authors know the number of elements before stepping into the loop
(preventing them from having to loop twice through the same list to get
that info, which you need to make best use of available space for
positioning and sizing), and would let the authors bypass the irritating
check for nodeType.
Regards-
-Doug
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-intensive, depending on
the exact usage pattern. But maintaining a live list means that you don't
actually have to have anything in the list until someone asks, which in
practice means lower memory overhead for long-ish lists. In fact, even if
someone asks, you could drop the nodes from the list on memory-pressure
notifications, and recreate the list as needed...
Note that live lists can even be a processor win, depending on how the
page accesses them. Gecko only looks through the DOM as little as it can
get away with, so if you do getElementsByTagName("foo")[0] it'll stop
after it finds the fist node. This was actually a huge CPU win over
walking the whole DOM in some cases, in addition to being a memory win.
I guess my issue is that I think that for typical web usage (in my
experience, etc) live lists can actually take up less memory and
comparable CPU... But then again, I've spent a good bit of time on
Gecko's live NodeList implementation to get it to this point. ;)
As a fellow implementor of NodeList (and HTMLCollection and NamedNodeMap),
I'd agree with all that. My implementation is targetted at devices that
have limited CPU power and memory resource. Maintaining live lists is less
overhead, but you just have to be more clever about how you implement those
classes. It is possible to create extremely efficient implementations of
these for slow, memory-limited devices - you just need to be careful about
tree updates. It is also quite easy to create extremely inefficient
implementations :-)
I'd say that the same goes for most of the DOM Core levels 1 and 2, and DOM
HTML Level 2 interfaces.
P.S. The Gecko implementation _is_ open-source and algorithms aren't
subject to copyright last I checked, so anyone who wants to set up things
similarly can. They'll need a notification infrastructure, but they need
that anyway to handle changes to the DOM, I would think.
Aren't those DOM events handy? Just what you need to keep these data
structures up to date. It sounds like you do exactly the same as me :)
--
Regards-
-Doug
Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482
Re: ElementTraversal spec draft
Hi, Bjoern-
I don't think that your solutions address the use case I was pushing
for. I will present my counterargument, but just for the sake of moving
the spec along, I will most likely drop this feature unless I get
indication of support otherwise.
Bjoern Hoehrmann wrote:
* Charles McCathieNevile wrote:
@@issue: should we add a childElements attribute
that returns a list of elements?
No! You can easily do this with
for (child = element.firstElementChild;
child;
child = child.nextElementSibling)
array.push(child);
for (var i = 0; i < array.length; ++i)
...
That forces the author to use a 2-pass solution at JS speeds, rather
than at compiled-code speed (and footprint).
I do not see why you would do that though. Further, you can about as
easily do this using DOM XPath, XPath selectNodes, the CSS Query API,
DOM Level 2 Traversal, you can in fact just use Core like
for (var i = 0; i < element.childNodes.length; ++i)
if (element.childNodes[i].nodeType == 1)
...
well you would really use
for (child = element.firstChild;
child;
child = child.nextSibling)
if (child.nodeType == 1)
...
Counting is trivially implemented on top of these, or you can just
use XPath "count(*)".
In what browser?
I understand a primary concern why SVG Tiny 1.2
did not have many of the DOM Core features is because the NodeList
interface was regarded as expensive. And having childNodes live and
childElements not live would add considerable confusion. No need for
an alias for element.selectNodes("*") and element.cssQuery("*").
I doubt that smaller devices will implement those interfaces. We'll see.
As a comment on the draft, you have to define how the method behave
in case of unexpanded entity references and entity replacement markup.
I've explained this in a little bit more detail on www-svg at some
point.
As discussed on IRC, I'll post my suggested handling of this situation
in the next draft. I'd appreciate further feedback then.
Regards-
-Doug
