[whatwg] Questions about ::backdrop

Tab Atkins Jr. jackalmage at gmail.com
Fri Jun 28 09:57:27 PDT 2013

On Fri, Jun 28, 2013 at 2:48 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Jun 28, 2013 at 9:46 AM, Matt Falkenhagen <falken at chromium.org> wrote:
>> 1. Should ::backdrop have the same properties as a real top layer
>> element, such as "Its containing block is the initial containing block."
>> and "Ancestor elements with overflow, opacity, masks, etc. cannot affect
>> it."?  It seems weird if a dialog is not affected by overflow, etc. and
>> its ::backdrop is. It also may be convenient to position and size the
>> backdrop relative to the ICB, like <dialog>. On the other hand, perhaps
>> it's convenient in some use cases for ::backdrop to be positioned and
>> sized relative to the <dialog>.
> Clarified: https://github.com/whatwg/fullscreen/commit/319aea6ffe996ac97f49701075aa233966765e81
> Hopefully in due course this will be properly part of CSS instead of
> some hack on top, but we've been waiting on that for a while now so
> don't get your hopes up :-)

I think it should be the same as <dialog>, for the reasons you mentioned.

>> 2. Clicking on a pseudo-element causes a click event to be dispatched to
>> its parent element. But this will make it unwieldy to implement
>> behaviors like dismissing a modal dialog or "bouncing" it for attention
>> when the area outside the dialog is clicked. Ideally you can easily
>> determine whether the dialog or its ::backdrop was clicked. Can we
>> perhaps use event.relatedTarget for this information?
> Simon, Tab, what does CSSOM / CSS / hit testing say about this?
> (Harhar, I know half of that is not defined, get on it!) (I'm assuming
> this would also apply to e.g. ::before.)

Right now you can't detect that the click was actually on a
pseudo-element.  That's a bad thing.  Elliot Sprehn argued a little
while ago for adding a .pseudo attribute onto mouse events, with it
being either the empty string or the name of the pseudo that was
actually clicked on.

Alternately, now that we have a basic representation of
pseudo-elements in script
we could just extend that to allow event handlers to be registered on
pseudos.  Similar to shadow trees, they'd re-target when they bubbled
up to the associated element (to preserve today's behavior where the
target is the associated element).

Either works for me.


More information about the whatwg mailing list