W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: backdrop for fullscreened elements and modal dialogs/lightboxes

From: Edward O'Connor <eoconnor@apple.com>
Date: Tue, 29 Nov 2011 13:02:02 -0800
To: www-style@w3.org
Message-id: <m2wraiej79.fsf@eoconnor.apple.com>
Hi,

roc wrote:

>> * the only parts of the document that are visible are the element and
>> its descendents
>
> I don't think [this] item is correct. In the current fullscreen
> proposal, the rest of the document can be visible behind the
> fullscreen element. I don't see what else background:transparent on
> the fullscreen element could mean.

At the moment, there are no normative statements in the Fullscreen API
spec that claim the rest of the document can be visible behind the
fullscreen element. This is a good thing! The *element* requests to go
fullscreen, not its document. The spec shouldn't preclude implementation
strategies that differ from your own. Having a backdrop behind
fullscreened elements allows us to (literaly) hide such implementation
details, and also makes a variety of other features easier, such as
animating entering and exiting fullscreen.

>> There should be an easy way for the Fullscreen API spec to say
>> something like "the fullscreen element stacks above everything else"
>> without playing z-index tricks or the like[3],
>
> z-index tricks aren't really a problem. The problem is the
> non-compositionality of multiple fullscreen elements or fullscreen
> combined with other "on top of everything else" features like
> <dialog>.

If we specify how backdrops stack together and other such details, and
if the Fullscreen API & <dialog> both make use of this common backdrop,
then the Fullscreen spec should get this "for free" without needing to
presume too many implementation details in its rendering section.

fantasai wrote:

>> 2. In addition, there are some a11y implications that are out of scope
>>     for CSS, such as[…]
>
> This is a good point. This problem would be solved if instead of using
> positioning tricks, the spec defined the fullscreened element as
> occupying its own canvas.

Yeah. At minimum, the spec shouldn't preclude implementing fullscreened
elements in such a way.

>> 3. The rendering section of the Fullscreen API spec currently suggests
>>     using a z-index of 2147483647. :(
>
> This seems like a pretty broken way of speccing something, imho.

Indeed.


Ted
Received on Tuesday, 29 November 2011 21:03:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT