[whatwg] Fullscreen changes to support <dialog>
shogun70 at westnet.com.au
Wed Apr 4 20:58:12 PDT 2012
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>.
So this "top" layer prevents all user-interaction with the rest of the
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
More information about the whatwg