[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