Re: SVGT 1.2: requirements for pointer selection

On Jun 27, 2006, at 3:39 PM, Doug Schepers wrote:

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

What assistive technology depends on the ability to drag-select text  
with the pointer? And why don't they seem to mind that not all HTML  
UAs allow this?

>
>
> 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.

Opera's behavior is interesting. Safari and Firefox always drag the  
link FWIW. I think this is a UI decision that should be left up to  
the UA. I do not see an obvious rationale for the given requirement.

> | 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.

I'm not sure "as a default" is the clearest way to say this, but OK.  
Note that the suggested implementation approach does rule out  
preventing selection via event handlers, though.

>
>
> | 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.

I'm willing to believe there are ways of implementing the  
requirement, however I do not think the suggested "one implementation  
option" is in fact implementable or legal per the spec. I request  
that it be replaced with an implementable approach (perhaps based on  
what Opera does). However the fact that Opera does not support link  
dragging in SVG means their specific approach is unlikely to meet UI  
requirements of other UAs.

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

See above. Not satisfied on points 1 and 3; satisfied as to point 2.

Regards,
Maciej

Received on Thursday, 29 June 2006 07:16:20 UTC