- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 29 Jul 2008 16:17:12 -0400
- To: Jeff Schiller <codedread@gmail.com>
- Cc: www-svg <www-svg@w3.org>
Hi, Jeff- Indeed I did read it, and I think that your algorithm is simple and effective. I plan to use it in some proposed wording on the topic. I'm sorry I didn't respond before... but it's definitely on my list of todos. I also want to define the content model. Here's a question for the community: should @display="none" on a <title> stop the UA from displaying a tooltip? As a developer, I've often wanted to block Opera's behavior here, because it interfered with my own, nicer, home-rolled solution. Also, how should <desc> be treated? Should it also feed into the tooltip? Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF Jeff Schiller wrote (on 7/29/08 3:44 PM): > I did not receive any comments on this - I was wondering if any of the > SVG WG members have had a chance to read it? > > The gist is that I would like it to be specified that svg:title elements > on a use element override svg:title elements within the shadow tree > (i.e. the content referenced by a svg:use). This becomes important for > tooltips in UAs and the ability to re-use graphics for multiple > purposes, for instance. > > <svg> > <defs> > <polygon id="triangle" ...> > <title>Red Triangle</title> > </polygon> > </defs> > > <use xlink:href="#triangle"> > <title>Red Roof</title> > </use> > </svg> > > In my opinion, hovering over the triangle should produce a "Red Roof" > tooltip, but in Opera it shows "Red Triangle". > > Other thoughts/opinions? > > Thanks, > Jeff > > On 7/8/08, *Jeff Schiller* <codedread@gmail.com > <mailto:codedread@gmail.com>> wrote: > > SVG WG, > > Just in case anyone finds this useful... please feel free to use it. > > Thinking about it a bit tonight, if I had to recommend an algorithm > I think user agents should follow when determining the tooltip to > display for a given hovered element, for the most part, I think > Opera and Batik are doing the right thing _except_ when it comes to > <use> elements. > > The problem is that you may author a triangle symbol with a title > "Red triangle". I may use that symbol as a roof on an image of a > house. As the author, I would want to override that title with > something like "Red roof". Or I might want the tooltip for the > entire house (including the roof) to be "My house". At present, > there is no way to tell UAs to 'ignore the title inside this symbol > because I have a better one'. > > Basically I think UAs should _only_ go down into the <use>'s shadow > tree when there is no suitable tooltip in the current DOM tree. An > algorithm to find an element's tool tip can be defined by the > following general algorithm: > > - find the innermost element under the mouse in the current DOM tree > (ignore shadow trees) > - use its <title> > - if it has no <title> and is a <use>, then recurse into its shadow > DOM tree and find the innermost element under the mouse and use its > <title> > - if, after walking shadow trees, there still is no suitable > <title>, then start walking up the DOM tree, ancestor by ancestor > searching for the first <title> > > The above would allow the author to override the title of a used > symbol if the author wanted, for instance. It would remove the need > to use pointer-events="none" for symbols used inside symbols > described above. In general, it would also seemingly be faster than > (by default) automatically going into the shadow trees which is what > Opera and Batik are doing now. > > More formally: > > BEGIN > Set hovered_elem to the innermost exposed (i.e. not in a > deep-cloned shadow tree) element under the mouse pointer > Set tooltip_elem to getToolTipElement(hovered_elem) > Format markup in tooltip_elem into visually displayable text > (Optional) Truncate visually displayable text to some suitable > length > Show visually displayable text > END > > FUNCTION getToolTipElement(hovered_elem) RETURNS SVGElement: > BEGIN > Set tooltip_elem to null > > IF hovered_elem has any <title> elements THEN > SET tooltip_elem to the first <title> element > > ELSE IF hovered_elem is a <use> element THEN > SET inner_elem to the innermost element under the mouse > pointer in the shadow tree defined by hovered_elem.instanceRoot > SET tooltip_elem to getToolTipElement( inner_elem ) > > END IF > > IF tooltip_elem is null AND hovered_elem is not the top-most > <svg> element THEN > SET tooltip_elem to getToolTipElement( hovered_elem.parentNode ) > > RETURN tooltip_elem > END > > Regards, > Jeff Schiller > > > > On 7/8/08, *Doug Schepers* <schepers@w3.org > <mailto:schepers@w3.org>> wrote: > > Hi, Folks- > > I agree that this needs tightening up. When SVG was just > getting started, it may have been appropriate to be a little > more lax, to see how the community would end up using <title> > and <desc>. But now that lack of definite clarity is hindering > its use and implementation. > > We need to define the content model more precisely, and describe > how UAs should treat the content. Defining user interface > behavior is always a bit of a balancing act, but in this > instance, I think the open Web platform would benefit from a > little more precision. We now have more use case and clearer > requirements that we can act on. > > We also need to define the relationship that focus has on > behavior, and perhaps to allow the requiredFeatures, > requiredExtensions, and systemLanguage attributes on the <title> > and <desc> elements, as Dr. Olaf suggests. > > I am interested in what implementors think about the matter... > Opera? Mozilla? Safari/WebKit? Batik? Care to chime in? > > In the interim, I will draw up a proposal and post it to > public-svg-wg and this list. > > Regards- > -Doug Schepers > W3C Team Contact, WebApps, SVG, and CDF > > Jeff Schiller wrote (on 7/8/08 5:09 PM): > > Jonathan, do you think it would it be reasonable for us, as > part of the SVG > IG, to put together recommendations that we can then forward > to the WG - > what do you think? > > Dear WG, > > I believe Jonathan has a valid concern. The use case is as > follows: > > <defs> > <symbol id="apple"> > <title>apple</title> > </symbol> > > <symbol id="banana"> > <title>banana</title> > </symbol> > > <symbol id="orange"> > <title>orange</title> > </symbol> > > <symbol id="fruit"> > <title>fruit</title> > <use xlink:href="#apple" transform="..." /> > <use xlink:href="#banana" transform="..." /> > <use xlink:href="#orange" transform="..." /> > </symbol> > </defs> > > <use xlink:href="#apple" /> > <use xlink:href="#banana" /> > <use xlink:href="#orange" /> > <use xlink:href="#fruit" /> > > Displaying all four symbols, we would like to have the > tooltips be: apple, > banana, orange, fruit respectively. However, it seems like > with the last > symbol (which is actually a collection of previous symbols) > that if you > hover over the apple within the fruit symbol that you'd get > the 'apple' > tooltip. > > It seems like if the browsers always displayed the innermost > title (as Opera > currently does), that you'd be forced to do something hacky > like this: > > <defs> > <!-- no title elements on these --> > <symbol id="apple-impl">...</symbol> > <symbol id="banana-impl">...</symbol> > <symbol id="orange-impl">...</symbol> > > <symbol id="apple"> > <title>apple</title> > <use xlink:href="#apple-impl" /> > </symbol> > > <symbol id="banana"> > <title>banana</title> > <use xlink:href="#banana-impl" /> > </symbol> > > <symbol id="orange"> > <title>orange</title> > <use xlink:href="#orange-impl" /> > </symbol> > > <symbol id="fruit"> > <title>fruit</title> > <use xlink:href="#apple-impl" transform="..." /> > <use xlink:href="#banana-impl" transform="..." /> > <use xlink:href="#orange-impl" transform="..." /> > </symbol> > </defs> > > Is there any better way? Jonathan, can you test this? > > 2) If the following is done referencing the above defs, what > should the > tooltip be: > > <use xlink:href="#apple"> > <title>granny smith</title> > </use> > > In this case, does the <use> element's title override any > titles in its > shadow content? > > Basically the questions boil down to - which title elements > should the user > agents interoperably display for a tooltip when hovering > over elements? > > Regards, > Jeff > > On 7/8/08, Jonathan Chetwynd <j.chetwynd@btinternet.com > <mailto:j.chetwynd@btinternet.com>> wrote: > > > Whether to display inner or outermost <title>? > > I believe it might be helpful for the SVGWG to consider > and possibly agree > and define the behaviour for this issue: > > There appear to be two simple possibilities either: > > the innermost element being hovered should have its > title content displayed > as a tooltip > or > the outermost element being hovered should have its > title content > displayed as a tooltip > > the example given is an illustration of the word 'fruit' > as used here: > http://www.openicon.org/icon-ark/mulberry/fruit.svgz > > Our users have enormous difficulty with generalisations > and would benefit > from adoption of the latter course. > > there is no simple means once the innermost elements are > titled, of titling > the group - fruit. > whereas in the outermost case, one has no necessity to > label the group, and > any parts one wishes to retain their title may be left > out of the group. > > it seems clear to me that <use> is the defining case, as > in other cases the > author is in general able to adapt the content to suit > their purpose. > > regards > > <http://www.openicon.org> > > > Jonathan Chetwynd > > j.chetwynd@btinternet.com <mailto:j.chetwynd@btinternet.com> > http://www.openicon.org/ > > +44 (0) 20 7978 1764 > > http://www.w3.org/TR/SVG-access/#Equivalent > > title > Provides a human-readable title for the element that > contains it. The title > element may be rendered by a graphical user agent as a > tooltip. It may be > rendered as speech by a speech synthesizer. > > http://www.w3.org/TR/SVGMobile12/struct.html#DescriptionAndTitleElements > > 5.5 The 'desc' and 'title' elements > > Each container element or graphics element in an SVG > document may supply a > 'desc' and may also supply a 'title' description. The > 'desc' element > contains a detailed description for the container or > graphics element > containing it. This description should be usable as > replacement content for > cases when the user cannot see the rendering of the SVG > element for some > reason. The 'title' element contains a short title for > the container or > graphics element containing it. This short title > provides information > supplementary to the rendering of the element, but is > not sufficient to > replace it. These are typically text, but can be content > in other markup > languages (see foreign namespaces). When the current SVG > document fragment > is rendered as SVG on visual media, 'desc' and 'title' > elements are not > rendered as part of the graphics. SVG User Agents may, > however, for example, > display the 'title' element as a tooltip, as the > pointing device moves over > particular elements. Alternate presentations are > possible, both visual and > aural, which display the 'desc' and 'title' elements but > do not display > 'path' elements or other graphics elements. For deep > hierarchies, and for > following use element references, it is sometimes > desirable to allow the > user to control how deep they drill down into > descriptive text. > > http://www.w3.org/Graphics/SVG/IG/wiki/Accessibility_Activity#Assumptions > SVGIG wiki discussion on this topic... > > > > -- > > >
Received on Tuesday, 29 July 2008 20:17:49 UTC