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
<http://dev.w3.org/csswg/cssom/#extensions-to-the-element-interface>,
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.

~TJ
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