RE: SVGT 1.2: requirements for pointer selection

Hi, Maciej-

Thanks for raising this issue. First, let me state that the reason for this
requirement are rooted in accessibility concerns. 

Maciej Stachowiak wrote:
| 
| "For systems which support pointer devices such as a mouse, the user  
| agent is required to provide a mechanism for selecting text 
| even when  
| the given text has associated event handlers or links, which might  
| block text selection due to event processing precedence rules (see  
| Pointer events). One implementation option: For platforms which  
| support a pointer device such as a mouse, the user agent may provide  
| for a small additional region around character cells which initiates  
| text selection operations but does not initiate event handlers or  
| links."
| 
| I do not think this is a reasonable or implementable requirement:
| 
| 1) HTML UAs do not behave this way - they allow selection starting  
| before or after a link, but not in the middle; and they often assign  
| a different behavior to dragging starting inside a link (it 
| generally initiates a link drag). It would be bad for text links in SVG to
| behave differently.

Opera, an HTML UA, allows me to select any text, including links, from
anywhere in the text by the typical method of mousing down and dragging.
This doesn't prevent me from dragging a link, either. Opera seems to decide
when to select and when to drag by the direction of the drag... if I drag in
the direction of the text (normally horizontally), it selects; if I drag up
or down, it grabs the link. This is certainly one possibility. For the
record, this is the behavior in their HTML UA; while I can freely select any
text (even in a link) in their SVG UA, I can't yet drag any links in the SVG
UA.


| 2) Using event handlers (with default prevented) to prevent text  
| selection is a feature provided to content authors.

That's a good point. We have reworded the section to say:

"For systems which support selection, the user agent must provide a  
mechanism for selecting text with a full range of available UI devices 
(e.g. keyboard, mouse, pen, or any other pointer device) as a default, even 
when the given text is part of a link.  One implementation option for 
platforms which support selection via a pointer device such as a mouse 
is for the user agent to provide for a small additional region around 
character cells which initiates text selection operations but does not
initiate 
event handlers or links.  Additionally, the user agent must allow scripted
or 
programmatic DOM access to all text content, and specifically any selected 
or focused content, at all times."

As you see, this makes no restriction that text must be selectable under the
circumstances that you point out (when there is an author-defined
constraint, such as pointer-events="none", an overlaying shape with
opacity="0", or other such chicanery). I reviewed the WAI documents
carefully, and believe that this captures the letter and spirit of those
guidelines, while easing the restrictions on UAs.


| 3) Where is the suggested extra space to go? Suppose you have:
| 
| <a xlink:href="http://www.example.com">
| <textArea>
| first line of text
| second line of text
| third line of text
| </textArea>
| </a>
| 
| Suppose the lines happen to break exactly as written. Where is the  
| space that would allow selection of the word "line" on the second  
| line of text? The <a> element is supposed to apply to the entire  
| textArea, it seems disallowed by the spec and furthermore confusing  
| that clicking or dragging the link in some places would not actually  
| have the link behavior.

Opera came up with a mechanism, but we don't mandate any particular method
of addressing that. That is platform- and implementation-specific.

If this does not satisfy your concern, please respond within 2 weeks with
further clarification.

Thanks-
Doug, on behalf of the SVG WG

Received on Tuesday, 27 June 2006 22:39:21 UTC