RE: SVG 1.2 questions: editable text

Hey, guys-

You're preaching to the choir. This is a feature I've been bugging them
about for years, and they finally graced us with it:

http://www.w3.org/TR/SVG12/text.html#text-selection

Happily-
Doug

Kevin Hughes wrote:
| 
| 
| From: Andreas Neumann <neumann@karto.baug.ethz.ch>
| > * should there also be an attribute indicating whether a text is 
| > "selectable" (true|false)? There are cases where you want text 
| > elements to react to events, but not be selectable. Setting 
| > "pointer-events" to "none" also turns of the ability to react to 
| > mouse-events, such as "onclick". I think, such an addition might be 
| > useful. Of course, setting "selectable" to false would also 
| turn off 
| > "editable".
| 
| 	I would second this. The problem is in cases where one 
| has draggable interface elements, such as scrollbars, next to 
| text content that still needs to respond to events such as 
| mouseup and mousedown. Today, if the mouse is moved over a 
| text element while dragging, the text is selected and in some 
| cases the drag operation is cancelled.
| 	In traditional GUIs scrollbars are often near text 
| labels. When a drag is detected the UI programmer must have 
| an easy way to turn off text selectivity for all applicable 
| elements, and turn selectivity back on again when the drag 
| operation is finished. Note also that the UI may be dynamic 
| and change depending on the display size, etc. so these text 
| elements may change over time and be added to or removed from 
| the DOM as the layout changes, as in the case of certain word 
| processor or page layout interfaces.
| 	It may be easiest to do this using a CSS property, in 
| which case this becomes a CSS, and not an SVG, issue.
| 	Today, if I want to make non-selectable text I can drag 
| over that also responds to mouse ups and downs, as in the 
| case of drop-down menu widgets or a drag-and-drop 
| cut-and-paste text feature, I must create multiple layers 
| with 0 opacity to handle events and highlights. This is a 
| time-consuming elementally verbose process that also requires 
| a good deal of otherwise unnecessary code.
| 	The ability to toggle selectivity via CSS (using 
| classes or IDs) sounds like the most flexible solution to me. 
| With that you also give Web page designers the ability to 
| specify certain text as being non-selectable as well. This is 
| useful in the case of allowing people to select and copy only 
| the relevant textual content of Web pages without also 
| inadvertently selecting navigational and other UI-specific 
| text, without having to shut off event listening.
| 
| 	-- Kevin Hughes
| 
|

Received on Tuesday, 2 November 2004 08:04:29 UTC