[whatwg] Fullscreen changes to support <dialog>

[Sean Hogan]

On 4/04/12 9:14 AM, Ian Hickson wrote:
> 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,

So this "top" layer prevents all user-interaction with the rest of the 
page?

If that's the case, it seems a bit inflexible. I would imagine that some 
UI designers would like parts of the page to still be clickable - a 
couple of examples:

- a toggle button to show / hide the dialog (probably part of a menu-bar).
- a menu bar with buttons that, when activated, first dismiss the dialog

Sean