W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Questions about ::backdrop

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 28 Jun 2013 09:57:27 -0700
Message-ID: <CAAWBYDCMSjx9cdN+HqN_Fuq_3PsSRcO242dEXw+ggBsDy=yz0Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Matt Falkenhagen <falken@chromium.org>, WHATWG <whatwg@whatwg.org>, Simon Pieters <simonp@opera.com>
On Fri, Jun 28, 2013 at 2:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Jun 28, 2013 at 9:46 AM, Matt Falkenhagen <falken@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.

Received on Friday, 28 June 2013 16:58:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC