[DOMCore] fire and dispatch
For DOM Core Ms2ger and I (and some others on IRC) decided to introduce a subtle distinction between fire and dispatch. Dispatching is actually going through the list of event targets with an initialized event whereas firing is initializing the event and then dispatching it. E.g. a specification can say fire an event named x and DOM Core defines that to mean that you create an event of type Event, that all its flags are unset (unless specified otherwise), apart from its trusted flag which is true (when a specification says to dispatch an event it is trusted), that its name is x, etc. and that after you have initialized it in that way it is then dispatched. We chose fire because HTML (and some other specifications, now including XMLHttpRequest and Progress Events) already use it in that way and because the more proper initialize and dispatch was thought to be too long for frequent use. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes rbar...@bbn.com wrote: Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
On Thu, 24 Feb 2011 14:43:47 +0100, Richard L. Barnes rbar...@bbn.com wrote: On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. With Sec-* only the client needs to be aware of the tricks. The server can simply trust the values because it can never get spoofed secure headers from compliant clients. -- Anne van Kesteren http://annevankesteren.nl/
[FileAPI] FileError and FileException should be available in workers
The File API spec should say that FileError and FileException interface objects must be available when the global object is a WorkerGlobalScope object. -- Simon Pieters Opera Software
Re: [XHR2] Feedback on sec-* headers
On 24.02.2011 15:00, Anne van Kesteren wrote: On Thu, 24 Feb 2011 14:43:47 +0100, Richard L. Barnes rbar...@bbn.com wrote: On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. With Sec-* only the client needs to be aware of the tricks. The server can simply trust the values because it can never get spoofed secure headers from compliant clients. As long as the server relies on the request being sent by XmlHttpRequest, right? Use a different type of client, and the header fields could be sent... BR, Julian
Overview of W3C technologies for mobile Web applications
(bcc to public-html and public-device-apis; please follow-up on public-webapps) Hi, As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html It is meant as a picture of the current state as of today, based on my own (necessarily limited) knowledge of the specifications and their current implementations. I'm very much looking for feedback on the document, the mistakes it most probably contains, its overall organization, its usefulness. I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. I'll likely publish regular updates to the document (e.g. every 3 months?), esp. if it helps sufficiently many people to understand our current ongoing activities in this space. Thanks, Dom 1. http://mobiwebapp.eu/
Re: [XHR2] Feedback on sec-* headers
On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes rbar...@bbn.com wrote: Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. --Richard
RE: Overview of W3C technologies for mobile Web applications
Hi Dom, It looks quite nice as a way to organize a large lot of information. I'm sure I will be making use of this often as I seem often to get confused by the number of W3C projects on going and the proper jurisdiction as specific concerns may arise. A couple of quick reactions: I'm not sure I see a place for time-series data such as covered in InkML. InkML is very interesting for data visualization efforts, particularly with regard to animation and geolocation. I also don't see MathML anywhere, or has no one yet attempted it in the mobile environment? Just a couple of quibbles from the SVG perspective: There are a few places in the table where specific functionalities have been broken out and assigned to some technology, where, depending on one's purposes another technology might be preferred. For example: rounded corners, complex background images and box shadow effects are just as well the purview of SVG as of CSS, at least in my mind, though admittedly the applicability from CSS (to either HTML or SVG or MathML. Is someone likely to look at this table to get advice on where to turn to accomplish a given effect? If so, then pointing them in more than one direction might be useful. Under animations in your table, it seems like both SVG/animation and SMIL should be listed in addition to CSS. The SVG/SMIL animate module is probably more mature, widely implemented, and powerful than the CSS business. In discussion of fonts, SVG fonts has a more powerful model than WOFF, allowing broader extensibility as well as interactive fonts (defined dynamically in the browser). While they are downloadable (as in bundle-able in one's document) they need not be, and are hence of greater potential utility to the mobile community. Under Image Video analysis and modification, you mention SVG filters in the discussion at top, but in the table, only HTML Canvas/2D Context is mentioned. What if someone only looks in the table to find the row that they are interested in, and concludes aha! this must be the way to filter video? It looks as though your table attempts to provide a one-to-one mapping from functionality to Working Groups, but the proper relationship may be one-to-many owing to the zeal of some of the working groups. One other comment: much of what you've listed here is just as relevant to the browser community as to the mobile community. Would a minor expansion of scope and effort suffice to make a roadmap that is relevant to both? Regards David -Original Message- From: public-html-requ...@w3.org [mailto:public-html-requ...@w3.org] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, February 24, 2011 10:04 AM To: public-webapps Subject: Overview of W3C technologies for mobile Web applications (bcc to public-html and public-device-apis; please follow-up on public-webapps) Hi, As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html It is meant as a picture of the current state as of today, based on my own (necessarily limited) knowledge of the specifications and their current implementations. I'm very much looking for feedback on the document, the mistakes it most probably contains, its overall organization, its usefulness. I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. I'll likely publish regular updates to the document (e.g. every 3 months?), esp. if it helps sufficiently many people to understand our current ongoing activities in this space. Thanks, Dom 1. http://mobiwebapp.eu/
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Wednesday, February 23, 2011 8:21 AM, Arthur Barstow wrote: Anne and Ms2ger (representing Mozilla Foundation) have continued to work on the DOM Core spec and they propose publishing a new Working Draft of the spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html As such, this is a Call for Consensus (CfC) to publish a new WD of DOM Core. If you have any comments or concerns about this proposal, please send them to public-webapps by March 2 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. I think the document should have a clearly stated goal relative to DOM L3 Events. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html
Re: Overview of W3C technologies for mobile Web applications
Hi Dom, This is really helpful - thanks for making this! (I'm also working on some EU research projects, and I keep mentioning W3C specs which no-one else has heard of, so this is a good resource to point researchers and developers at.) I think a 3-monthly update would also be worth doing given the pace of new spec work going on. S On 24 Feb 2011, at 15:03, Dominique Hazael-Massieux wrote: (bcc to public-html and public-device-apis; please follow-up on public-webapps) Hi, As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html It is meant as a picture of the current state as of today, based on my own (necessarily limited) knowledge of the specifications and their current implementations. I'm very much looking for feedback on the document, the mistakes it most probably contains, its overall organization, its usefulness. I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. I'll likely publish regular updates to the document (e.g. every 3 months?), esp. if it helps sufficiently many people to understand our current ongoing activities in this space. Thanks, Dom 1. http://mobiwebapp.eu/
Re: [workers] Moving the Web Workers spec back to Last Call WD
Hi Ian, All, Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. Are there any objections to doing the above? -Art Barstow On Feb/14/2011 5:18 AM, ext Ian Hickson wrote: On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Web Workers spec [ED] as a new Last Call Working Draft ... Bugzilla shows one open bug [Bugs]: 11818 - As documented in the Creating workers section, a worker *must* be an external script. http://www.w3.org/Bugs/Public/show_bug.cgi?id=11818 What high priority work must be done such that this spec is ready to be re-published as a new Last Call Working draft? None, to my knowledge. The bug above is a feature request. In particular, what are the proposals, plans and timeline to address the above bug? I expect to address the issue of supporting data: URL scripts in workers at the same time as adding the ability to do cross-origin shared workers, currently estimated to be in 6 to 18 months, depending on browser implementation progress on other features in the same timeframe. HTH,
Re: [eventsource] Moving Server-sent Events spec back to Last Call
Hi Ian, All, Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. Are there any objections to doing the above? -Art Barstow On Feb/14/2011 5:22 AM, ext Ian Hickson wrote: On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Server-sent Events spec [ED] as a new Last Call Working Draft ... 1. 11835 - EventSource must support cross-domain requests (ala CORS) http://www.w3.org/Bugs/Public/show_bug.cgi?id=11835 This will be supported once CORS is more widely deployed and understood by content developers. At a guess, 9 to 24 months. 2. 11836 - Don't specify the transport, just specify API and protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836 It's not clear to me what problem this bug describes, so I cannot currently give a timeline for its resolution. Discussion is ongoing. HTH,
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] FileError and FileException should be available in workers
On 2/24/11 9:19 AM, Simon Pieters wrote: The File API spec should say that FileError and FileException interface objects must be available when the global object is a WorkerGlobalScope object. Simon: duly noted. -- A*
Re: CfC: publish a new Working Draft of DOM Core; comment deadline March 2
I support this publication. - Maciej On Feb 23, 2011, at 8:20 AM, Arthur Barstow wrote: Anne and Ms2ger (representing Mozilla Foundation) have continued to work on the DOM Core spec and they propose publishing a new Working Draft of the spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html As such, this is a Call for Consensus (CfC) to publish a new WD of DOM Core. If you have any comments or concerns about this proposal, please send them to public-webapps by March 2 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Art Barstow
Binary data in WebSockets API (was RE: [Bug 12102] New: WebSocket protocol update time)
As we've been updating our WebSockets prototype [1] in line with the latest protocol changes we've been thinking about how the binary support that the protocol now includes should be reflected in the API. I added the following comment to the bug: At Microsoft, we've been reviewing how the binary support now enabled by the WebSocket protocol might be exposed in the API. In line with Ian's notes in this bug, we'd like to see the send() method accept a Blob argument that indicates to the API that a binary message should be sent. The existing definition with a string should send a text message. Implementations can decide how they choose to break up the message into intermediate frames since this isn't exposed to the API. On the receiving side, we think that the event.data attribute should contain a Blob if the message was a binary message and a remain as a string for text messages. Since MessageEvent already defines data to be of type 'any', the change here would be to describe the semantics of text vs. binary messages in section 5 of the spec. For the send method, we'd expect an overload of send in section 4 as follows: void send(in Blob data); We'd be interested to hear how others have been thinking about this. Thanks, Adrian. [1] http://html5labs.interoperabilitybridges.com/prototypes/available-for-download/websockets -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of bugzi...@jessica.w3.org Sent: Wednesday, February 16, 2011 5:52 PM To: public-webapps@w3.org Subject: [Bug 12102] New: WebSocket protocol update time http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 Summary: WebSocket protocol update time Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: i...@hixie.ch QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org * onclose should have unsigned int reasonCode and DOMString reasonMessage. * readonly attribute DOMString extensions; // ianf will provide a hook * send() takes some sort of binary argument and * onmessage event.data exposes binary data * check through http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol to make sure the hooks still work -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10381] [IndexedDB] Structured clones should be created synchronously
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10381 Pablo Castro pablo.cas...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Pablo Castro pablo.cas...@microsoft.com 2011-02-25 00:20:00 UTC --- I was just looking at the current state of the spec that this is no longer an issue. The current text explicitly separates the creation of clones from the execution of the steps to asynchronously add or update objects, effectively addressing the issue that made us open this bug in the first place. So I'm resolving this. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 11552] We should remove timeout from IndexedDB.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11552 Jeremy Orlow jor...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Thursday, February 24, 2011 2:37 PM, Anne van Kesteren wrote: On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. Of course it's true that the status doesn't imply everyone agrees with everything and I'm okay with that but heartbeat working drafts are intended to show forward progress and this feels like a retrograde step to me compared to the previous draft. This should be updated to reflect the discussions for ISSUE-171 and ISSUE-172. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Since DOM L3 Events is further along and likely to track faster than this spec it would be reasonable to refer to this. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. If this is your intent then it would be helpful to include a note in the draft making this clear so people know to give this kind of feedback. Otherwise it is just confusing to see it defined in two different places. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Thanks for your consideration, Adrian.
[Bug 12179] New: We should spec the order in which version change events fire
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12179 Summary: We should spec the order in which version change events fire Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should spec the order in which version change events fire. Right now it's just stated they should fire, but it's possible some implementations will depend on one event listener getting the signal first. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: publish a new Working Draft of DOM Core; comment deadline March 2
Hi, Anne- I object to publishing a Working Draft of the DOM Core spec that includes DOM Events. Introducing conflicting specifications that cover the same materials dramatically harms interoperability, and the idea of competing specifications is an anti-pattern when it comes to standardization. If there are changes that you want to the DOM3 Events spec, and if you get the support of the browser vendors to make those changes, then I am happy to change the spec; I'm not married to the spec as it exists, but that is the result of what the last few years of discussing it with the browser vendors and users has resulted in. Please simply raise the individual issues on the www-dom mailing list for discussion. So far, I've seen no support on the list for adding events to DOM Core. Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events in parallel, we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history. So, in summary: please remove section 4, Events, from DOM Core before publishing it as a Working Draft, for now. After serious discussion, if the group agrees, we can always add them back later, but I would prefer to change DOM3 Events to seeing conflicting specifications. Regards- -Doug Schepers W3C Team Contact, SVG, WebApps, and Web Events WGs Anne van Kesteren wrote (on 2/24/11 5:37 PM): On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html
Re: several messages
On Thu, 24 Feb 2011, Arthur Barstow wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. On Thu, 24 Feb 2011, Arthur Barstow wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. I'll defer to Tab for these. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: several messages
On Thu, Feb 24, 2011 at 5:46 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 24 Feb 2011, Arthur Barstow wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. On Thu, 24 Feb 2011, Arthur Barstow wrote: Given the information below, I think it would be useful to move this spec to a test-ready state. That is, publish it as a Last Call Working Draft now and if there are known issues, document them in the Status of the Document Section. Then, after a fixed review period, if no substantial changes are agreed, the spec can be moved to Candidate Recommendation and work on a test suite can begin. Naturally, if major changes are agreed, the spec will need to return to Working Draft. I'll defer to Tab for these. I'll do the necessary edits for publishing tomorrow. ~TJ
RE: Overview of W3C technologies for mobile Web applications
Hi Dom, This looks like a very useful document. On the voice/multimodal side, in addition to the HTML-Speech XG, you will definitely want to add some of the Voice Browser Working Group and Multimodal Interaction Working Group specs, specifically: 1. Multimodal Architecture and Interfaces, for integrating multiple modalities into an application http://www.w3.org/TR/mmi-arch/ 2. InkML for representing traces from pointing devices (stylus, finger, mouse) http://www.w3.org/TR/InkML/ Also see an interesting prototype for displaying and capturing traces in a web browser at http://lists.w3.org/Archives/Public/www-multimodal/2011Feb/0004.html 3. EMMA for representing user inputs from different modalities (for example, speech, ink, haptics, biometrics) http://www.w3.org/TR/emma/ 4. VoiceXML (especially VoiceXML 3.0) for speech interaction http://www.w3.org/TR/voicexml30/ Regards, Debbie Dahl -Original Message- From: public-html-requ...@w3.org [mailto:public-html-requ...@w3.org] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, February 24, 2011 10:04 AM To: public-webapps Subject: Overview of W3C technologies for mobile Web applications (bcc to public-html and public-device-apis; please follow-up on public-webapps) Hi, As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html It is meant as a picture of the current state as of today, based on my own (necessarily limited) knowledge of the specifications and their current implementations. I'm very much looking for feedback on the document, the mistakes it most probably contains, its overall organization, its usefulness. I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. I'll likely publish regular updates to the document (e.g. every 3 months?), esp. if it helps sufficiently many people to understand our current ongoing activities in this space. Thanks, Dom 1. http://mobiwebapp.eu/
Re: [DOMCore] fire and dispatch
On 2/24/11, Anne van Kesteren ann...@opera.com wrote: For DOM Core Ms2ger and I (and some others on IRC) decided to introduce a subtle distinction between fire and dispatch. Dispatching is actually going through the list of event targets with an initialized event whereas firing is initializing the event and then dispatching it. E.g. a specification can say fire an event named x and DOM Core defines that to mean that you create an event of type Event, that all its flags are unset (unless specified otherwise), apart from its trusted flag which is true (when a specification says to dispatch an event it is trusted), that its name is x, etc. and that after you have initialized it in that way it is then dispatched. OK. Why not expose a generic version of `fire` to the scripting environment? -- Garrett
[Bug 12180] New: give the name of url to download the Jetty server
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12180 Summary: give the name of url to download the Jetty server Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: give the name of url to download the Jetty server Posted from: 112.121.55.5 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
