Re: [whatwg] Using requestFileSystem to setup mounts
On Mon, Nov 28, 2011 at 9:18 AM, Kinuko Yasuda kin...@chromium.org wrote: On Wed, Nov 23, 2011 at 1:58 AM, Glenn Maynard gl...@zewt.org wrote: This would lead to interop problems if it's not consistent, though. For example, if my application creates ZIP files, and the user drags two files into the root directory of the ZIP, he wants to put those files at the top of the ZIP: /file1.txt /file2.txt If the UA creates a virtual directory for that drag, then it'd end up putting the files in a subdirectory with the name of the virtual directory, as if a directory was dragged: /drag-and-drop/file1.txt /drag-and-drop/file2.txt The UA can simply puts the file1.txt and file2.txt in the virtual 'root' directory if Entry.fullPath matters. The problem is that a drop event with two separate files will probably be treated differently by some software than one with a single directory containing two files. That'll be true no matter what Entry.fullPath is set to. That's why it'd be an interop problem if some browsers do this and some don't. (I don't think the value of Entry.fullPath is very important for drops. It can probably just be /.) -- Glenn Maynard
Re: [whatwg] Fullscreen CSS
Robert O'Callahan wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes[…] Also, it doesn't address situations where[…] (and maybe other things I've forgotten). Yeah, I'm sure I missed lots of potential issues in the initial ::cover proposal. Please follow up on the www-style thread linked to below! :) I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it Exaclty. I've made a proposal for a backdrop feature, for the Fullscreen API and dialog, here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0705.html Ted
Re: [whatwg] Fullscreen CSS
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. This proposal seems like will make fullscreen styling non-transparent and non-trivial. Currently the elements are just resized and that very easy to implement, understand and workaround with CSS. How would that affect, for instance, a canvas element that is resized to fit the whole screen ?
[whatwg] Fullscreen and keyboard focus.
Hi. Perhaps keyboard focus should be limited only to the fullscreen element or its descendants. If you have a canvas or video fullscreen, alt-tabbing can move the focus outside the fullscreen element, say into form elements. But then this would require giving focus, and dispatching focus events, if the focused element is not inside the fullscreen element subtree.
Re: [whatwg] Fullscreen and keyboard focus.
On Tue, Nov 29, 2011 at 6:25 AM, João Eiras jo...@opera.com wrote: Hi. Perhaps keyboard focus should be limited only to the fullscreen element or its descendants. If you have a canvas or video fullscreen, alt-tabbing can move the focus outside the fullscreen element, say into form elements. But then this would require giving focus, and dispatching focus events, if the focused element is not inside the fullscreen element subtree. I agree. (There's a WebKit bug for this: https://bugs.webkit.org/show_bug.cgi?id=69698)
