Re: [css3-regions] Event handling on regions

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.

Thanks,

Alan

Received on Wednesday, 13 March 2013 00:57:15 UTC