[whatwg] Fullscreen changes to support <dialog>
Ian Hickson
So based on our discussions on IRC and in person earlier today, I think
the following additions to the Fullscreen specification would provide the
necessary infrastructure to support <dialog>:
- Add a new stacking layer to the CSS 2.1 Appendix E layering model,
after the current layer 10. Let's call this new layer the "top" layer.
This layer consists of a stack of elements, which each CSS viewport
maintains. These stacks are initially empty. When the layer is painted,
the elements in the stack are rendered in the order that they were added
to the stack, with the most recently added being rendered closest to the
user. The 'z-index' property is ignored for this stacking layer.
An element in this layer is rendered in the CSS model as an atomic unit
that is a sibling to the root element; overflow, opacity, masks, clips,
etc, of ancestor elements do not affect it. Outlines must be rendered in
their non-layer-10 position if they are specified on an element with an
ancestor-or-self that is in such a stack.
An element in this layer that has an ancestor-or-self that is
display:none does not get rendered.
The 'position' property for elements in one of these stacks computes to
'absolute', 'fixed', or 'center' if that is its specifed value, and to
'absolute' if the specified value is anything else.
The containing block for such an element is the initial containing
block, same as for the root element. The static position for left,
right, and top are zero, unless overridden by another specification.
(The <dialog> spec will override the static position for top.)
- Define an algorithm to "push an element onto the top layer", which adds
a given element to this element's browsing context's viewport's stack,
if the element is in a document.
- Define an algorithm to "yank an element from the top layer", which
removes the given element from the stack it is in.
When an element is removed from a document, it must be yanked from the
top layer.
- Define a new pseudo-element ::backdrop which applies to any element in
such a stack; it addresses a box that exactly covers the viewport
immediately below the element in the stack, in the same stacking layer,
whose only applicable properties are the 'background' properties.
(Alternatively, make it a generic box with properties initially set to
have position:fixed and positioned to exactly cover the viewport, but
I don't see much point in letting people fiddle with this box's
positioning, display type, etc.)
Fullscreen then defines that when you make an element fullscreen, it's
"pushed onto the top layer", and when an element is unfullscreened, it's
"yanked from the top layer". The user "emergency escape" UI yanks all
fullscreened elements from the top layer (but leaves any other elements in
it; we wouldn't want dialogs to disappear when exiting full screen mode).
If this works, then I'll use this for <dialog>.
Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Robert O'Callahan
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson <i...@hixie.ch> wrote:
> This layer consists of a stack of elements, which each CSS viewport
> maintains. These stacks are initially empty. When the layer is painted,
> the elements in the stack are rendered in the order that they were added
> to the stack, with the most recently added being rendered closest to the
> user. The 'z-index' property is ignored for this stacking layer.
>
Is each element in this stack treated as having its own stacking context? I
assume so, but you'd better say so.
- Define a new pseudo-element ::backdrop which applies to any element in
> such a stack; it addresses a box that exactly covers the viewport
> immediately below the element in the stack, in the same stacking layer,
> whose only applicable properties are the 'background' properties.
> (Alternatively, make it a generic box with properties initially set to
> have position:fixed and positioned to exactly cover the viewport, but
> I don't see much point in letting people fiddle with this box's
> positioning, display type, etc.)
>
It's probably more work to make all non-background properties inapplicable
than it would be to simply treat it like ::before/::after generated content.
Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
Ian Hickson
> On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson <i...@hixie.ch> wrote:
> >
> > Fullscreen then defines that when you make an element fullscreen, it's
> > "pushed onto the top layer", and when an element is unfullscreened,
> > it's "yanked from the top layer". The user "emergency escape" UI yanks
> > all fullscreened elements from the top layer (but leaves any other
> > elements in it; we wouldn't want dialogs to disappear when exiting
> > full screen mode).
>
> a dialog open, esc should cancel the dialog, otherwise it should yank
> all fullscreened elements.
Yes, indeed. I didn't mean to specifically refer to the escape key, so
much as the generic "escape me out of fullscreen mode because I might be
being spoofed" emergency escape UI. That could just be a button that
appears when you hover over the top-right of the screen, for instance.
Ian Hickson
> On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson <i...@hixie.ch> wrote:
> >
> > This layer consists of a stack of elements, which each CSS viewport
> > maintains. These stacks are initially empty. When the layer is
> > painted, the elements in the stack are rendered in the order that they
> > were added to the stack, with the most recently added being rendered
> > closest to the user. The 'z-index' property is ignored for this
> > stacking layer.
>
> Is each element in this stack treated as having its own stacking
> context? I assume so, but you'd better say so.
Right, each one would be its own atomic stacking context much like a
'position:absolute' box normally is today. I agree this should be explicit
in the Fullscreen spec.
> > - Define a new pseudo-element ::backdrop which applies to any element
> > in such a stack; it addresses a box that exactly covers the viewport
> > immediately below the element in the stack, in the same stacking
> > layer, whose only applicable properties are the 'background'
> > properties. (Alternatively, make it a generic box with properties
> > initially set to have position:fixed and positioned to exactly cover
> > the viewport, but I don't see much point in letting people fiddle with
> > this box's positioning, display type, etc.)
>
> It's probably more work to make all non-background properties
> inapplicable than it would be to simply treat it like ::before/::after
> generated content.
Either is fine by me.