iirc in every case, where there is a title a tooltip should be raised. in case of more than one, within an open element only the first is used. furthermore and in particular, <use> can reference any named svg resource, ie does not require symbol, g or any other specific element. there is no requirement or expectation that <g>** should be used to enclose titles. **for the singular case where <g> is used, and a title is raised see: https://bugs.webkit.org/show_bug.cgi?id=16854 there has been some debate, about hierarchies of titles, but that is not part of this bug. please check the specs as this is from my poor memory of 6 years ago, or more....
Someone please update the following since the person who raised this did not follow instructions at https://bugs.webkit.org/show_bug.cgi?id=16854#c32 * Please update abstract/title to "Symbol tooltips not being displayed" * Please clear the "HasReduction" keyword (there is no test case attached) * Please clear the "EasyFix" keyword since this is not an easy fix
Jeff, this bug does not relate to <symbol> however that is a testcase, and is in the URI given apologies if this is not an easyfix, hard to guess, as the one fixed evidently was....
Jonathan - please submit a reduced test case that demonstrates your problem in WebKit trunk. Otherwise it is difficult to understand what you feel doesn't work. As far as I know, the only thing that doesn't work is <symbol>. Thanks.
Jeff, you intimated that <g> was needed, this is irrational, but doesn't suggest that everything else works, rather the reverse...
Jonathan - please submit a reduced test case that demonstrates your problem.
Jeff, the test case is the URI, your test case for the previous bug was not helpful, as explained, and you failed to indicate that <defs> <line id="sunny" style="stroke-width:17;stroke:#f0f" x1="22" y1="75" x2="139" y2="75" > <title>line</title> </line> </defs> <use xlink:href="#sunny" x="33" y="72" /> was fixed, either in the comments, or testcase, it's not clear to me why symbol should be treated differently to g, and hence why this is not an easyfix.
(In reply to comment #6) > Jeff, the test case is the URI, > > your test case for the previous bug was not helpful, as explained, and you > failed to indicate that Jay, this is not a way to talk to hard-working contributors. The testcase is NOT THE URI. A reduced testcase is needed, as simple as possible. > <defs> > <line id="sunny" style="stroke-width:17;stroke:#f0f" x1="22" y1="75" x2="139" > y2="75" > > <title>line</title> > </line> > </defs> > <use xlink:href="#sunny" x="33" y="72" /> > > was fixed, either in the comments, or testcase, No one has time to look through complex testcases, you should reduce it, and upload it here. > > it's not clear to me why symbol should be treated differently to g, and hence > why this is not an easyfix. You have no understanding of our internals, so it's hard for you to judge what is hard to fix and what not. Upload a reduced testcase, and someone will be able to investigate.
You might want to read http://webkit.org/quality/reduction.html The URL you have submitted is not a reduced test case - it is a Wikimedia commons-hosted file for showing weather symbols. That file has 24 <symbol> elements and 18 <use> elements and no instructions on how to reproduce the problem you see. Please remove HasReduction keyword if you are able. My test case for Bug 16854 https://bug-16854-attachments.webkit.org/attachment.cgi?id=53317 is concise, has instructions and demonstrates a variety of scenarios in which tooltips on SVG elements now work. As I tried to state at https://bugs.webkit.org/show_bug.cgi?id=16854#c32, the only scenario that doesn't work is when the use references a <symbol> with a <title>. Thus, I had to rework the Wikimedia file as I discussed as a demonstration of a workaround. The details of why this doesn't work have nothing to do with the spec or users perceptions - they have to deal with the WebKit code. The details I believe are that <symbol> is not treated as a visible element (as per spec). As a consequence it is not iterated over when doing the hit-test for mouse hovering. If I could have fixed this for 16854, I would have.