Confirm, emeritus
969
edits
Changes
Created page with 'The [http://www.w3.org/TR/SVG11/ SVG specification] introduced the '[http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty pointer-events]' property to provide SVG autho...'
The [http://www.w3.org/TR/SVG11/ SVG specification] introduced the '[http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty pointer-events]' property to provide SVG authors with more control over when and which parts of an element can be the target of a pointer event. This document discusses the use of the 'pointer-events' property in HTML, since HTML authors have been asking for 'pointer-events' like functionality since forever.
== The current property values suck ==
The current values for 'pointer-events' suck - especially for HTML. Quite apart from the fact that they use the SVG specific terms "fill" and "stroke" in their names, they're confusing, and even authors that have been using SVG for a long time frequently have to refer back to the spec to figure out which value they need to use. For example:
* What's the difference between 'visiblePainted', 'visible', 'painted' and 'all'? (Note that none of these tell you if the element in question actually affects the pixel that was clicked.)
* Does the value of the 'fill' property matter for the 'painted' and 'fill' properties? (Yes and no respectively.)
* ...
== Use cases ==
* Provide a way to allow pointer events to go "through" an element even when it's visible to the user.
* Provide a way to allow pointer events to go "through" areas of an element that are transparent/hidden from the user, while allowing pointer events to be "caught" by parts of the element that are visible to the user.
* Provide a way to allow pointer events to be "caught" by an element even when it is invisible to the user.
== Proposed values ==
'none', 'painted' and 'all'.
In SVG it may make sense to be able to have separate treatment for fill and stroke. In that case maybe the values 'all', 'fill', 'stroke' and 'painted', 'paintedFill', 'paintedStroke' would make sense. The former three would ignore opacity and visibility, the latter three would not. In fact, for these extra names to make a little more sense in CSS box model contexts such as HTML where you have 'background' and 'border' instead of 'fill' and 'stroke', the names could be 'all', 'perimeter', 'interior', and 'painted', 'paintedPerimeter', 'paintedInterior'.
== To merge... ==
The current specification makes the value of the 'visibility' property special, but for some strange reason ignores the effects of opacity. As a result the 'visible' in value names such as 'visiblePainted' is nothing to do with whether something visible is actually painted, but rather to do with whether the 'visibility' property is set to 'visible' or not. The 'fill-opacity', 'stroke-opacity' or 'opacity', or the 'fill' or 'stroke' properties with rgba()/hsla() values that set opacity to zero, could all prevent any paint from being output, but as far as 'visiblePainted' et. al. are concerned, it's visible and painted if 'visibility' is set to 'visible'. Perhaps these values could be fixed to take account of opacity?
In fact 'visibleFill', 'visibleStroke' and 'visible' don't care about the values of 'fill' or 'stroke', even if they are 'none'.
Another source of confusion is the difference between 'visiblePainted', 'visible', 'painted' and 'all'. For all four the geometry is the combined stroke and fill geometry. The difference is in whether the 'fill' and 'stroke' properties are set to 'none' or not ('visiblePainted' and 'painted' do not allow them to be 'none', but 'visible' and 'all' do). Why do we even need a distinction between non-painting due to the value of 'visibility' vs 'fill'/'stroke'? Why don't we also have 'paintedFill', 'paintedStroke' and 'paintedAll' values then???
The 'visible' value should really have been 'visibleAll' for consistency. Maybe it seemed easier to remember, but the inconsistency it brings to the naming makes it harder to remember how everything works as a whole.
What about when 'fill' or 'stroke' references a gradient or pattern that is fully transparent/empty (or has large areas that are)? I think it would be fine to always treat paint server references as fully opaque paint. The utility behind 'painter-events' is to
== The current property values suck ==
The current values for 'pointer-events' suck - especially for HTML. Quite apart from the fact that they use the SVG specific terms "fill" and "stroke" in their names, they're confusing, and even authors that have been using SVG for a long time frequently have to refer back to the spec to figure out which value they need to use. For example:
* What's the difference between 'visiblePainted', 'visible', 'painted' and 'all'? (Note that none of these tell you if the element in question actually affects the pixel that was clicked.)
* Does the value of the 'fill' property matter for the 'painted' and 'fill' properties? (Yes and no respectively.)
* ...
== Use cases ==
* Provide a way to allow pointer events to go "through" an element even when it's visible to the user.
* Provide a way to allow pointer events to go "through" areas of an element that are transparent/hidden from the user, while allowing pointer events to be "caught" by parts of the element that are visible to the user.
* Provide a way to allow pointer events to be "caught" by an element even when it is invisible to the user.
== Proposed values ==
'none', 'painted' and 'all'.
In SVG it may make sense to be able to have separate treatment for fill and stroke. In that case maybe the values 'all', 'fill', 'stroke' and 'painted', 'paintedFill', 'paintedStroke' would make sense. The former three would ignore opacity and visibility, the latter three would not. In fact, for these extra names to make a little more sense in CSS box model contexts such as HTML where you have 'background' and 'border' instead of 'fill' and 'stroke', the names could be 'all', 'perimeter', 'interior', and 'painted', 'paintedPerimeter', 'paintedInterior'.
== To merge... ==
The current specification makes the value of the 'visibility' property special, but for some strange reason ignores the effects of opacity. As a result the 'visible' in value names such as 'visiblePainted' is nothing to do with whether something visible is actually painted, but rather to do with whether the 'visibility' property is set to 'visible' or not. The 'fill-opacity', 'stroke-opacity' or 'opacity', or the 'fill' or 'stroke' properties with rgba()/hsla() values that set opacity to zero, could all prevent any paint from being output, but as far as 'visiblePainted' et. al. are concerned, it's visible and painted if 'visibility' is set to 'visible'. Perhaps these values could be fixed to take account of opacity?
In fact 'visibleFill', 'visibleStroke' and 'visible' don't care about the values of 'fill' or 'stroke', even if they are 'none'.
Another source of confusion is the difference between 'visiblePainted', 'visible', 'painted' and 'all'. For all four the geometry is the combined stroke and fill geometry. The difference is in whether the 'fill' and 'stroke' properties are set to 'none' or not ('visiblePainted' and 'painted' do not allow them to be 'none', but 'visible' and 'all' do). Why do we even need a distinction between non-painting due to the value of 'visibility' vs 'fill'/'stroke'? Why don't we also have 'paintedFill', 'paintedStroke' and 'paintedAll' values then???
The 'visible' value should really have been 'visibleAll' for consistency. Maybe it seemed easier to remember, but the inconsistency it brings to the naming makes it harder to remember how everything works as a whole.
What about when 'fill' or 'stroke' references a gradient or pattern that is fully transparent/empty (or has large areas that are)? I think it would be fine to always treat paint server references as fully opaque paint. The utility behind 'painter-events' is to
