- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 28 Jun 2013 09:57:27 -0700
- 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