-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-ui] Spec the pointer-events property for non-SVG elements #4438
Comments
Relevant background, unearthed by @svgeesus:
|
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 |
The CSS Working Group just discussed
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. |
heads-up for @frivoal |
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)The text was updated successfully, but these errors were encountered: