Re: backdrop for fullscreened elements and modal dialogs/lightboxes

On Wed, Nov 30, 2011 at 10:02 AM, Edward O'Connor <eoconnor@apple.com>wrote:

> 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.


There are no statements that you can deviate from regular CSS rendering. In
the absence of such statements, I think UAs are required to keep adhering
to CSS. If a browser doesn't show the rest of the document behind a
fullscreen element with 'background:none', then I think it doesn't comply
with CSS + the current fullscreen spec.

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.
>

Nevertheless, if one browser displays a fullscreen document with the whole
document visible and another browser only makes the fullscreen element
visible, we have a serious interop problem that we need to change the spec
to fix.

I certainly want it to be *possible* for elements outside the fullscreen
element to be visible. For example if a page has a floating fixed-pos
toolbar, it should be possible for that toolbar to remain visible when the
page is fullscreen.

> 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.
>

Sure, that could work. Depends on the details :-).

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.
>

The "occupy its own canvas" approach has the problem that we'd need to
carefully study a lot of CSS specs to figure out how they should behave for
an element subtree "occupying its own canvas". For example, how should the
layout of the elements outside the subtree be affected? What should CSSOM
View APIs return for elements inside the subtree? If you have a CSS region
partially inside and partially outside the subtree, and thus elements in
the region that are partially on the main canvas and partially on the "its
own canvas", what happens? etc.

I'm not convinced the "its own canvas" approach ends up being an elegant
solution once you've covered all those details.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]