Re: [whatwg] Fullscreen CSS

2011-11-28 Thread Edward O'Connor
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.

Re: [whatwg] Fullscreen CSS

2011-11-28 Thread João Eiras
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

Re: [whatwg] Fullscreen CSS

2011-11-16 Thread Edward O'Connor
Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking

Re: [whatwg] Fullscreen CSS

2011-11-16 Thread Robert O'Callahan
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor eocon...@apple.com wrote: It seems like we shouldn't assume that these are the only two features that will ever need this sort of rendering support. I'll get a www-style thread going. Thanks. If multiple specs (or even multiple running

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Robert O'Callahan
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Having the rest of the page visible under the fullscreen element is not expected and I think we should default to avoiding it. background:black seemed like the right thing for video and a reasonable default for other

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Tab Atkins Jr.
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Having the rest of the page visible under the fullscreen element is not expected and I think we should default to avoiding it.

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Anne van Kesteren
On Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren ann...@opera.com wrote: I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Boris Zbarsky
On 11/15/11 11:25 AM, Anne van Kesteren wrote: UA does not have an important level. In Gecko it actually does: it's a level that overrides the user important level. Such a level is sort of needed in some cases, no matter what you actually choose to call it. -Boris

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Robert O'Callahan
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

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Tab Atkins Jr.
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.com 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

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Robert O'Callahan
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The

Re: [whatwg] Fullscreen CSS

2011-11-14 Thread Tab Atkins Jr.
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, why would it require stacking-level changes?  One obvious way to get it to act correctly is to make it wrap around the element, like