[css-ui] Spec the pointer-events property for non-SVG elements

[AmeliaBR]

Currently, the only reference specification for pointer-events is in SVG.

Which brings up the odd situation of people filing issues on SVG about how to handle pointer events propagation for CSS boxes and HTML iframes: w3c/svgwg#744

Since every interactive user agent I know of supports at least the basic values of pointer-events on arbitrary CSS layout boxes, can we please write up a spec for that? Presumably in CSS UI Level 4. (CSS UI 3 is Rec)

[AmeliaBR]

Relevant background, unearthed by @svgeesus:
https://wiki.csswg.org/spec/css4-ui#pointer-events

pointer-events
Moved from CSS3-UI editor's draft because it was the top source of issues for the 2nd CSS3-UI LCWD, and because it requires documenting previously undocumented web platform hit-testing model.

Incorporate spec text from:

pointer-events spec text
Consider just specifying pointer-events:none, and reserving the other keywords as undefined in CSS (at this level of spec.

input from zewt, wilto asking for pointer-events:none in particular (#whatwg 2012-227)
Consider use-cases, in particular for pointer-events:none;

make sure things that use CSS opacity:0 transitions aren't clickable when they're hidden. (zewt on #whatwg 2012-227)
disable clicks on elements that are transitioning on/off screens (zewt on #whatwg 2012-227)
prevent transparent elements that overlap clickable ones from getting in the way (zewt on #whatwg 2012-227)
Consider adding a 'paint-order' value, as per Tokyo 2013 discussion

this would replace the normal DOM-order user-event bubbling with bubbling through the result of elementsFromPoint()
could be used with positioned elements displayed outside their DOM parent
could be used in fragmented content to include the fragment container

[AmeliaBR]

I'm expecting that the first part of spec-ing the property will be fully documenting current behavior, then seeing if that's sensible & consistent enough for a spec. So, test-driven spec development.

So far, we have basic parsing tests in the SVG folder. And one CSS test for pointer-events showing up in TypedOM. But no tests for behavior.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Spec the pointer-events property for non-SVG elements, and agreed to the following:

• RESOLVED: add pointer-events to css-ui level 4

The full IRC log of that discussion

<myles> Topic: [css-ui] Spec the pointer-events property for non-SVG elements
<myles> GitHub: https://github.com//issues/4438
<myles> AmeliaBR: The pointer-events property defines whether an element is clickable or not. If something has pointer-events: none, it's treated as transparent for clicks and you can click through it for whatever's underneath. It's not defined in any CSS spec. It's defined in SVG, which also has lots of extra values that relate to fill areas or stroke areas are clickable and other variations
<myles> AmeliaBR: The reason to discuss this is we got a bug report on SVG complaining that a particular behavior wasn't defined, and that behavior wasn't SVG-related. It was about CSS boxes and stuff that wasn't SVG related. So, what about writing up a spec for pointer-specs?
<myles> chris: SVG would be happy to see it turn up in another spec, so they can delete it from theirs
<myles> AmeliaBR: One thing that chris did discover when we were discussing it, there was a spec in CSS-ui that got pulled when trying to stabilize that spec because speccing out the actual details turned out to be complex. It seemed to have been pulled and never reappeared in a later draft. Speccing it won't be nice and easy because we have lots of legacy behavior
<myles> chris: This is widely implemented
<myles> AmeliaBR: We have lots of implementations of a property without a spec. But we should still do it, difficult or no
<heycam> +1 to moving pointer-events to css-ui
<myles> chris: This is valuable by itself to define what pointer event handling is for CSS
<myles> astearns: Since the editor of css-ui is not on the call, we can pile it on him
<myles> astearns: But, chris, you mentioned SVG would like to delete it ... you'd only be deleting a tiny part of it, because all of those other values would still be an add on for SVG
<myles> chris: They would until css-fill-n-stroke. So those parts would move there
<myles> astearns: I would expect that the current work that we are proposing for css-ui would only be the currently supported values.
<myles> AmeliaBR: That sounds like a good strategy. The SVG spec would continue to be a partial definition adding in the extra values.
<myles> chris: Yes. which is fine.
<myles> astearns: Anyone concerned about defining pointer-events in a CSS spec?
<myles> RESOLVED: add pointer-events to css-ui level 4
<myles> AmeliaBR: One final note: The first step is going to be putting together some tests to understand existing behavior and compatibility issues. If anyone wants to take the initiative to look at their implementation, that would be great
<myles> AmeliaBR: We only have parsing tests in WPT
<myles> astearns: Thanks everyone! Next week is a non-APAC time.

[astearns]

heads-up for @frivoal