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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Jan 2013 20:34:35 -0800
Message-ID: <CAAWBYDD_qmeYh9ug+3ZcSrMqaqaHPT3CE2XuUg4-8ikwLsYHvw@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: www-style list <www-style@w3.org>
On Wed, Jan 16, 2013 at 8:33 PM, Simon Fraser <smfr@me.com> wrote:
> On Jan 16, 2013, at 8:10 pm, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> 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".)
>
> I thought we were already spec'ing this as part of fullscreen/<dialog>?

This is my effort to start actually speccing it for those purposes.  ^_^

~TJ
Received on Thursday, 17 January 2013 04:35:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT