(Should this be assigned to Content Model? Parser? Rendering? Viewer App?) "cite", "datetime", "title", "hreflang"... should all be accessible to the user. See the quoted uri for some more information and for some ready made tests to cover this topic. Attribute Elements lang (all) title (all) cite Q, BLOCKQUOTE, INS, DEL datetime INS, DEL hreflang A, LINK href A, LINK longdesc IMG (has its own bug report) Currently, AFAICT only "href" is made available.

This is really an application question rather than a layout issue. Rick: I haven't a *clue* who owns the browser in the new world so if it's not you, then please reassign this to who is the owner so that they can have a debate about the issues here.

My new Evil Test Suite contains an improved version of this test. URI updated.

Changed platform and OS to All, component to Apprunner, and whacked priority and severity. Rick, this is gonna be you and Nisheeth, right?

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

I do not think this will be in for Dogfood. But need to know for sure so I can add to Release Notes.

Changed component to XPApps and milestone target to M4.

Re-assigned to davidm@netscape.com and changed target milestone to M5.

If I understand this bug properly we need a UI design which provides a way for the user to see the metadata? I don't think there is any chance of me doing this anytime soon.

moving to off to m7

I am reassigning to the UE people. If we choose to impliment this feature it will need a spec on how the data is be presented to the user. I have not idea how important this bug is but if a spec is written reassign the bug to me with a pointer to the spec.

Assign it to UI designer to review whether we will need a spec/UI design.

(cc'ing ekrock wrt standards comliance, returning bug to don for cost assessment) If these are attributes for certain HTML 4 tags and if this is required for HTML4 compliance we need to expose this in varied ways (this is a strawman proposal): - as a tooltip for the 'title' attribute showing up on mouseover for the whole element affected. - as statusbar message after the link destination for the attributes lang,hreflang and datetime(in this order if specified/applicable for the element) as shown in http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/metadata.html. The behavior is much like the 'href' attribute shown as status message on mouseOver in 4.x browsers today. I believe a tooltip would be too obstrusive and interventive for the user's browsing experience (due to delay and due to covering up valuable content context). The statusline message would simply show a list of concatenated value attribute pairs. This approach should balance a pleasant browsing experience with the needs of the HTML 4 spec. - For the cite=URI I agree we should add an element to the context menu right before the basic navigation commands and separated from those saying something like "Open Quote Source" which would open a new window. I do not know what to do about the Q element, I am not sure that our stylesheets can support having them rendered as quoted. Anybody?

(cc'ing ekrock wrt standards comliance, returning bug to don for cost assessment) If these are attributes for certain HTML 4 tags and if this is required for HTML4 compliance we need to expose this in varied ways (this is a strawman proposal): - as a tooltip for the 'title' attribute showing up on mouseover for the whole element affected. - as statusbar message after the link destination for the attributes lang,hreflang and datetime(in this order if specified/applicable for the element) as shown in http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/metadata.html. The behavior is much like the 'href' attribute shown as status message on mouseOver in 4.x browsers today. I believe a tooltip would be too obstrusive and interventive for the user's browsing experience (due to delay and due to covering up valuable content context). The statusline message would simply show a list of concatenated value attribute pairs. This approach should balance a pleasant browsing experience with the needs of the HTML 4 spec. - For the cite=URI I agree we should add an element to the context menu right before the basic navigation commands and separated from those saying something like "Open Quote Source" which would open a new window. I do not know what to do about the Q element, I am not sure that our stylesheets can support having them rendered as quoted. Anybody?

Changing to enhancement bug and moving out to M14 ...

I'm not an expert on the DOM, but does alecf's new DOM Viewer (37698C04.9D651741@netscape.com in RDF) expose this information? The picture in that message shows META tags (would a click or mouseover show the attributes?). I think this is a desirable enhancement, but would be happy with getting it through the DOM viewer, although non-savvy users wouldn't necessarily be for the subset of meta-data that concerns them, like Author.

See also bug 2800, concerning the metadata contained in the <LINK> element.

I think that saying the DOM viewer is adequate is on about the same level as saying that the tags show up in View source;)

That's a point. =)

Ok, the strawman proposal has been discussed on the mozilla-ui newsgroup, and I have written a summary of what was brought up. The summary is written as a UI spec. Basically, german's proposal survived. The main new issue present in the full UI spec concerns details such as how to convert language codes (e.g., lang=en) into readable text (e.g., English). SUMMARY OF SUMMARY: * All this should be done in XUL. * We should show 'title' and 'summary' attributes in tooltips. * We need have a status line with three panels, one for UA messages, one for js messages and metadata, and one for language information. * We need code to interpret the metadata attributes into human-readable strings. * We need a new menu item for elements with attributes that are links. The UI spec / thread summary is available online: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt

*** Bug 1358 has been marked as a duplicate of this bug. ***

I don't see a need to have information in the `lang' attribute available to the user. It seems most useful to search engines, etc. See <http://www.w3.org/TR/REC-html40/struct/dirlang.html#h-8.1>.

The UI spec specifically lists the language panel as an item that can be disabled in the preferences settings, so if you don't want to see it you can disable it. Personally, I would find it very useful to know what language a section of text was in if I couldn't understand it. eg: <p> And he said <q lang="de">Ja!</q> immediately. </p> "What language is the fourth word in? Hmm, I am not sure. Lets see. Oh, German. Well there you go." Basically, I am all for being able to show _all_ the metadata we have available.

OK, I finally got around to reading Ian's UI spec. Nice work, Ian! You really have a passion for this. As to the cost assessment ... For the XPApps team to implement the chrome (i.e. the tooltips, status messages, language panel, etc.) we're gonna need a lotta support first from the Gecko team. All this metadata needs to be pushed up to the app in some form of notification or some such if we're gonna show tooltips and status messages. Also, APIs will need to be created by the Gecko team to access additional meta data so the XPApps team can then write XUL chrome display it in the language panel, page info dialog, or whatever. This looks like a lot of work for the Gecko team before we ever get to it over here in XPApps. So ... I'll first need a cost assessment by ekrock (post dogfood/beta) as to whether the Gecko team is up to doing all this infrastructure work for us. If ekrock says "no" or "not yet" then there's not much XPApps can do now.

Adding shuang@netscape.com for evaluation of UE implications. Shuang, could you please scan the proposed UI spec for exposing meta at http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/metadata.html and let us know what you think of the proposal? I'm concerned that splitting the status bar into three portions on a small monitor will lead to a poor user experience (user unable to read any of the messages). Otherwise, the spec is excellent and visionary. However, I doubt that Netscape can provide the engineering time necessary to do these enhancements between now and 5.0. Unless someone on the Internet steps forward, we may have to document this as a known bug for 5.0 and put it on the 5.1 list. Performance and fixing existing bugs have to be highest priorities at this point, and we definitely don't want to delay the 5.0 release for this. Note: a possible middle ground would be a quick-hack right menu option that views raw element source or all attribute/value pairs, or something. Can anyone suggest such an 80/20 solution? That would be more feasible for 5.0. Unless someone can provide a resource to provide a quick-and-dirty first cut solution, I'm afraid that this will wind up on the 5.1 pile.

I have just attached 3 screenshots showing what the UI spec suggests. Attachement 1556: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1556 This screenshot shows how the metadata would be displayed if the cursor was hovering over a link created using this markup: <a href="metadata.html" lang="en-GB" rel="next"> An example of meta data </a> The "next" and the URI are processed and then displayed in the middle status line section, the language is decoded and displayed in the third status line section. The entire window is smaller than 640px wide, and all metadata is displayed adequately, including the UA status message ("Done (1.2 secs)") and the protocol icon. Attachement 1557: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1557 This screenshot shows the status line and tooltip displayed for hovering over the following markup: <ins title="Section inserted to help show what it would look like." cite="http://hpvlpii/moreinfo.html#ins" datetime="1999-09-05T13:53:00+01:00"> <p> This is a new section </p> </ins> The 'title' attribute is displayed in the tooltip, the 'datetime' attribute (once decoded) and and the uri ('cite' attribute) are displayed in the status line's middle section, and the language (which in this case would be the document's language, given by markup similar to <html lang="en">) is displayed in the third section. This time, because the decded date string is relatively long, the URI is not displayed and the UA message ("Done (0.9 secs)") is slightly trimmed. However, the window is smaller than 640px wide and everything is visible at 800px wide. By decoding the 'datettime' attribute to a shorter string, e.g. "Inserted on 05/09/1999 at 15:53" instead of the verbose string shown, all the metadata can probably be shown. Attachement 1558: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1558 This screenshot shows the status line displaying a JavaScript-generated message typically found on websites using the onMouseOver and onMouseOut events and the window.status object. Unlike legacy behaviour, the URI is still visible, as is the UA message. Everything fits comfortably, and the window is still shorter than 640px. ekrock wrote: > I'm concerned that splitting the status bar into three portions on a small > monitor will lead to a poor user experience (user unable to read any of > the messages). It would appear that this would only happen when the status line messages are long, which would typically not happen with current websites. (In fact, because this UI spec says that Javascript status line messages are added to the rest of the messages instead of replacing them, the problem is _less_ than with legacy browser behaviour.)

Reassigning to Shuang for assessment of possible UI to provide access to this data and setting to M19 because this issue is definitely a post-dogfood/beta issue and a lower priority than basic usability of the browser and mail. I hope we can get this issue addressed for the first release, but if we don't we can release note it and shoot for resolution in 5.1.

I think German will have to work on his strewman proposal more after Beta if this will still be reqired. Reassign it to german for m19.

Shuang: His strawman proposal _has_ been worked on. There was a long discussion on the mozilla newsgroups that resulted in the following comprehensive UI spec: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/metadata.html

Shuang: Oops. Wrong URI. I see why you thought that the strawman proposal still needed work. The actual URI for the spec is: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt ...the URI I just quoted (which is the one Eric also quoted) is the test page.

I will read through the latest spec. Since it's not dogfood, I'll put other things higher up on the list.

*** Bug 7045 has been marked as a duplicate of this bug. ***

*** Bug 19129 has been marked as a duplicate of this bug. ***

*** Bug 22822 has been marked as a duplicate of this bug. ***

German, are we going to want this for beta1? I expect the tooltip part of this, certainly, should be implemented by then since it is implemented in legacy browsers. (The statusline side of things can probably wait a milestone or more after beta1, though, IMHO.)

This is definitely not a beta1 blocker. Candidly, because this would require a lot of new work (including UI changes) and is a fairly minor requirement of the spec compared to a lot of other critical priorities we face in terms of producing a usable, commercial-grade product, I'm strongly leaning towards release noting this unless someone from the Internet steps forward to do the work and shuang/german sign off on a UI proposal from that person. I think the proposal for a 3-line status bar won't work because it sacrifices too much screen real estate from the content area to chrome in order to provide functionality few users understand or care about. Ian--Could you clarify what you mean when you say "this" is implemented in "legacy" browsers? Which functionality and which browsers are you referring to?

I was referring to the 'title' attribute causing a tooltip to appear in IE4 and above. (Nav4 does this for the 'alt' attribute, which is wrong but is basically the same idea.) Also, the proposal does not suggest a three _line_ bar, just a three-panel bar, split horizontally. See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1556 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1557 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1558 ...for examples. Nav4 and IE5 _already_ do this kind of thing, although the panels are used for different content. And this is not functionality that "few users understand or care about" -- we are talking about content here. For example, "This section was inserted on the fifth of February". There is nothing particularily complicated about that.

*** Bug 31264 has been marked as a duplicate of this bug. ***

changing qa contact to jrgm@netscape.com on some random bugs

Sorry everyone, but the time has arrived where we have to start making some tough decisions. This won't make nsbeta2, so it's out for FCS. Setting to M20 and marking helpwanted and relnote. The release notes should say something like "HTML 4.0 specifies that all metadata attributes should be visible through the UI. Currently, the following attributes are visible only through the DOM viewer: _______" (can someone please fill in the list?) Outstanding issues to be resolved when we revisit this: 1) I'm concerned that a three-panel status bar would lead to having three panels which were each too narrow to display all their contents, creating an unpleasant UE and frustration at the fact that panels always showed "cut off" text. 2) For some of the elements that have been mentioned as examples such as INS and DEL, the HTML 4.0 spec passed on defining any standard way to express things in a meaningful way. e.g. "This section was inserted on the fifth of February" is readable English, but what if IE or Opera or an authoring application were to express the same idea as "2000/02/05-ins-section" for example? The reality is that since the standard took a bye on defining a meaningful way to interoperate, even if one browser implements its own way to express such ideas, interoperable handling/parsing of semantically meaning info is unlikely to occur.

To solve problem #1: every previous version of Navigator has merged the UA bar and the metadata bar (flicking between the two depending on the cursor position), and I don't see why this practice can't be continued. The only problem with this approach would be if BODY itself has metadata; and BODY metadata would probably belong in Page Info, or in the same frame used to show LINK elements -- not in the status bar.

When hovering over a link, the title attribute could be displayed in the status bar followed by the href attribute. That doesn't require a multi-pane status bar and could likely be implemented sooner than the advanced metadata display.

I have the tooltip side implemented, more or less. It's a very very small patch, a one-line bug fix to nsXULPopupListener.cpp and a short snippet of XUL/JS which lives in the chrome. I am displaying IMG ALT attributes if the element has no TITLE element, because it matches Nav4 behaviour and I find it useful. One question: if the hovered element has no TITLE attribute, I plan to go up through its parents in the document tree until I find a parent that has a TITLE element (or reach the top), and display that. Is that a good idea or a bad idea?

Please do *NOT* display image ALT attributes as tooltips. This encourages people to use ALT attributes for tooltips, which is wrong. ALT attributes have a very important purpose, which is to provide replacement text for images for browsers that cannot or do not (by user's choice) display images, and if graphical browsers display them as tooltips people will be discouraged from using them for their correct purpose. MSIE gets this correct. Going up through the tree does sound correct.

My copy of MSIE (5.01, Win98) does indeed display IMG ALT tags as tooltips. I find this perfectly useful... dbaron, why again is this a bad thing? I don't understand why this would discourage people from using them "correct[ly]".

I agree with David, *don't* the ALT attributes as tooltips. *PLEASE* don't. Displaying it as a tooltop will cause people to continue using the ALT attribute for text which really isn't appropiate as alternate text (see <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/alt-text.html>). If they want tooltips, there are *no* reason not to use the TITLE attribute.

See http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html

How odd that three of us tried to post the same link within five minutes of each other ... The relevant section: `Version by version, popular graphical browsers got worse and worse in their display of ALT texts when auto image loading was off. Then they seem to have hit upon the idea of remedying the loss by displaying the ALT texts as "tooltips" when the mouse pointer was on the image location. Perhaps that wasn't such a bad idea in itself, but plenty of authors seem to have reacted by using the ALT text to specify their desired tooltip text, regardless of the fact that it was an entirely inappropriate text for use as the "alternative text" described in the HTML specifications. `Well, HTML4.0 has an answer to this: the TITLE attribute. The HTML4.0 spec says explicitly that it would be appropriate for the TITLE attribute to be displayed as a "tooltip", so it all falls into place. Use the ALT text for the purpose of providing alternative text, for example along the lines discussed in this article, and use the TITLE element to title the image, in a way that would be appropriate for a tooltip. MSIE4 already supports this, for one example, and can be configured (via a checkbox on the Advanced Preferences menu) to display the whole ALT text on the page when images aren't loaded.' My two cents: If it encourages bad author behavior (as tool-tipping ALT does), and it's not required by any W3C recommendation (as tool-tipping ALT isn't), then don't do it.

"If it encourages bad author behavior (as tool-tipping ALT does), and it's not required by any W3C recommendation (as tool-tipping ALT isn't), then don't do it." Sounds like the old argument dictionary editors go through all the time: do we design to reflect the actual usage, or do we insist that people change their behavior? Removing self from cc: list, leaving this up to youse guys instead.

We are unlike dictionary editors in that the choice we make actually will change people's behavior.

Robert: Since you are writing a patch for this, could you please take a look at the current UI proposal: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt ...and in particular look at the "FREE FORM TEXT: title AND summary" section. Thanks.

Fear not. I am following the spec faithfully. I am also ignoring IMG ALT. Pinkerton has already accepted my 1-line C++ patch and it should be checked in today. I'm just polishing up the XUL/JS now. There are still a few ambiguities to thrash out; it'll be easier to do that once I've posted some proposed code.

Nominating for nsbeta2 consideration by the PDT. If not, then nsbeta3. But this _must_ go in - people have been wanting correct tooltips on graphics for ages. :-) Gerv

Patch 8757 is the C++ code that Pinkerton already agreed to check in. I'm putting it here just so that it doesn't get lost. I hope the logic of my code is clear. I start at the moused-over node and search through it and then its parents, looking for the first node that either has a nonempty TITLE attribute or is a TABLE with a nonempty SUMMARY attribute. If no such node is found, I bail out without creating a tooltip. Otherwise I take the TITLE and/or SUMMARY text for the node and put them into the tooltip. Please comment if you think this is suboptimal. A lot could be done with tooltips in general. It wouldn't be hard to make "developer" tooltips that display the tag and attributes of any element you mouse over. Since the tooltip can contain arbitrary content, the sky's the limit. Gerv: This is NOT going to provide tooltips on images for most existing Web pages. See the discussion here for how I was talked out of that :-).

The C++ fix has landed. As soon as new builds appear, you can try the tooltips by manually applying the changes to your Navigator chrome.

This would also be nice to have for XLink title attribute. I tried Robert O'Callahan's DOMTips, and they worked quite well. However, where is the code for the real tooltips? Anyway, if the tooltips are done with JS (like DOMTips), then this line of JS will get the value to display for simple XLinks: var xlinkTitle = <somenode>.getAttributeNS("http://www.w3.org/1999/xlink","title");

I have updated the UI spec to take into account XLink's 'title' attribute. http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt

The real tooltips are right here, in patch 8750. The spec says "TITLE: most elements". Currently I'll take it from any HTML element. Is that OK? I'm going to update the patch. Can someone give me a test case for XLink title? I'm XLink ignorant. Also, what if an element has an HTML TITLE and an XLink title (and a TABLE SUMMARY :-) )? I think I'll treat an XLink title identically to an HTML TITLE and if an element has both, I'll ignore the XLink title. One other thing: currently if an element has an HTML TITLE then you are guaranteed to get a tooltip when you mouse over any of its children. It might be useful to provide some way for authors to create children which do not show tooltips even if their parents do. One way to do this would be to give the children an "empty" TITLE (all whitespace) and suppress tooltips containing only whitespace. Thoughts?

If there is more than one tooltip value for a given item, I'd put them in the one tooltip, separated by blank lines, and ordered with the most specific text (i.e. that for the innermost element) first.

The updated patch adds support for XLink title, drops attributes that contain only whitespace (which enables child elements to hide tooltips even if their parents have a TITLE attribute), and uses createElementNS for better robustness. mpt: I personally think child elements should override parent tooltips, instead of extending them.

> The spec says "TITLE: most elements". Currently I'll take it from any HTML > element. Is that OK? Yes, that is what I intended. The HTML spec does not say that "title" can be used on all elements, but in all cases where it _can_ be used, then it is ok to use it for a tooltip. > What if an element has an HTML TITLE and an XLink title (and a TABLE > SUMMARY :-) )? I think I'll treat an XLink title identically > to an HTML TITLE and if an element has both, I'll ignore the XLink title. No, I would show all three. See the spec (I changed it a few minutes ago (when XLinks were first brought up) to take this into account). > [...] One way to do this would be to give the children an "empty" TITLE (all > whitespace) and suppress tooltips containing only whitespace. Thoughts? Great idea. At the moment, do we show the empty tooltip if there is one? That would be a bad thing. I would suggest that tooltips consisting of only whitespace should not be shown. The spec has been updated to show this. BTW, Robert: Thanks for implementing this, you are a star!

The updated patch displays all three strings when present. Well, I hope it does: Mozilla currently barfs on HTML elements containing XLink attributes so I can't really test the 3-string case. Any whitespace-only string is suppressed. If all strings are suppressed, then the entire tooltip is suppressed. In the spec you asked for wrapping text. I agree that this would be nice, but currently tooltips can't wrap properly so I don't try. (I discovered this when I tried using wrapping in my DOMTips patch. I set max-width: 500px on the block container, and the text wrapped OK but the tooltip did not extend its height; I suspect popups currently don't resize themselves after they're created. End result: a nice-looking tooltip with a scrollbar :-).)

Try setting "height:auto" on the tooltip element's style. If the tooltip is absolutely positioned, then that should do the trick (some changes went in recently to alter this). What do you mean by "Mozilla currently barfs on HTML elements containing XLink attributes" -- is it a serious error, or does it just not recognise XML things on HTML documents? If the later, then it should work if the HTML is given as XHTML (this is left as an exercise to the reader...).

That file triggers an assertion which explicitly says it's unhappy at finding a non-HTML attribute on an HTML element. Ignoring the assertion, Mozilla doesn't crash but tooltips don't work at all. Variations on that file crash Mozilla hard, but I haven't got time to track that one down.

"height: auto" doesn't help at all. I can track this down and fix it sometime later.

The tooltip issues are now covered by bug 27828.

To answer Eric's points from 2000-04-21: > The release notes should say something like "HTML 4.0 specifies that > all metadata attributes should be visible through the UI. Currently, > the following attributes are visible only through the DOM viewer: > _______" (can someone please fill in the list?) datetime, lang, hreflang, rel, rev, action, longdesc, and cite. (That's assuming that title and summary are shown by Robert's tooltips, and longdesc is fixed -- see bug 1996. longdesc should be a very simple fix. In fact, Robert, you may be interested in looking at it after the tooltips are checked in...) > 1) I'm concerned that a three-panel status bar would lead to having > three panels which were each too narrow to display all their > contents, creating an unpleasant UE and frustration at the fact that > panels always showed "cut off" text. But we currently have four sections! The sidebar, the progress bar, the UA message line, and the build ID. I am merely suggesting that we swap the build ID for the language status line, the UA status line for the metadata status line, and the progress bar for a combined progress bar + UA status line section, depending on context. > For some of the elements that have been mentioned as examples such > as INS and DEL, the HTML 4.0 spec passed on defining any standard > way to express things in a meaningful way. e.g. "This section was > inserted on the fifth of February" is readable English, but what if > IE or Opera or an authoring application were to express the same > idea as "2000/02/05-ins-section" for example? What of it? That doesn't matter to us. We should display it in what we think is the best way. Are we worried about how/where we currently display the "href" attribute metadata? Opera displays it as a tooltip, we display it in the UA status line. So what? > The reality is that since the standard took a bye on defining a > meaningful way to interoperate, even if one browser implements its > own way to express such ideas, interoperable handling/parsing of > semantically meaning info is unlikely to occur. No, because the standard is very explicit about the format the data should be *stored* in (on which the "interoperable handling/parsing of semantically meaning info" depends), it is merely how we _display_ it that is in question here.

Checking with don, german, ekrock, and hangas on status of all these issues. Putting on [NEED INFO] radar.

Per german; "I will not have time to even touch this for the beta2 time frame. If technically easy and safe we should probably get it in. Although the bug is long and winding, I think it is harmless for the 90% user case. But getting it in would get it some real world user exposure, so we can see whether it works for those who use it. That we the contributors would have a chance to make it better for beta 3..." Setting to [nsbeta2-], adding nsbeta3 keyword.

Even if the rest of this bug is pushed out, it would be cool if someone could check in the tooltip code. The TITLE attribute seems quite useful, and we need to start reeducating Web designers to use it instead of IMG ALT.

Shuang, could you arrange for the checkin of the TITLE tooltips?

I want this too, but it's unclear which patch I want. All of ``Patch to make XUL tooltips work properly across Documents''?

That C++ patch was already checked in by Mike Pinkerton, weeks ago. You want the XUL/JS code in "version 3 browser tooltips". Actually, that patch had a couple of conflicts with recent tree changes; I'll give you a new version.

Updated the patch to use correct (X)HTML namespace. Someone else is going to have to check this in. I can't get secure CVS access (don't ask).

Clearing nsbeta2 nomination and moving all TITLE patch related stuff to bug 27828.

about the rest of the attributes (not title). How about showing them in a "properties" dialog that are avalible in the context-menu (ala IE). This "properties" dialog is really a very nice feature in IE and a perfect place for showing metadata stuff.

Adding PATCH keyword for easier querying. The patch should really be checked in by somebody with the permission!

Removing patch keyword. See bug 27828 to track the status of the tooltip patch. No patch has been submitted to fix the other metadata issues discussed in the given UI specification.

Since this bug suggests re-using status areas we already have to display meta data this could be a good thing, although few of the top 500 pages actually use meta data in that standard way. I want somebody that works on checking in the browser engineering pieces to take that bug away from me, it is still help wanted as far as I am concerned. The patches and suggestions have matured to a point though where in IMO it would useful and safe to integrate them. I am assigning this to Don's eng team for now.

*** Bug 47575 has been marked as a duplicate of this bug. ***

nav triage team: nsbeta3-

Question: Should Mozilla also handle (i.e. show somehow) the summary-tag of table? http://www.w3.org/TR/html4/struct/tables.html#adef-summary "summary = text [CS] This attribute provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille." Thus we don't need support it, but on the other hand, I'd like to make use of something which I can (and do) define. Still remains the question how to handle this; it probably won't fit into the status bar, the tooltip is used for title,...

Regarding 2000-09-08 comments by Tobias: If it's primarily for non-visual UA's benefit, maybe Mozilla simply needs to "recognize" it but not do anything with that info.

For TABLE SUMMARY, see bug 45735.

> For TABLE SUMMARY, see bug 45735. Well, this is about having the table summery *not* in a tooltip, which I think is good. The question was: Can we have this similar to lang, cite-url, datetime hrefland etc. somehow make available (not via tooltip, but also not via view|source), I think it might be usefull, should be available easily, but shouldn't pop up in a tooltip.

As for *lang, I think, that should be used in processing, not directly displayed to the user. Assuming the languages in prefs are sat correctly, text in other languages could just be removed or so, similarly links to resources in other languages could be ignored or displayed in another color. cite-url is bug 37209, or at least similar to that, not?

BenB: no, that is the wrong use of lang. <p xml:lang="en"> Food's ready, <span xml:lang="fr">bon appetit</span> ! </p> ...should display as: Food's ready, bon appetit ! ...and not: Food's ready, ! The language information is as useful as the other metadata.

hixie, you're right, I should have read the spec first. Sorry.

So in theory, would babelfish or some translator be able to take <span xml:lang="fr">Bonjour</span> <span xml:lang="es">senior.</span> And translate that to English <span babelfish:lang="fr">Hello</span> <span babelfish:lang="es">sir.</span> ?

timeless: assuming that the parent node had the following attributes set: xmlns:babelfish="..." xml:lang="en" ...then yes, I guess.

Taking QA per managerial policy.

Changing severity to enhancment and moving to "Future" milestone.

how can this be an enhancement? It is a html4 conformance requirement

This is an enhancement request because we don't have the functionality in the product yet. An enhancement is orthogonal to conformance.

If tables were not yet implemented, they were an enhancement, too?

Making an optimistic target milestone nomination.

Yes. :-)

Jonas: What part(s) of this bug are a conformance requirement for HTML 4.0? Don: This might be an enhancement with respect to Netscape's product; but if it is in fact an HTML4 conformance blocker, it should not be considered an enhancement with respect to Mozilla 1.0 (which is what this bug db is for).

I was given the impression from previous discussions here that this in the spec. But I can't find it anywhere in the html4 spec that this is a requirement for conformance.

Almost nothing in HTML4 is a conformance requirement. Even things like <p> are not required to be a "conforming implementation". Some of the few things that _are_ requirements are: quotes around the content of <Q> elements (don't ask me how you are supposed to do that if you are not a visual browser), and no default character set selection (which is impossible short of refusing to display a page that has no charset specified -- i.e., most of the web). Conformance in HTML terms is not really a useful concept. Of course, this is still a requirement for full support of HTML4, as are all the bugs that block meta bug 7954.

Fair enough. I think that means this shouldn't be considered an "enhancement" with respect to Mozilla 1.0. That said, this bug is covering a number of issues which aren't necessarily related (in implementation). I think it ought to be broken up.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: What's the current status of this bug? Is the last patch enough to fix this bug? Marking nsbeta1- for the moment and reassigning to pchen so that it doesn't get too lost in the shuffle.

the attatched patches adds an "properties" entry to the context menu. When selected it opens a window with a bunch of information about the clicked tag and document, including all of the metadata discussed in this bug. So if you rightclick on an image that is also a link you get info about the both the link and the image. I would like to add even more data (such as physical info about an image), but that could be done later...

+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ please us 2 2, and mark it java instead of c.

no, we are not enforcing tab-widths on new files. It is up to the file author to make sure that the tab width actually matches the emacs line, but that is it. Personally I prefer 4, but I would never force opinion on someone else. When modifying an existing file it's important that they match of course, but not for new files. I will not have time to review this patch (due to it's size) before 1/15...sorry. Feel free to find another super-reviewer, or just wait until then.

Is this patch still being actively reviewed?

There are a couple of minor things I want before rerequesting a review. Will hopefully be able to do this during next week

*** Bug 68410 has been marked as a duplicate of this bug. ***

W3C `Common user agent problems' <http://www.w3.org/TR/2001/NOTE-cuap-20010206>, 1.9: When a Web resource includes metadata that may be recognized by the user agent, allow the user to view that metadata.

*** Bug 69877 has been marked as a duplicate of this bug. ***

ok, talked with sicking on irc, discussed: - getElementsByTagName - yeah, it's inefficient, but it's not too slow even on large documents - we will avoid it wherever possible by using document.images and so forth, but it's hard to avoid using it for "base" tags.. so we'll avoid it wherever possible. - getAbsoluteURI - there isn't really an accessable way of doing this from js yet - dom3 will eventually have a getBaseURI or something, so that should avoid the above issue for "base" tags.. but until then we'll just leave in sicking's implementation. assuming the changes are straight forward to change from getElementsByTagName("IMG") and .images, etc, then sr=alecf

The above patch (ver 4) has new namespace handling as well as uses Node.ELEMENT_TYPE rather then 1 when checking nodetype. Also changed if (multipleFound) img = false; to if (multipleFound) img = null; in getImageForMap(map)

I assume you've tested this extensively. r=jag if you fix those code comments I mentioned on irc. Feel free to do whatever you like with the space nits.

Is this the right place (bug) for discussing support for the Dublin Core metadata standard (<URL: http://www.lub.lu.se/cgi-bin/nmdc.pl >)? This info should be available in the page info dialog.

This bug is about metadata in HTML 4 attributes. This bug report is also already very long. I think it would be better to file another bug about displaying Dublin Core metadata (expressed in <meta> tags in text/html and in RDF in applications of XML) in the Page Info window.

Alecf, could you sr this again (and check in aswell?). Nothing has changed codewise since version 4 and the only thing that's changed since your sr is new namespace handling. This code is starting to get rather old...

sorry, my bad.. I got as far as backing the old properties.* files out of my build so I could check this one in, and then never finished... I'll try to get to this soon

Oh, btw. I actually did one more thing in the last version. I removed the access-key on the context-menu-item since "p" was already used for "paste". Paste exists in the contextmenu for form-controls.

> This bug is about metadata in HTML 4 attributes. This bug report is also > already very long. I think it would be better to file another bug > about displaying Dublin Core metadata Done. If anybody's interested, see bug #73992.

ok, fix is finally in! thanks!

Reopening. This can't be fixed since there are four open bug this depends on (bug #1996, #18779, #37209 and #57399).

Yes this is fixed. It is not an uncommon situation that a bug is fixed although it is marked to have dependencies. The feature asked for is implemented and that is what matters Please don't reopen bugs unless it has regressed or was closed prematurely, and fixing the bug does *not* count as a prematurely

verified. Other bugs have been opened on the feature now.

This bug originally was written up because several metadata attributes were not accessible to user. Attributes included title, cite, datetime, longdesc, etc. I see where tooltips have been implemented for the title attribute and there are other bugs written up for 'cite' as an attribute of BLOCKQUOTE and 'longdesc' as an attribute of IMG, but I see nothing referring to 'cite' attribute of INS and DEL or 'datetime' attribute of INS and DEL. I don't consider this bug 'fixed' but since it is SO long, I will write up new bugs for the above and refer to this bug for additional info.

rightclick on the quote/ins/del and select properties. Then you should be able to see the data you want.

*** Bug 97711 has been marked as a duplicate of this bug. ***

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

Regressed by bug 513147. No longer fixed; should be reopened.

You should probably file a new bug that is blocking bug 513147.