[css4-ui] [css-ui] Effect of pointer-events:none on scrollbars

Hello,

In working on a patch (https://codereview.chromium.org/68243009/) for
Chrome Issue 313908 (http://crbug.com/313908), an issue has come up
concerning the effect of pointer-events:none on overflow controls such as
overflow scrollbars.

First of all, by overflow scrollbar, I mean a scrollbar that decreases the
size of the viewport, as opposed to overlay scrollbars which are drawn on
top of the viewport and are typically only visible during scrolling.
 Overflow scrollbars are used on Windows as well as on Mac when the "Show
scroll bars" setting is set to "Always".  Overlay scrollbars are used on
Mac when the "Show scroll bars" setting is set to "When scrolling".

The latest draft wording of the pointer-events CSS4 UI property (
http://www.w3.org/wiki/User:Tantekelik/pointer-events) does not appear to
specify what the effect of pointer-events:none is on overflow scrollbars.
 In addition, there is a difference in behavior between Firefox and
Internet Explorer 11, so it would be good to clarify the spec on this point.

Here is a test case:
<div id="div1" style="position: absolute; top: 0; left: 0; width: 100px;
height: 340px; background-color: Pink; overflow: auto;"
onclick="alert('div1 clicked')">
<div id="div1Content" style="width: 100%; height: 500px;">
    Div 1
</div>
</div>
<div id="div2" style="position: absolute; pointer-events: none; top: 20px;
left: 0; width: 100px; height: 300px; background-color: Gold; overflow:
auto; z-index: 1;" onclick="alert('div2 clicked')">
<div id="div2Content" style="width: 200%; height: 500px;">
    Div 2
</div>
</div>

In Firefox 25.0.1 on Mac with the "Show scroll bars" setting set to
"Always", I am seeing that div2's overflow scrollbars *do* respond to mouse
events.  In IE 11 on Windows 8.1, I am seeing that div2's overflow
scrollbars do *not* respond to mouse events.  In both browsers with the
mouse cursor strictly over the Gold-colored div2Content area, scrolling
with the mouse wheel scrolls div1 (as expected).

I searched the www-style list to see if this has come up before, and the
one thing that I did find that might be helpful are minutes of a 2013-03-27
telecon (http://lists.w3.org/Archives/Public/www-style/2013Mar/0688.html):

   <fantasai> I'm sympathetic to dbaron's concern about layering, but
>               I'll also note that propagating through the region parenting
>               is entirely controlled by CSS
>    <sgalineau> dbaron, doesn't pointer-event do that to some extent
> already?
>    <fantasai> not really. It changes the geometry of the target only, atm
>    <sgalineau> you can use it to prevent an element from capturing events
>    <fantasai> That's equivalent to making its geometry match the empty set
>               of points
>    stearns: I'm happy to try out option 4, unless there's anyone who
> prefers
>             any of the three previous options
>    fantasai: I'm not DOM or events person, but second one also looks like
>              it could be OK
>    stearns: 2nd one is about duplicate event which goes up the visual
> hierarchy
>    fantasai: concern with 4th one: pointer events changes the geometry with
>              respect to pointer clicks, but doesn't change how the events
>              are propagated
>    fantasai: Do we need a separate property?
>    sgalineau: You're changing which way it's routing
>    fantasai: It's like making it hidden
>    sgalineau: if a different node gets the event, you get a different route
>    fantasai: no
>    sgalineau: yes
>    <fantasai> You're just changing what got hit, not what the routing is
>               after the hit
>    <sgalineau> disagree; another node behind you gets the event and may
>                not be your parent afaik.
>    <fantasai> right, but you didn't hit that because it wasn't "visible".
>               You didn't change the routing of the event bubble chain,
>               you changed its target



Personally I think that IE 11's behavior makes better sense here because
it's consistent that pointer-events:none on div2 prevents it from being
scrolled.  In Firefox, if using overflow scrollbars, then it is possible to
scroll div2.  However, if using overlay scrollbars, (e.g. Mac's "Show
scroll bars" setting is changed to "When scrolling") then it is not
possible to scroll div2.  Also, I think that fantasai's pointer-events:none
analogy of an empty-set geometry points to IE 11's behavior as correct in
this case.  Furthermore, the fact that overflow scrollbars are rendered
within the border-box of div2 (as can be seen by adding a border to div2),
and the spec for pointer-events:visible mentions that an element may be the
target of an event if over the borders, this conceptually implies that the
overflow controls within the border-box are subject to the effect of
pointer-events as well.

Could the pointer-events spec be clarified on this issue?

Daniel