Re: Proposal to add Mouse Lock to the Web Events Working Group
Hi Vincent, All - given there were no negative comments regarding Vincent's proposal, Doug and I will work toward updating WebEvents' charter to add the Mouse Lock API. Additionally, as indicated in [1], we will also work toward adding the Gamepad API [2] (formerly know as the Joystick API) to WebEvents' charter. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1408.html [2] http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html On 9/15/11 1:52 PM, ext Vincent Scheib wrote: A Mouse Lock API has been under discussion on the W3 public-webapps list Mouse Lock[1] and earlier Mouse Capture for Canvas[2]. The primary goal is to enable use cases such as first person perspective 3D applications. This is done by providing scripted access to mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. I have been working to formalize the discussions into a draft specification[3]. I propose that the Web Events Working Group consider adoption of Mouse Lock for formal specification. Cheers, -Vince 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 3. http://goo.gl/9G8pd Additional discussions: W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754
Re: [whatwg] Web Forms 2 Repetition Model?please reinstate on specification
Matthew Slyman, M.A. Computer Science (Camb) -- Quoting Ian Hickson i...@hixie.ch: We took it out because it was just far too complicated a solution to solve far too narrow a set of use cases. However, there is a lot of ongoing work in this area of research, especially currently in the public-webapps@w3.org group. I encourage you to bring up the suggestion there. Unfortunately, coming up with a declarative solution whose cost-to-usefulness ratio is good enough has proven over the years to be a rather elusive goal. I find this surprising. Unless of course you're trying to create a tool to do everything (in which case you're diving head-first down a rabbit-warren), or otherwise, have already tried that and decided it doesn't work, and therefore decided that it's not worth attempting a solution to any part of this problem. Let's address another potential misconception at the same time. I recently dug up an old archive message from 2004/2005 in which some fellow was talking the repetition model down on the basis that repetition would be programming and declarative models aren't meant to do programming or something to that effect. Repetition isn't truly programming if it isn't Turing-complete. But I get the point, and I would NEVER ask for a declarative solution that would be Turing-complete. Let's look at a case study or two: ===Chemical formulae===: These have had a repetition model for a long time now, which is very simple but very powerful. Like so: Ca(OH)2 [subscript 2 - put superscript figures in for charge if you want.] Nobody has a problem with this. It does the job and it's very powerful. Just powerful enough, yet not so powerful that you end up with 20 different ways to write the same chemical formula (the system is sufficiently restrictive to enforce a common system of notation). It strikes the balance perfectly, and forms a perfect demonstration of the relative advancement of chemistry as compared with many other sciences. The combination of power and simplicity in this system of chemical notation (which closely resembles the basic HTML5 Repetition Model) enables the world of chemistry to get on with their real work without worrying too much about the art of notation, and enable chemists to find prior art easily. ===Linear equations===: A similar case could be made for these. They're a separate class of problems from the much larger set of problems that can be tackled with mathematics in general. You shouldn't put the folks that need real power and freedom in a strait-jacket by forcing them to work with a system designed for linear equations only. Likewise, you shouldn't burden and befuddle the novices and the folks that just need to get a quick linear equation job done, by forcing them to work with a generalised mathematical tool that they're just not trained to handle, and will never be confident using. ===Classes of problems===: For many problems, there is such a thing as too much power. Let's please recognise that we're dealing with two distinct classes of problems here. There is a class of problems that requires a similar approach/solution to what we see in chemical notation (where one only requires a contiguous repetition of a block of HTML, which may or may not include repeatable subgroups), and another separate and much larger class of problems that requires the greater power available in a programming language. The correct solution for the former is a declarative solution like the basic HTML5 Repetition Model. The correct solution for the latter is Javascript or something similar. ===CONCLUSIONS===: We need a declarative solution for HTML repetition, the same way Chemists need a declarative solution for repetition of chemical formulae. Please reinstate the basic HTML5 Repetition Model. The system design as it stood just a few months ago was excellent in my opinion, and not at all in need of major revision if any. -- Matthew Slyman, M.A. Computer Science (Camb)
[cors] Ability to read Access-Control-Expose-Headers
Hi all, Is there a reason that Javascript cannot read the Access-Control-* headers in CORS? In particular I was trying to work around a bug in Firefox [1] that means that .getAllResponseHeaders() doesn't get all response headers for CORS requests. It seems that the nicest way to do this would just be to iterate over the list of simple-response-headers, and the contents of the Access-Control-Expose-Headers header. Unfortunately, I'm not able to read the Access-Control-Expose-Headers header, because it was not exposed in the Access-Control-Expose-Headers header :). In general it seems like a useful introspection mechanism — it would allow applications to distinguish between this header was not set and I am not allowed to read this header. It also seems that it would be useful to be able to read the Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers so that the javascript application can adjust its feature set based on what the server will allow. Conrad [1] https://bugzilla.mozilla.org/show_bug.cgi?id=608735
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, 20 Sep 2011 16:04:29 +0200, Ian Fette (イアンフェッティ) ife...@google.com wrote: With all due respect, I think that if we have to re-charter or create a new working group each time a new API comes up we are all doomed. The overhead of creating and monitoring so many WGs is not appealing to many of us. Agreed - but at the same time if people start doing work that others are doing in another group, so they can do it with different people, we are all doomed. It is generally not a helpful way to get to a common standard. There is a group where the work you're interested in was already agreed as a deliverable. Which to some extent suggests this isn't a new API, it's Yet another API for doing something people knew they wanted to do. Reading this discussion and understanding the issue multiplied out over the people who effectively have to follow the discussion seems far more process overhead than you and MS just joining that group. Even if MS doesn't join, they can (and with all the rest of webapps will be invited to) comment and make an IPR commitment. And as noted, discussing on the same list doesn't guarantee attention from the other subscribers anyway. We are unlikely to stop you holding discussion here, but it would appear that it makes more sense to do it in a group which is already chartered to produce the deliverable. So with all due respect, I suggest that joining DAP and doing the work is an efficient way forward, while carrying on a process discussion here is sidetracking a lot of people whose time could otherwise be spent making technical progress on something. Part of the value of W3C standards, as compared to random spec proposals from a vendor or three, comes from a process that gives many kinds of stakeholders confidence in what that means. Chartering a group with a reasonable scope definition and then doing that work there is part of the way that process works. You could always ask Google's W3C Advisory Committee representative T V Raman to raise the process discussion to the AC forum, where it is directly in scope. The point of this group, DAP, and other WGs is to focus on doing their chartered technical work. cheers On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote: Hi James, thanks for bringing this forward, it is indeed a very interesting approach. On Sep 19, 2011, at 22:27 , James Hawkins wrote: I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. It does fit the goal and scope, but then most web client technology does ;) Where you may run into issues is that it does not fit in the deliverables list. Since that is what members makes their IP commitment on, a new deliverable of non-negligible content might require rechartering. Last time we did that, it wasn't very pleasant. Thankfully, there is already a group that was chartered with Intents (or, in the poetic phrasing of charters, with an API that allows web applications to register themselves as handlers/providers based on data string identifiers and an API that enables other web applications to discover these handlers/providers and gain permission to interact with them — but Intents is what that means): the Device APIs group, http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the bureaucracy and allow us all to just go straight to work. We'd certainly be happy to accept your draft input. The new DAP is meant to be completely flexible in how it is organised. Notably, if you prefer to conduct work on this spec without necessarily getting all the email from the rest of the group we can setup a dedicated Task Force with its own mailing list and chair (if there's a volunteer, otherwise I'll do it). TFs can decide whether they want to have telcons or not. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [XHR2] Blobs, names and FormData
On Sun, 25 Sep 2011 03:22:40 +0200, Charles Pritchard ch...@jumis.com wrote: Are there any objections to adding a Blob serialization method to the FormData interface? I still maintain my objection, yes. It is too soon to make FormData more complicated. Are JavaScript libraries offering the functionality you are proposing? -- Anne van Kesteren http://annevankesteren.nl/
Re: Adding Web Intents to the Webapps WG deliverables
On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. I don't think this claim makes sense. As a developer I have no way to know if 'foo' is used by anyone else on the Internet, but it would be trivial to check http://webintents.org/foo;. But this is a non-problem. In practice, we have plenty of examples of spaces where conflicts don't happen despite not having used long names such as URLs. For example: - rel= values in HTML - element names in HTML - MIME type names - scheme names I believe all of these examples have one or more central name controls. The rel example in particular provides a counter example to using simple uncontrolled verbs: http://microformats.org/wiki/existing-rel-values Multiple naming authorities, layered on wiki, and still messy. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. A wiki is not comparable to the controlled naming systems in the four examples you give above. A wiki is a free for all that works great when there is no money involved. A Web system involving 'share' along with images, audio, and video will have money involved. I think the intent names need a controlled namespace, either centralized like your examples or decentralized as in the original proposal. URLs need not be the format. Note the Firefox extension developers use domain@name format for unique ids. jjb
