W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css3-regions] Event handling on regions

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Thu, 25 Apr 2013 15:43:51 +0200
Message-ID: <51793317.904@disruptive-innovations.com>
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 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.

Received on Thursday, 25 April 2013 13:44:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC