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

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