Pointer-Events in SVG 1.2

Hi-

This is a reminder about two aspects of pointer events which were brought up
onthis list and/or during panel discussions with the WG at SVG Open 2003.

Pointer-Events and Text [1] [2]

To recap, a frequent request on svg-dev is how to prevent the capturing of
text upon mouseover or mouseclick. One issue when this is raised is the use
of text as a button or  the label for a button; a workaround is to make an
invisible overlay rect, or to turn off all pointer events and place a rect
or other element below to catch the pointer events; both these methods are
klugey, involving the coordination of the placement of multiple elements,
usually with different y-coordinates (rect being top-down and text being
baseline-up in orientation). However, this is only a mild inconvenience.

A more serious issue is the ability of text to capture events from mouseover
events; in mousing over text during a drag-and-drop operation, the text can
steal focus from the dragged element in a way that other elements cannot.
This also has aesthetic implications and can lead to confusing UIs.

A proposed solution is to extened the list of discrete types of
pointer-events, to include a pointer-events='noSelect' that would prevent
the selection of text while still permitting all normal mouse events.

A consideration is the impact this proposal would have on editble text; I
believe that it will be a benefit, as the insertion/cursor point in the text
will not be obfuscated by accidental text-selection. Another point of
contention is raised by Jim Ley, who maintains, correctly I believe, that
this should be a property overrideable by user style sheets for purposes of
accessiblity. I do not believe there is any utility in allowing text to be
made non-searchable, and do not think that the new value should affect that
ability; in fact, another solution to the accessibility issue might be a
special interface in the UA that exposes the text to text-to-speech or other
UAs. The ordering of this text might be ordered by a reading/navIndex, or by
a mechanism such as the logicalGroups I proposed earlier, where the logical
order of the text can be divorced from the rendering order (for a more
indepth idea of what logical groups might achieve, see [3]).

A final issue is that when text that extends beyond the current viewport is
being selected, the rest of the image can be moved by the act of selecting.
This is often a benefit (such as when text is being searched for and the
viewport is adjusted to show it), but is often not the desired behavior. A
solution might be a further extension to the value-list of pointer-events:
'staticSelect'. This would allow the text to be selected only to the point
where it exits the viewport, and would not shift the viewport. A companion
value might be 'textShift' (or something), which would move only the text
(and not the viewport or other elements) along the axis of its baseline, by
shifting the x and/or y values of the text element. A benefit of this would
be that it would aid in the reproduction of textboxes, as the text would
move in the same manner as in traditional UIs, while the box would remain
static. Again, this would work synergistically with editable text, and with
flow-text (where the axis of movement could be the primary axis of the
containing shape).

Have built up an argument for the extension of pointer-events, it now occurs
to me that since these are text-only extensions (as of now, setting aside
the possibilities of the selection of other elements for things like editing
or inherent drag-and-drop capabilities), it might be better to create a new
attibute/style-property altogether: 'text-selection' (or just 'selection'),
that works orthogonally with pointer-events, and would allow the author more
control over just how text (and other elements?) behave natively within the
UA. All these extensions, in this case, would be under the aegis of this
attribute:
'selection-events'
Value:   visible | textShift | all | none | inherit


Pointer-Events and Markers

At the WG panel meeting at SVG Open 2003, one of the GIS guys (Andreas
Neumann, IIRC) asked for pointer-events to be applicable to markers. Use
cases include fulfilling user expectations when clicking on these markers
(mile-markers, roadsign-labels such a highway designations, arrowheads) as
being the same as clicking on their owner element. When users click on
markers, they are confused when this click does not register for no apparent
reason. In addition, if would be nice if we could assign separate events to
these markers, to get the ids of the referenced marker, its x/y coordinates,
the specific properties ('marker-start', 'marker-end', marker-mid' ), or
even to move it and thus help in the editing of the attached shape (come on,
wouldn't that be sweet? applying drag-and-drop abilities to markers that
activate when a shape is designated as editable, making native --almost
declarative-- editing of a document?)

More compelling arguments might bemade by Andreas or others, but I think the
first use case alone makes this worth considering.

Regards-
-Doug

[1] http://lists.w3.org/Archives/Public/www-svg/2002Jul/0008.html
[2] http://lists.w3.org/Archives/Public/www-svg/2003Jul/0044.html
[3] http://schepers.cc/logicalGroups/

Received on Wednesday, 14 January 2004 08:15:33 UTC