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

2 points,

1.	 regarding the subject: Whether to display inner or outermost  
<title>?

what is the objection to the proposal that only the outermost title  
should be displayed?
the proposed example is a bowl of fruit.
the rationale being that it is simple, and the author need not provide  
a title where he wishes the inner titles displayed.
alternatively requisite items can be moved from the group and place  
later in the code.

Jeff's proposed solution to provide an outermost title by creating a  
transparent overlayed box with title is untenable and open to  
misinterpretation in almost every case.


2. Doug asked how should <desc> be treated?  Should it also feed into  
the tooltip?
if one is to meet user expectations regarding html desc content should  
be displayed in the body of the window.
Is it amazing that after a decade, no user agent has made any attempt  
to display at this?
see various threads on w3c specification process, and involving the  
user.

displaying SVG title and desc content was raised with lynx developers  
in february, discussion continues, progress is very slow.
http://lists.gnu.org/archive/html/lynx-dev/

bugs have also been filed with:
Opera: bug-353003@bugs.opera.com
Safari: https://bugs.webkit.org/show_bug.cgi?id=20290
Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=449273
Batik: https://issues.apache.org/bugzilla/show_bug.cgi?id=45574

regards


Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.openicon.org/

+44 (0) 20 7978 1764


On 4 Aug 2008, at 09:54, Doug Schepers wrote:

>
> Hi, David-
>
> David Woolley wrote (on 8/4/08 3:19 AM):
>> Doug Schepers wrote:
>>>
>>> Indeed I did read it, and I think that your algorithm is simple  
>>> and effective.  I plan to use it in some proposed wording on the  
>>> topic.  I'm sorry I didn't respond before... but it's definitely  
>>> on my list of todos.
>> First thought: is this really any different from inline containment.
>
> Sorry, can you explain further?
>
>
>>> I also want to define the content model.
>>>
>>> Here's a question for the community: should @display="none" on a  
>>> <title> stop the UA from displaying a tooltip?  As a developer,  
>>> I've often wanted to block Opera's behavior here, because it  
>>> interfered with my own, nicer, home-rolled solution.
>> You are equating <title/> with tooltips.
>
> Not exactly.  I'm just using the looser term for the popup infobox  
> (aka "hover box", “ScreenTip”, etc.).  That's what Opera does with  
> the <title> contents, and that seems to be fairly effective, working  
> on the same paradigm as the link @title.  In the underlying markup,  
> there is a distinction between the roles played by the <title>,  
> <desc>, and <tooltip> elements (note: <tooltip> is a planned element  
> for SVG 1.2 Full).  Since this is the way browsers seem to be  
> trending, and because it is generally helpful, I think it's  
> appropriate that we tighten up the spec to make it an interoperable  
> feature.
>
> We will take pains to leave room for display of the actual semantics  
> that distinguish the 3 elements (and the xlink:title).
>
>
>> Even if one has custom tooltips (which might be reasonable
>> for graphic art, but possibly not for technical drawings)
>
> That depends on what you want to display.  An author may want the  
> infobox to be something other than the element's title, something  
> that supplies related information, for example.
>
>
>> one should not be suppressing aural presentation, and I would argue  
>> that one doesn't really benefit the user by suppressing a status  
>> line display of the title.
>
> Good points.  I will note that the status line and (more  
> importantly) the aural presentation must not be affected by any  
> @display values.
>
>
>> For Jonathon's application, I would argue that consistent  
>> presentation of titles is important, although it is possible that  
>> Jonathon sees that consistency being imposed by his web  
>> application, rather than the basic browser.
>
> As you correctly brought up before, consistency is important in the  
> identification of links, but authors also wish to override that  
> default behavior.  This is no different, and we should give authors  
> the power to adapt the default behaviors to their needs.  In most  
> cases, authors will probably go with the default, so there will be  
> enough consistency to establish the idiom.
>
> In any case, for SVG+CSS UAs, the CSS display property would  
> override the display attribute (though not the inline display  
> property), so user stylesheets could be used to define the behavior,  
> too.
>
> Jonathan should be free to use the native capabilities provided by  
> browsers.  Making sure that the behavior is defined enough is  
> important to make sure that we have interoperability for his use case.
>
> Regards-
> -Doug Schepers
> W3C Team Contact, WebApps, SVG, and CDF
>