Re: [css3-regions] Event handling on regions

On 3/21/13 4:28 PM, "Alan Stearns" <stearns@adobe.com> wrote:

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

One more option (I'm rejecting the first three options - I'm looking to
decide on either option 4 above or option 5 below)

Option 5:

Change event propagation for fragmented content to hop to the fragment
container at the fragment context boundary.

In the case of regions and named flows, events would propagate normally
within the named flow content. But once they hit the named flow boundary,
the event propagation would hop to the region where the user event
originated, then up through the region's DOM parentage. In the case of a
fragment container like a column (if/when columns are targetable) the
effect would be to insert the column between the top content node and the
multi-column element in the event propagation.

This violates A but satisfies B, C, D, E and F.

I've added a wiki page condensing all of the above [1]. I think some
whiteboard discussion in Tokyo will help resolve what to do.

Thanks,

Alan

[1] http://wiki.csswg.org/spec/css3-regions/user-event-handling

Received on Thursday, 23 May 2013 23:59:53 UTC