Re: Whether to display inner or outermost <title>?

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...
>>>
>>>
>>
> --
>