W3C home > Mailing lists > Public > www-style@w3.org > January 2013

[css3-positioning] "Top layer" for positioned elements?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Jan 2013 20:10:33 -0800
Message-ID: <CAAWBYDAiZSrnWzksNKs1SRbaFxLg271fe2CnzEMoyj5ybd1dHQ@mail.gmail.com>
To: www-style list <www-style@w3.org>
A decent number of recent specs outside of CSS (Fullscreen, <dialog>,
others?) want the ability to put something "above everything else".
(Of course, this doesn't really work, as multiple things can be "on
top" at once, but all that's actually needed is "on top of everything,
except possibly stuff that also wants to be on top").  Outside of
specs, authors also want this kind of thing relatively often for their
own purposes, often related (for example, doing author-build dialogs
and similar things).

In simple cases, this can be done with abspos, by setting z-index to a
very high value.  However, this fails if the element is in a
(pseudo-)stacking context.  As well, "very high value" isn't
well-defined - many authors implicitly assume that implementations use
a signed 32-bit int to store z-index (which happens to be true for
several (all?) major implementations, but which shouldn't be depended
on in general), and set z-index to 2 billion or so.  If impls ever
change, or a new impl uses a smaller value (since this assumption
isn't documented in any spec), the page will break.

Instead, we could create a "top layer" for positioning stuff, which is
separate from the "document layer".  This could be set with an
additional value in z-index that can be specified alongside the number
value.  Within the top-layer, z-index still works to position things
relative to each other.  When positioned in the top layer, the element
breaks out of any containing contexts, including pseudo-stackign
contexts like 'opacity'.  (I'm unsure of whether this means they
*won't* be affected by an ancestor's opacity/filter/etc, or if it'll
be affected independently from the rest of the group they were
originally in.  I suspect the former makes more sense and has better
use-cases, and can perhaps be defined precisely in terms of "effects
that create a pseudo-stacking context".)


Received on Thursday, 17 January 2013 04:11:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:25 UTC