Re: Charter addition proposal: screen orientation lock
On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon ro...@berjon.com wrote: ... I will let implementers speak for themselves, but my understanding is that there is interest in this feature. It is certainly a regular request from developers. In previous discussions we haven't hashed out who would stand up as editor and test facilitator, but I'm confident that we can find people. If no one else steps up, I'll take the testing hat. With Robin as test coordinator and Mounir as editor, we seem to have consensus on taking this on as a work item. So I'll add it to the charter draft... cheers Chaals -- 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: Charter clarification: common manifest
On Mon, 30 Jan 2012 17:51:14 +0100, Robin Berjon ro...@berjon.com wrote: On Jan 30, 2012, at 13:38 , Marcos Caceres wrote: On Monday, 30 January 2012 at 21:26, Robin Berjon wrote: It's not something that has happened to date, but I'm hearing indications that there could be interest in quickly aligning on a manifest for web apps (that would I presume differ from the one used in Widgets). Interesting… pointer to these indicators would be nice (or would be nice to hear from WG members). Tobie kicked up some dust here: http://blog.tobie.me/post/14262541286/app-manifests-an-anthology I can't seem to track down pointers right when I need them, but this spurred a fair amount of commentary, including from some people who work for implementers agreeing that the current situation is stupid and needs to be fixed. It would be a shame to close the door right as it looks like it might happen. Agree. However, an alternative serialisation of the Widget's metadata can be specified in the Native Web Apps CG and then a WG home can be found. Sure, I'm happy for the work on this to take place in the NWA CG since that seems like a fit home for it, but it needs a place to be properly standardised. My hope is that this place can be the WebApps WG. Given that the discussion would take place elsewhere, and that the result is pretty much in charter, I would hope that this should be agreeable to all. I'll write it that way into the charter draft. I also hope that it is seen that way by the WG. cheers Chaals -- 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: CfC Re: Charter addition proposal: screen orientation lock
Given the positive responses to this CfC, the Screen Orientation API has now been added to the Additions Agreed section of charter changes wiki http://www.w3.org/2008/webapps/wiki/CharterChanges. On 1/30/12 8:26 AM, ext Charles McCathieNevile wrote: OK, since I was planning to have the charter up today, let's have a quick call for consensus on this. Please reply by end of business Wednesday if you support or object to this - silence will be taken as not explicitly supporting it, and without support it isn't going to get into the draft charter. If it does go there, there will still be opportunities to object but it will be harder to squeeze in. cheers Chaals On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon ro...@berjon.com wrote: Hi all! Sorry for bringing this to the group this late, but it's a topic that's been discussed in other places and that I believe is both useful and mature enough to be ready for standardisation. Some applications are designed in such a way that they only make sense in one device orientation. The archetypical example would be a game that only works in landscape mode, but there are other examples. Right now native apps can support this rather easily, but web apps have been stuck with silly hacks such as detecting that the orientation is wrong and asking the user to rotate. This further leads to trouble when the device itself is used as a controller (e.g. in racing games) as this can sometimes trigger an undesired orientation change mid-game — hardly a user-friendly experience. Note that this is not about system-level orientation lock (which would be fodder for another group) but application-level orientation. Options to address this have been discussed (amongst other places) here: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/f38bb05e66c01a77# There is discussion as to whether this ought to be only an API or if it should use a meta element (which would also give it an API since it could be changed dynamically), with an overall leaning towards the latter. I am rather confident that we should be able to agree on the best approach relatively quickly. I will let implementers speak for themselves, but my understanding is that there is interest in this feature. It is certainly a regular request from developers. In previous discussions we haven't hashed out who would stand up as editor and test facilitator, but I'm confident that we can find people. If no one else steps up, I'll take the testing hat. WDYT?
Re: CfC: Charter addition for Fullscreen API
Given the positive responses to this proposal, I added it to the additions agreed section of the charter changes wiki and Chaals will add it to the draft charter. On 1/31/12 11:04 AM, ext Robin Berjon wrote: Hi all, I love deadlines. I love the whooshing noise they make as they go by. In a discussion earlier, it has come to my attention that the Fullscreen API may not currently have a properly chartered home. I somehow thought that it was in the HTML WG but it seems not. Apparently it was on the CSS WG's plate at some point but it seems to have been dropped. If that is indeed the case, we need a home for it. (If it turns out that it does have a home and I simply couldn't figure out which one it is, then please consider this CfC as null and void.) We have a draft, I'm pretty sure that I've seen implementer interest, and it's very obvious that there's a lot of developer interest in it. My understanding is that it has an editor. WDYT?
[Bug 15901] Create Participate: box at top of the specification
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15901 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Ms2ger ms2...@gmail.com 2012-02-06 14:13:46 UTC --- Thanks, fixed. https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/f739d400ea72 -- Configure bugmail: https://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 15916] New: DOMParser Document origin
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15916 Summary: DOMParser Document origin Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The origin of a Document created through DOMParser needs to be defined. -- Configure bugmail: https://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: Encoding Spec and Encoding for readAsText
Anne, On Thu, 26 Jan 2012 22:57:35 +0100, Arun Ranganathan aranganat...@mozilla.com wrote: Few quick questions: 1. Can you review: http://dev.w3.org/2006/webapi/FileAPI/#encoding-determination I think per https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359 we want to let the BOM checking happen before the other considerations. Really? Does that mean, favoring BOM checking over the Blob's type attribute and the optional encoding parameter of the readAsText() method? Why exactly? 2. How can I best coordinate this with the Encoding Specification that you are working on? I think eventually we want to update the text to no longer make use of the IANA registry (which is open ended) and just directly defer to the Encoding Standard (which only supports a fixed list of encodings). Got it -- I'll look to you for the cue about when to do this. -- A*
Re: [XHR] setRequestHeader and redirects
On Sat, 02 Jul 2011 10:13:25 +0200, Anne van Kesteren ann...@opera.com wrote: On Sun, 26 Jun 2011 16:46:23 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/25/11 2:23 PM, Anne van Kesteren wrote: So each specification that deals with custom headers of some kind (e.g. EventSource has Last-Event-ID and Cache-Control) needs to say what happens to them in the face of redirects? On the face of it, yes. Especially because different redirect response codes have different semantics (well, in theory), so some headers may need to be preserved across some of them but not others. And without knowing the meaning of the header, it's impossible to say when it should be preserved across the redirect and when it only makes sense in the context of the original request. I raised this with the HTTP WG: http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0489.html It seems they are going to do something about it: http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0490.html I guess we should evaluate again when that is done. This ended up coming back to us. HTML fetching will hopefully address this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15228 -- Anne van Kesteren http://annevankesteren.nl/
[Bug 15917] New: prueba de uso de web broker
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15917 Summary: prueba de uso de web broker 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: Web Workers (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/workers/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: prueba de uso de web broker Posted from: 189.186.12.113 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7 -- Configure bugmail: https://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 15917] prueba de uso de web broker
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15917 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID --- Comment #1 from Art Barstow art.bars...@nokia.com 2012-02-06 21:52:59 UTC --- English: proof of use of web broker -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
April face-to-face meetings for HTML and WebApps
Folks, in order to facilitate the work of the WebApps and HTML Working Groups, I've been discussing with the Chairs the idea of having a face-to-face in the silicon valley in April. Due to various constraints (WWW2012 and Google I/O most notably), I ended up with the second week of April: - WebApps WG: April 10/11 (Tuesday/Wednesday) - HTML WG: April 12/13 (Thursday/Friday) - WebAppSec: April 11/12 (Wednesday/Thursday) Is anybody else aware of other potential conflicts? The WebKit contributor meeting dates are not set yet but may overlap with webapps for one day (April 10)... I asked the Chairs to ask for objections to those dates as well, Note that this meeting would be in addition to the TPAC 2012 in November (Lyon, France). Thank you, Philippe
