- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Wed, 9 Jul 2008 09:11:15 +0100
- To: Jeff Schiller <codedread@gmail.com>
- Cc: www-svg <www-svg@w3.org>
- Message-Id: <AA11F4A3-CABF-433F-8D72-FAEF5E2AA978@btinternet.com>
Jeff, Does your description, which appears to be a more formal restatement of my suggestion, cover the fruit case I originally gave? http://www.openicon.org/icon-ark/mulberry/fruit.svgz It needs to, but it seems to me it does not, otherwise there is no mechanism for the author to provide this type of structure. The intention is to allow <use> remote file with the title. This is essential for a number of reasons such as otherwise files are being sent and saved unnecessarily across the web it is much harder to update, more or less impossible, a similar issue arose with microformats for addresses etc. the authoring process is very much simpler, Amaya already can copy and paste <use> remote files, it's just a url in a <use> wrapper. no SVG, script, css, rdf, CC-copyright in the clipboard etc... designers can learn which files are popular, and which are not.... Finally I wish to once again make the case that involvement of end- users in the specification process would ensure much simpler and easier to use specifications. I am really disturbed by the SVGWGs current proposed milestones for the next three years: http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-charter.html#deliverables I have repeatedly asked Doug and others to contribute and set aside time to create an SVG microformat. that is a reduced set of minimal essential elements. the purpose being to enable the design of at least one simple and easy to use authoring tool. that the ordinary user or child can use to create good clean simple code. inkscape is already enormous, old and after a decade, has no means to add title content. that is just one example, there is a bug filed. One can hand edit the code, but as mentioned elsewhere a grep of 7000 files on openclipart, 6 had titles. It does seem that the WG consisting of developers working for corporations ensures that bloat is the main course. regards Jonathan Chetwynd j.chetwynd@btinternet.com http://www.openicon.org/ +44 (0) 20 7978 1764 On 9 Jul 2008, at 03:44, Jeff Schiller 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 Wednesday, 9 July 2008 08:20:45 UTC