Re: [css3-regions] Event handling on regions

On 3/12/13 5:56 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 11/11/12 12:22 PM, "Razvan Caliman" <rcaliman@adobe.com> wrote:
>
>>Hello,
>>
>>CSS regions act only as a visual containers for rendering content.
>>
>>In most cases, regions and content nodes that flow into them belong to
>>different node trees. Regions do not act as 'parentNode' to their content
>>nodes. Because of this, events triggered on the content nodes do not
>>bubble to the regions.
>>
>>This prevents regions from reacting to events such as click, touch, drag,
>>etc.
>>
>>The regions CSSOM provides 'getRegionsByContent()'[1] as a method to help
>>identify the region where a content node renders. However, it is possible
>>and likely that the method will return a sequence of regions if the
>>content node is split across multiple regions.
>>
>>It is necessary to identify the exact region where an event took place to
>>cover basic use cases:
>>- Highlight a region on click / mouseover
>>- Drag a region across the page
>>
>>There at least two possible approaches to fix this issue:
>>
>>Option 1: 
>>Inject the region's object reference into the capture and bubble phases
>>for events triggered on content nodes that render inside the region. None
>>of the region's ancestors in the DOM would be injected.
>>
>>The event path for a click might look like this:
>>(capture) document -> body -> content node parent -> REGION -> content
>>node
>>(target) content node
>>(bubble) content-node -> REGION -> content node parent -> body ->
>>document
>>
>>
>>Option 2: 
>>Do not inject the region in the regular event paths. Dispatch a separate
>>event on the named flow [2] that the region belongs to. The two events
>>are
>>interlaced:
>>
>>Let NFE be the event dispatched on the named flow.
>>
>>(capture NFE) Named flow - > region
>>(capture) document -> body -> content node parent -> content node
>>(target) content node
>>(bubble) content node -> content node parent -> body -> document
>>(bubble NFE) region -> Named flow
>>
>>Either option should consider the complexities:
>>- nested regions: regions might render inside other regions.
>>- non-DOM elements as regions: pseudo-elements, grid cells, page slots.
>>Both options require that these containers have a corresponding CSS
>>Object
>>Model.
>>
>>I expect Option 1 to be more intuitive for developers. Option 2 does not
>>alter the DOM event paths and helps mitigate the issue of regions not
>>being DOM elements.
>>
>>What are your thoughts on these approaches to enable event handling on
>>regions?
>
>Apologies for taking so long to respond to this. There have been off-list
>discussions on this topic in multiple venues. Here is my summary of what I
>understand so far.
>
>This is not necessarily a problem just for regions. It's an issue for any
>fragmentation context (multicol, paged views, overflow fragment boxes), if
>you want the fragment containers to know when events happen in the
>fragment content. In the simple case of an element fully contained in a
>region fragment, you can determine the relevant region using the CSSOM
>methods provided. So regions are a bit ahead of the other fragmentation
>contexts in this regard (though it would be much better if you could just
>listen for an event on the region). It's only when a content node crosses
>a fragmentation boundary that the problem crops up for regions.
>
>There are quite a few design constraints I've heard discussed, and some of
>them are contradictory.
>
>A. How events currently work should not change
>B. There should be only one capture/bubble path for an event
>C. Fragment containers should be aware of events in their fragment
>D. Ancestors of fragment containers should also aware of events
>E. Nested fragmentation contexts should not multiply events
>
>
>Razvan's option 1 satisfies B, C and E. The event path changes, so A is
>lost. To accomplish D the event handler for the fragment container would
>need to notify its ancestors. How it handles E is not defined, but nesting
>would not add more events.
>
>Perhaps we could change where this option inserts the fragment container
>hierarchy in the path. What if the fragment container was the end
>reference instead of being inserted somewhere in the middle?
>
>(capture) document -> body -> content node parent -> content node ->
>fragmentainer
>(target) content node
>(bubble) fragmentainer -> content-node -> content node parent -> body ->
>document
>
> An given a multicol region (nested columns inside of regions) we could
>insert the fragment containers in nesting order:
>
>(capture) document -> body -> content node parent -> content node ->
>column -> region
>(target) content node
>(bubble) region -> column -> content-node -> content node parent -> body
>-> document
>
>
>Razvan's option 2 satisfies A and C. D might be satisfied if you chose to
>add the fragment container's ancestors to the NFE event path. B is lost
>because there are now two paths, and E is lost because in nested contexts
>you'd get more events.
>
>
>There is at least one more option.
>
>Option 3:
>
>Add fragment container references to the existing event. No other changes
>are made to the event path. You can listen for the event anywhere in the
>content node ancestry, then read the event to see which fragment
>container(s) are relevant. This would satisfy A, B and E. C and D aren't
>satisfied directly, because you would not be able to attach an event
>handler to a region or its ancestors.

All right - here's more on this topic.

New constraint:

F. Whatever happens with events should be mirrored in pseudo-class
propagation

I'm not sure whether pseudo-class propagation is actually defined, but it
looks to me like if you hover over a node, the :hover styling of its
parent is invoked (even if the child is separated from the parent in
visual rendering). It would be useful to be able to style a fragment
container with :hover and have the styling apply when you're hovering over
its fragment.

I believe options 1 and 2 could satisfy this constraint. Option 3 does not.

New use case:

To support my contention that this isn't region-specific, think of a
paginated view displaying two pages of content at once (as happens in
iBooks, for example). There are two page boxes displaying fragments, and a
paragraph node might be split from one page to the other. I want to be
able to have :hover styling for each page, and a click handler for each
page (left moves to the previous spread, right to the next spread). If I
hover over or click in the second fragment of the split paragraph, I'd
like the right page to have it's :hover styling applied and its click
handler invoked.

New option:

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'.

Thanks,

Alan

Received on Thursday, 21 March 2013 23:28:40 UTC