- From: Doug Schepers <doug@schepers.cc>
- Date: Mon, 1 Nov 2004 18:48:10 -0500
- To: "'Ian Hickson'" <ian@hixie.ch>, <www-svg@w3.org>
- Cc: 'Håkon Wium Lie' <howcome@opera.com>
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