- From: Jeff Schiller <codedread@gmail.com>
- Date: Tue, 29 Jul 2008 14:44:20 -0500
- To: www-svg <www-svg@w3.org>
- Message-ID: <da131fde0807291244s4e7aa70ejad4c6a65a8ccd42b@mail.gmail.com>
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> 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> 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> 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 >>>> 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 19:45:00 UTC