- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Thu, 25 Apr 2013 15:43:51 +0200
- To: www-style@w3.org
On 29/03/13 02:11, Alan Stearns wrote: > On 3/27/13 7:36 AM, "Daniel Glazman" > <daniel.glazman@disruptive-innovations.com> wrote: > >> On 22/03/13 00:28, Alan Stearns wrote: >> >>> Option 4: >>> >>> Add a new 'display-tree' value to the proposed 'pointer-events' property >>> [1] (or add a new property for this value). The capture phase remains >>> unchanged. The bubble phase remains unchanged *unless* the target node's >>> 'pointer-events' property computes to 'display-tree'. In that case, the >>> event bubbles up to the first fragmented node, then to the fragment >>> container (repeating through nested fragmentation contexts). >>> >>> This option satisfies B, E and F. It satisfies A with >>> 'pointer-events:auto' and C and D with 'pointer-events:display-tree'. >> >> I really really like this proposal. The best of both worlds for >> the least intrusive solution. Please note this could help solve >> the loooong standing issue of hovering over a positioned >> element, cause of the first Note in section 6.6.1.2 of Selectors [1]. > > Hmm. That note does not mention what the preferred solution would be. If > we hover over an absolutely positioned element and expect the hover > styling to propagate to the display boxes below the element, then it's no > longer necessarily following the display tree. So for this suggestion to > work with both positioned elements and fragment containers, I think this > might be better: > > Add a new 'display-order' value to the 'pointer-events' property. If a > node's 'pointer-events' property computes to 'display-order' then event > and hover propagation bubbles through the targets for each box underneath > the pointer position in front-to-back order. > > One way of thinking about this would be to consider the target node as > having pointer-events:none - what node would then get the event? That's > the next step in the propagation chain. Now consider that node to have > pointer-events:none to determine the next step, and so on. The way I see it, there is choice between the visual tree and the DOM tree only at regions boundaries. So maybe this is has to deal with the 'flow-into' property that could become a shorthand for the flow name and the event propagation chain. </Daniel>
Received on Thursday, 25 April 2013 13:44:15 UTC