- From: Doug Schepers <doug@schepers.cc>
- Date: Tue, 27 Jun 2006 18:39:00 -0400
- To: "'Maciej Stachowiak'" <mjs@apple.com>, <www-svg@w3c.org>
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