Re: [clipboard] Semi-Trusted Events Alternative
On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com wrote: [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events The default action of a synthetic paste event is to insert any data passed to the event constructor, if that data is suitable for the event target. If the data type is not suitable for the event target, data must not be inserted. Seems wrong. Why is that still in the editor's draft? Dispatching synthetic events should not cause actions. -- http://annevankesteren.nl/
[Bug 26368] Typo: Queue a task to run these subsubsteps
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26368 Philip Jägenstedt phil...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Philip Jägenstedt phil...@opera.com --- Oh, I assumed it was just a typo. I see that there are occurences of the same thing in the HTML spec, so I'll resolve this as invalid. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26440] New: Allow fullscreenchange events to be synchronized with animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 Bug ID: 26440 Summary: Allow fullscreenchange events to be synchronized with animation frames Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#go-fullscreen Tasks are queued to resize the viewport and fire the fullscreenchange event. I would like to synchronize changes to the fullscreen element stack and the events with animation frames, so that any scripts will always see a perfectly consistent state. I wrote about this and other messy things on blink-dev recently: https://groups.google.com/a/chromium.org/d/msg/blink-dev/GLl6aWs9-EM/6Z0IkWgmWJsJ Unfortunately, the way the spec is phrased doesn't seem to allow for this. I propose that instead of using the user interaction task source, any script visible changes and events are tied into the requestAnimationFrame() machinery. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26379] exitFullscreen() should pop from the stack, resize and fire fullscreenchange events together
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26379 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/6bc47c40c2d84938b4a9ea69a3c46800fc2dabe3 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Screen Orientation] Best Practice wording comment
On Fri, 25 Jul 2014, at 14:34, Bruno Racineux wrote: Just took a peak at the latest spec [1], since Chrome Canary breaks my code made for the previous spec and I have to update to a dual screen.orientation object|string context (It was previously a string). Good to see the new 'natural' keyword and angles. 1. One minor comment on the Best Practice 1 box for the phrase: Never assume any kind of relationship between the screen orientation type and the screen orientation angle Any kind seems too strong a statement, since there is a relationship between type and angle during the length of a browsing context/runtime as mentioned afterwards. I suggest adding a permanent relationship qualification and/or cross-devices dimension in that sentence. Fixed: https://github.com/w3c/screen-orientation/commit/d1adfa1b1419d534c8b124331a70c7a322451008 2. I am noting that the definition 1 and 2 of reading current screen orientation type is going to require that IEMobile and iOS change the reporting of their current screen.width and screen.height to the correct orientation, and stop reporting portrait only. I suppose that's a good thing even if it might break a few scripts. Do you mean that they do not update the screen.width and screen.height when the screen rotates? -- Mounir
[Bug 26326] Why fully exit fullscreen when an element is removed?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26326 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/3b2ad1f028b3fc8d69766180fcb0965567d70450 -- You are receiving this mail because: You are on the CC list for the bug.
file writer discontinued?
Hello, As a media-applications developers companies chief developer I am trying to find a way to get involved in the happenings around the html file apis. Could you please give me a tipp where to start finding out why the html5 file writing stuff was discontinued? Thanks and all the Best, Harald Harald Jordan Director Development Email harald.jor...@x-dream-media.com Mobil +43664 88620280 x-dream-media GmbH Höhenkirchener Straße 134 | 85662 Hohenbrunn | Germany Telefon +49-8102-99578-1 | Telefax +49-8102-99578-5 Web http://www.x-dream-media.com/ www.x-dream-media.com Sitz: Hohenbrunn | Register: Amtsgericht München | HRB 206096 | Geschäftsführer: Stefan Pfütze this e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. The targeted timeframes, products, features and/or functionality described herein are estimates only and provided for budgetary purposes, shall not be relied on, may be changed at any time at x-dream-media's sole discretion, and shall not be interpreted as an obligation or deliverable for current or future orders, and shall not be incorporated into any contract. Obligations and deliverables are defined on an independent basis pursuant to the individual contract terms and will default to current performance capabilities. Nothing herein shall create or impose any obligation on the part of x-dream-media. This document contains information that is proprietary and confidential x-dream-media GmbH and is intended for the specific use of the recipient for the express purpose of evaluating x-dream-media products. This document is provided to the recipient with the expressed understanding that the recipient will not divulge its contents to other parties or otherwise misappropriate the information contained herein. © 2013 x-dream-media GmbH. All rights reserved. All information subject to change without notice.
[Bug 26445] New: XMLHttpRequestEventTarget should have Exposed=(Window,Worker)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26445 Bug ID: 26445 Summary: XMLHttpRequestEventTarget should have Exposed=(Window,Worker) Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: b...@pettay.fi QA Contact: public-webapps-bugzi...@w3.org CC: bzbar...@mit.edu, m...@w3.org, public-webapps@w3.org . -- You are receiving this mail because: You are on the CC list for the bug.
Re: [imports] credentials flag bits need to be updated to current fetch terminology
I encountered a pre-release site that uses credentials to protect it from public. Imports in that site failed to load because the UA didn't send credentials. The current behavior solved this problem. There are a couple of options that I didn't take: - Always send credentials: We clearly shouldn't do this as the same reason why XHR doesn't this. - Introduce @crossorigin attribute: This seemed plausible, but I worried that this can be just redundant and hurts brevity if the credential-protected sites are the mainstream. Once a popular FAQ site recommends to put it all the time, that would become bad news. Then send-only-same-origin looked promising way to go. I think following XHR behavior makes sense because it is well understood as it's been there for a long time and both imports and XHR load documents. I'm not super confident about this though. On Sun, Jul 27, 2014 at 4:18 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 22, 2014 at 12:36 AM, Hajime Morrita morr...@google.com wrote: It behaved like that before. I changed it to current one so that it works with credential-protected in-house or staged apps. You'll need to elaborate a bit, I'm not sure I understand. In any event, I think XMLHttpRequest's default behavior of only sending credentials same-origin is somewhat confusing. If we only offer one mode for rel=import we should either always include credentials (and thus require more complicated CORS headers) or never. -- http://annevankesteren.nl/ -- morrita
Re: [Screen Orientation] Best Practice wording comment
On 7/28/14 3:01 AM, Mounir Lamouri mou...@lamouri.fr wrote: I suggest adding a permanent relationship qualification and/or cross-devices dimension in that sentence. Fixed: https://github.com/w3c/screen-orientation/commit/d1adfa1b1419d534c8b124331 a70c7a322451008 Better. Thanks 2. I am noting that the definition 1 and 2 of reading current screen orientation type is going to require that IEMobile and iOS change the reporting of their current screen.width and screen.height to the correct orientation, and stop reporting portrait only. I suppose that's a good thing Do you mean that they do not update the screen.width and screen.height when the screen rotates? Correct, IEMobile and iOS browsers always report the portrait values. Chrome mobile fixed that at version 18. It's been documented by ppk: http://www.quirksmode.org/mobile/tableViewport.html Perhaps you could enforce that fix by being even more explicit such as: 1. If the 'screen.width' is greater than the 'screen.height', return landscape-primary or landscape-secondary. The portrait only behavior is error prone, and need to be corrected.
Re: file writer discontinued?
On 7/26/14 3:40 PM, Harald Jordan harald.jor...@x-dream-media.com wrote: As a media-applications developer¹s companies chief developer I am trying to find a way to get involved in the happenings around the html file api¹s. Could you please give me a tipp where to start finding out why the html5 file writing stuff was discontinued? Decision note: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0010.html Or you may search the archive for related mails: http://www.w3.org/Search/Mail/Public/search?keywords=FileWriterhdr-1-name=s ubjecthdr-1-query=index-grp=Public_FULLindex-type=ttype-index=public-web apps
