Text Selection (was: SVG 1.2 Comment: Detailed last call comments (all chapters))

Hi, Ian-

I'm responding in specific to your comments on Text Selection, and in
general to your comments regarding text in SVG, such as those dealing with
flowing text. Sorry if what I say duplicates others' commments on the (very
long, and as yet unread) Flow Text thread; I'm just replying to your
original email.

Ian Hickson wrote:
|
| > 6.2 Text Selection
| 
| This section omits to define the event's bubbling behaviour 
| and default action. Its IDL doesn't define the 
| initSVGSelectionEvent and initSVGSelectionEventNS methods 
| which should presumably be used to initialise such events. 
| The interface is missing a |view| attribute (readonly 
| attribute views::AbstractView view;) which is required for 
| all view-specific events (see, e.g., the UIEvent definition).

Yes, the wording and IDL need more work, both for precision and for clarity.


| This section doesn't define what should happen if the 
| selection crosses out of the <svg> element into other 
| content. For example, why is the |selection| attribute on the 
| SVGSVGElement interface instead of the document?

Why would we need to worry about that? Surely, the SVG Spec need only define
what happens within the scope of an SVG document, and a Compound Documents
Spec should fill in the gaps on interaction between other Specs. Otherwise,
HTML would have to define, as part of its Spec, how every HTML element or
attribute interacts with every SVG element; in that case, no Spec would ever
be able to leave Last Call.


| It would seem better for selection to be defined independent 
| of SVG (outside the SVG specification, since it applies to 
| more than SVG) and have SVG re-use such a definition.

I think the case is special for SVG and text selection, as you have noted
yourself. SVG has a special relationship with text. Unlike the other shapes
that SVG presents, text has deep semantic content. A circle can mean any
number of things; an "A" glyph has a specific meaning. No other SVG element
requires child nodes in order to render; in fact, no other SVG element can
have 

Unlike HTML, however, text in SVG is truly treated like a graphical element.
In HTML, you are severely constrained as to how text is presented (despite
the cool stuff that CSS allows you to do), a constraint that makes HTML
unsuitable for the same kind of text presentation that SVG excels in. In no
HTML browser that I'm aware of (not even Amaya) can you reference an SVG
Font in HTML; CSS doesn't seem to provide any way to do this, even in the
abstract. (I could be wrong here.... I looked through what I thought would
be relevant sections of CSS, to no avail; please disabuse me of this notion
if I'm wrong.) Nowhere else besides SVG can you declaratively alter the
presentation of text in the rich ways that are demanded by graphical
applications and (certain) rich documents and artistic applications(see for
example my little clock example [1]; why should I have to appeal to HTML to
do something like that). In HTML+CSS, you can't apply filters to text, you
can't use gradients on text, you can't even apply a stroke to text (much
less the cool results that Vector Effects will allow us), you can't indicate
the exact placement of words and letters on a coordinate system, you can't
flow text to arbitrary shapes or have it follow an arbitrary path. 

Is it any wonder that, given the marvelous layout and styling facilities
that SVG affords us even today, that those of us authoring in SVG would want
it to extend to flowing text? In fact, I see this as a pragmatic approach to
integrating HTML and SVG. You could use sXBL to directly map HTML content to
the SVG analog, if you really need to use HTML; better yet, you could use a
more semantically rich XML dialect (something that marks up 'footnote',
'title', 'subtitle', etc. discretely and explicitly, for instance), and
present that content. While both HTML+CSS and SVG use text, they use them in
very different ways, and so have very different needs.

I would far rather have the capability to do these things now, rather than
wait years for another WG to specify them (or reject them), which would far
too late for them to be used in next generation (2005) SVG UAs. Moreover,
it's not at all clear what other language would need such a
attribute/property as 'selectable'.

Back to the point: given the special status that text has in SVG, which
deals with both its presentational (the way it looks) and semantic (what it
means) content, there is a need to allow the user to extract the semantic
content from its presentation. In order to provide a cue to the user on how
to do this manually, the UA has to change the cursor and select the text
being moused over. Unfortunately, this breaks other possible user cues (when
text is a link, when text is draggable, when text is not the focus target,
etc.), and often breaks functionality of WebApps (when dragging something
over text, when trying to use text as a button, and other details).

Note that this will not prevent an appropriately accessible UA from
accessing this content, it will simply inhibit the manual user cue. 

This is a good feature, and not something to be lightly discarded.

Regards-
-Doug

[1] http://svg-whiz.com/svg/DigilogClock.svg

Received on Monday, 1 November 2004 23:48:17 UTC