Last Comment Bug 1995 - (metadata) [RFE] metadata attributes not accessible to use
(metadata)
: [RFE] metadata attributes not accessible to use
Status: VERIFIED FIXED
relnote-user
: helpwanted, relnote
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
: P4 enhancement with 2 votes (vote)
: Future
Assigned To: Jonas Sicking (:sicking) PTO Until July 5th
: Hixie (not reading bugmail)
Mentors:
http://www.bath.ac.uk/%7Epy8ieh/inter...
: 1358 7045 19129 22822 31264 47575 69877 97711 (view as bug list)
Depends on: 37209 57399 longdesc 18779 27828 45380 iptc 106420
Blocks: html4.01 68410
  Show dependency treegraph
 
Reported: 1998-12-19 13:06 PST by Hixie (not reading bugmail)
Modified: 2010-12-05 22:38 PST (History)
25 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Screenshot of metadata displayed when hovering over a link. (16.15 KB, image/png)
1999-09-05 09:04 PDT, Hixie (not reading bugmail)
no flags Details
Screenshot of metadata displayed for an <ins> inserted section </ins>, with notes. (29.04 KB, image/png)
1999-09-05 09:05 PDT, Hixie (not reading bugmail)
no flags Details
Screenshot of status line displaying a JavaScript-generated message shown when hovering over a link. (2.34 KB, image/png)
1999-09-05 09:08 PDT, Hixie (not reading bugmail)
no flags Details
Navigator chrome for HTML TITLE and TABLE SUMMARY tooltips (3.28 KB, patch)
2000-05-16 15:46 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
Patch to make XUL tooltips work properly across Documents (1.08 KB, patch)
2000-05-16 17:43 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
Test case (894 bytes, text/html)
2000-05-16 17:44 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
Simple XLink test case with XLink title attribute (281 bytes, text/xml)
2000-05-17 07:42 PDT, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details
Updated browser tooltip code (3.71 KB, patch)
2000-05-17 07:46 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
Version 3 browser tooltips (3.46 KB, patch)
2000-05-17 08:43 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
XML file trying to present an HTML TABLE with XLink attribute (594 bytes, text/xml)
2000-05-17 09:20 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
TITLE tooltips patch, version 4 (3.41 KB, patch)
2000-06-06 13:17 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
TITLE tooltips patch version 5 (3.45 KB, patch)
2000-06-15 12:10 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
part1 of properties window patch (14.04 KB, patch)
2001-01-02 22:10 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 of properties window patch (21.25 KB, patch)
2001-01-02 22:11 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 1 of properties windows, ver 2 (7.51 KB, patch)
2001-03-13 13:00 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 of properties windows, ver 2 (21.60 KB, patch)
2001-03-13 13:00 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 1 of properties windows, ver 3 (7.05 KB, patch)
2001-03-13 16:04 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 of properties windows, ver 3 (22.11 KB, patch)
2001-03-13 16:05 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 1 of properties windows, ver 4 (7.05 KB, patch)
2001-03-14 10:14 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 of properties windows, ver 4 (22.49 KB, patch)
2001-03-14 10:14 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 of properties windows, ver 5 (works with part1 v4) (22.23 KB, patch)
2001-03-18 16:16 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
part 2 ver 6 (spell/space fixes) (22.22 KB, patch)
2001-03-18 17:25 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
Part 1 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around (7.21 KB, patch)
2001-03-19 12:56 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
Part 2 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around (22.47 KB, patch)
2001-03-19 12:56 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
Part 1 Ver 8. Updated to new XUL syntax (7.07 KB, patch)
2001-03-27 16:49 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review
Part 2 Ver 8. Updated to new XUL syntax (22.47 KB, patch)
2001-03-27 16:50 PST, Jonas Sicking (:sicking) PTO Until July 5th
no flags Details | Diff | Review

Description Hixie (not reading bugmail) 1998-12-19 13:06:30 PST
(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.
Comment 1 kipp 1999-01-06 18:19:59 PST
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.
Comment 2 Hixie (not reading bugmail) 1999-01-23 15:08:59 PST
My new Evil Test Suite contains an improved version of this test.
URI updated.
Comment 3 don 1999-03-05 17:17:59 PST
Changed platform and OS to All, component to Apprunner, and whacked priority and
severity.

Rick, this is gonna be you and Nisheeth, right?
Comment 4 Paul MacQuiddy 1999-03-05 21:58:59 PST
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Comment 5 leger 1999-03-10 07:32:59 PST
I do not think this will be in for Dogfood.  But need to know for sure so I can
add to Release Notes.
Comment 6 don 1999-03-10 20:01:59 PST
Changed component to XPApps and milestone target to M4.
Comment 7 don 1999-04-07 01:22:59 PDT
Re-assigned to davidm@netscape.com and changed target milestone to M5.
Comment 8 davidm 1999-04-13 21:33:59 PDT
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.
Comment 9 davidm 1999-04-15 18:05:59 PDT
moving to off to m7
Comment 10 davidm 1999-05-13 15:43:59 PDT
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.
Comment 11 shuang (gone) 1999-05-13 18:02:59 PDT
Assign it to UI designer to review whether we will need a spec/UI design.
Comment 12 german 1999-05-21 10:41:59 PDT
(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?
Comment 13 german 1999-05-21 10:42:59 PDT
(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?
Comment 14 don 1999-06-04 19:42:59 PDT
Changing to enhancement bug and moving out to M14 ...
Comment 15 Matthew Tuck [:CodeMachine] 1999-06-21 18:15:59 PDT
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.
Comment 16 Hixie (not reading bugmail) 1999-06-21 20:06:59 PDT
See also bug 2800, concerning the metadata contained in the <LINK> element.
Comment 17 davidm 1999-06-30 14:12:59 PDT
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;)
Comment 18 Matthew Tuck [:CodeMachine] 1999-07-02 04:20:59 PDT
That's a point.  =)
Comment 19 Hixie (not reading bugmail) 1999-07-03 12:33:59 PDT
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
Comment 20 Hixie (not reading bugmail) 1999-07-03 12:43:59 PDT
*** Bug 1358 has been marked as a duplicate of this bug. ***
Comment 21 russell 1999-07-30 08:48:59 PDT
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>.
Comment 22 Hixie (not reading bugmail) 1999-08-29 08:53:59 PDT
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.
Comment 23 don 1999-08-30 12:15:59 PDT
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.
Comment 24 ekrock's old account (dead) 1999-08-30 13:26:59 PDT
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.
Comment 25 Hixie (not reading bugmail) 1999-09-05 09:04:59 PDT
Created attachment 1556 [details]
Screenshot of metadata displayed when hovering over a link.
Comment 26 Hixie (not reading bugmail) 1999-09-05 09:05:59 PDT
Created attachment 1557 [details]
Screenshot of metadata displayed for an <ins> inserted section </ins>, with notes.
Comment 27 Hixie (not reading bugmail) 1999-09-05 09:08:59 PDT
Created attachment 1558 [details]
Screenshot of status line displaying a JavaScript-generated message shown when hovering over a link.
Comment 28 Hixie (not reading bugmail) 1999-09-05 09:30:59 PDT
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.)
Comment 29 ekrock's old account (dead) 1999-09-10 12:13:59 PDT
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.
Comment 30 shuang (gone) 1999-09-16 18:22:59 PDT
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.
Comment 31 Hixie (not reading bugmail) 1999-09-27 05:38:59 PDT
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
Comment 32 Hixie (not reading bugmail) 1999-09-27 05:43:59 PDT
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.
Comment 33 german 1999-10-06 15:46:59 PDT
I will read through the latest spec. Since it's not dogfood, I'll put other
things higher up on the list.
Comment 34 Hixie (not reading bugmail) 1999-11-11 14:43:59 PST
*** Bug 7045 has been marked as a duplicate of this bug. ***
Comment 35 Hixie (not reading bugmail) 1999-11-17 16:33:59 PST
*** Bug 19129 has been marked as a duplicate of this bug. ***
Comment 36 Nicholas Cull 1999-12-30 01:23:59 PST
*** Bug 22822 has been marked as a duplicate of this bug. ***
Comment 37 Hixie (not reading bugmail) 2000-02-07 07:20:19 PST
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.)
Comment 38 ekrock's old account (dead) 2000-02-07 10:29:48 PST
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?
Comment 39 Hixie (not reading bugmail) 2000-02-08 14:12:21 PST
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.
Comment 40 Jonas Sicking (:sicking) PTO Until July 5th 2000-03-24 22:36:00 PST
*** Bug 31264 has been marked as a duplicate of this bug. ***
Comment 41 Paul MacQuiddy 2000-04-10 23:47:50 PDT
changing qa contact to jrgm@netscape.com on some random bugs
Comment 42 ekrock's old account (dead) 2000-04-21 08:59:52 PDT
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.
Comment 43 Matthew Paul Thomas 2000-04-23 23:05:23 PDT
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.
Comment 44 Henri Sivonen (:hsivonen) 2000-05-11 10:10:46 PDT
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.
Comment 45 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 08:10:04 PDT
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?
Comment 46 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-05-16 08:18:32 PDT
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.
Comment 47 cpratt 2000-05-16 08:24:51 PDT
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]".
Comment 48 Karl Ove Hufthammer 2000-05-16 08:30:35 PDT
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.
Comment 49 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-05-16 08:32:14 PDT
See http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html
Comment 50 Matthew Paul Thomas 2000-05-16 08:39:34 PDT
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.
Comment 51 cpratt 2000-05-16 10:37:38 PDT
"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.
Comment 52 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-05-16 10:46:58 PDT
We are unlike dictionary editors in that the choice we make actually will change
people's behavior.
Comment 53 Hixie (not reading bugmail) 2000-05-16 12:05:05 PDT
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.
Comment 54 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 12:16:13 PDT
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.
Comment 55 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 15:46:46 PDT
Created attachment 8750 [details] [diff] [review]
Navigator chrome for HTML TITLE and TABLE SUMMARY tooltips
Comment 56 Gervase Markham [:gerv] 2000-05-16 16:41:12 PDT
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
Comment 57 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 17:43:04 PDT
Created attachment 8757 [details] [diff] [review]
Patch to make XUL tooltips work properly across Documents
Comment 58 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 17:44:17 PDT
Created attachment 8758 [details]
Test case
Comment 59 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 18:03:17 PDT
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 :-).
Comment 60 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-16 19:47:15 PDT
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.
Comment 61 Heikki Toivonen (remove -bugzilla when emailing directly) 2000-05-17 06:42:31 PDT
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");
Comment 62 Hixie (not reading bugmail) 2000-05-17 06:56:11 PDT
I have updated the UI spec to take into account XLink's 'title' attribute.
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt
Comment 63 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 07:18:41 PDT
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?
Comment 64 Matthew Paul Thomas 2000-05-17 07:32:46 PDT
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.
Comment 65 Heikki Toivonen (remove -bugzilla when emailing directly) 2000-05-17 07:42:09 PDT
Created attachment 8773 [details]
Simple XLink test case with XLink title attribute
Comment 66 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 07:46:27 PDT
Created attachment 8775 [details] [diff] [review]
Updated browser tooltip code
Comment 67 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 07:51:10 PDT
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.
Comment 68 Hixie (not reading bugmail) 2000-05-17 07:52:24 PDT
> 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!
Comment 69 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 08:43:57 PDT
Created attachment 8779 [details] [diff] [review]
Version 3 browser tooltips
Comment 70 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 08:53:09 PDT
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 :-).)
Comment 71 Hixie (not reading bugmail) 2000-05-17 09:14:28 PDT
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...).
Comment 72 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 09:20:10 PDT
Created attachment 8783 [details]
XML file trying to present an HTML TABLE with XLink attribute
Comment 73 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 09:22:48 PDT
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.
Comment 74 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-17 09:27:58 PDT
"height: auto" doesn't help at all. I can track this down and fix it sometime 
later.
Comment 75 Hixie (not reading bugmail) 2000-05-21 02:21:50 PDT
The tooltip issues are now covered by bug 27828.
Comment 76 Hixie (not reading bugmail) 2000-05-21 13:22:21 PDT
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.
Comment 77 leger 2000-05-22 17:03:11 PDT
Checking with don, german, ekrock, and hangas on status of all these issues.  
Putting on [NEED INFO] radar.
Comment 78 leger 2000-05-23 13:56:46 PDT
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.
Comment 79 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-05-23 14:09:07 PDT
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.
Comment 80 Matthew Paul Thomas 2000-05-24 02:01:49 PDT
Shuang, could you arrange for the checkin of the TITLE tooltips?
Comment 81 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-06-06 12:50:35 PDT
I want this too, but it's unclear which patch I want.  All of ``Patch to make
XUL tooltips work properly across Documents''?
Comment 82 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-06-06 13:16:56 PDT
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.
Comment 83 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-06-06 13:17:58 PDT
Created attachment 9720 [details] [diff] [review]
TITLE tooltips patch, version 4
Comment 84 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-06-15 12:10:03 PDT
Created attachment 10191 [details] [diff] [review]
TITLE tooltips patch version 5
Comment 85 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2000-06-15 12:11:18 PDT
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).
Comment 86 Hixie (not reading bugmail) 2000-06-15 12:35:18 PDT
Clearing nsbeta2 nomination and moving all TITLE patch related stuff to 
bug 27828.
Comment 87 Jonas Sicking (:sicking) PTO Until July 5th 2000-06-18 19:33:28 PDT
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.
Comment 88 Sebastian Späth 2000-06-21 13:56:57 PDT
Adding PATCH keyword for easier querying. The patch should really be checked in 
by somebody with the permission!
Comment 89 Hixie (not reading bugmail) 2000-06-21 15:52:46 PDT
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.
Comment 90 german 2000-07-26 07:07:42 PDT
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.
Comment 91 R.K.Aa. 2000-08-04 06:34:08 PDT
*** Bug 47575 has been marked as a duplicate of this bug. ***
Comment 92 johng 2000-08-08 11:41:15 PDT
nav triage team:
nsbeta3-
Comment 93 Tobias Burnus 2000-09-08 05:17:59 PDT
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,...
Comment 94 Tim Larson 2000-09-08 05:59:38 PDT
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.
Comment 95 Matthew Paul Thomas 2000-09-08 19:50:11 PDT
For TABLE SUMMARY, see bug 45735.
Comment 96 Tobias Burnus 2000-09-09 01:57:14 PDT
> 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.
Comment 97 Ben Bucksch (:BenB) 2000-09-09 16:16:25 PDT
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?
Comment 98 Hixie (not reading bugmail) 2000-09-10 20:27:00 PDT
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.
Comment 99 Ben Bucksch (:BenB) 2000-09-10 20:53:55 PDT
hixie, you're right, I should have read the spec first. Sorry.
Comment 100 timeless 2000-09-10 22:18:13 PDT
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>
?
Comment 101 Hixie (not reading bugmail) 2000-09-10 23:14:03 PDT
timeless: assuming that the parent node had the following attributes set: 
   xmlns:babelfish="..." xml:lang="en"
...then yes, I guess.
Comment 102 Hixie (not reading bugmail) 2000-10-01 16:57:49 PDT
Taking QA per managerial policy.
Comment 103 don 2000-10-01 17:08:59 PDT
Changing severity to enhancment and moving to "Future" milestone.
Comment 104 Jonas Sicking (:sicking) PTO Until July 5th 2000-10-02 14:24:11 PDT
how can this be an enhancement? It is a html4 conformance requirement
Comment 105 don 2000-10-02 17:40:15 PDT
This is an enhancement request because we don't have the functionality in the
product yet.  An enhancement is orthogonal to conformance.
Comment 106 Ben Bucksch (:BenB) 2000-10-02 19:52:11 PDT
If tables were not yet implemented, they were an enhancement, too?
Comment 107 Henri Sivonen (:hsivonen) 2000-10-02 21:11:30 PDT
Making an optimistic target milestone nomination.
Comment 108 don 2000-10-02 22:24:20 PDT
Yes. :-)
Comment 109 Braden 2000-10-10 08:38:41 PDT
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).
Comment 110 Jonas Sicking (:sicking) PTO Until July 5th 2000-10-22 18:50:14 PDT
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.
Comment 111 Hixie (not reading bugmail) 2000-10-24 09:58:21 PDT
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.
Comment 112 Braden 2000-10-24 10:13:45 PDT
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.
Comment 113 Viswanath Ramachandran 2000-12-06 11:32:13 PST
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Comment 114 Paul Chen 2000-12-29 14:46:12 PST
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.
Comment 115 Jonas Sicking (:sicking) PTO Until July 5th 2001-01-02 22:10:01 PST
Created attachment 21638 [details] [diff] [review]
part1 of properties window patch
Comment 116 Jonas Sicking (:sicking) PTO Until July 5th 2001-01-02 22:11:10 PST
Created attachment 21639 [details] [diff] [review]
part 2 of properties window patch
Comment 117 Jonas Sicking (:sicking) PTO Until July 5th 2001-01-02 22:17:54 PST
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...
Comment 118 timeless 2001-01-02 22:30:01 PST
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
please us 2 2, and mark it java instead of c.
Comment 119 Alec Flett 2001-01-05 18:19:22 PST
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.
Comment 120 Christopher Hoess (gone) 2001-02-07 15:42:23 PST
Is this patch still being actively reviewed?
Comment 121 Jonas Sicking (:sicking) PTO Until July 5th 2001-02-07 16:38:51 PST
There are a couple of minor things I want before rerequesting a review. Will 
hopefully be able to do this during next week
Comment 122 Matthew Paul Thomas 2001-02-10 03:44:59 PST
*** Bug 68410 has been marked as a duplicate of this bug. ***
Comment 123 Matthew Paul Thomas 2001-02-10 04:03:43 PST
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.
Comment 124 Stephen Walker 2001-02-22 16:16:24 PST
*** Bug 69877 has been marked as a duplicate of this bug. ***
Comment 125 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-13 13:00:07 PST
Created attachment 27604 [details] [diff] [review]
part 1 of properties windows, ver 2
Comment 126 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-13 13:00:44 PST
Created attachment 27605 [details] [diff] [review]
part 2 of properties windows, ver 2
Comment 127 Alec Flett 2001-03-13 15:45:24 PST
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
Comment 128 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-13 16:04:36 PST
Created attachment 27628 [details] [diff] [review]
part 1 of properties windows, ver 3
Comment 129 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-13 16:05:13 PST
Created attachment 27629 [details] [diff] [review]
part 2 of properties windows, ver 3
Comment 130 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-14 10:14:16 PST
Created attachment 27699 [details] [diff] [review]
part 1 of properties windows, ver 4
Comment 131 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-14 10:14:45 PST
Created attachment 27700 [details] [diff] [review]
part 2 of properties windows, ver 4
Comment 132 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-14 10:30:52 PST
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)
Comment 133 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-18 16:16:33 PST
Created attachment 28049 [details] [diff] [review]
part 2 of properties windows, ver 5 (works with part1 v4)
Comment 134 Peter ``jag'' Annema 2001-03-18 17:15:20 PST
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.
Comment 135 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-18 17:25:04 PST
Created attachment 28055 [details] [diff] [review]
part 2 ver 6 (spell/space fixes)
Comment 136 Karl Ove Hufthammer 2001-03-19 09:45:56 PST
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.
Comment 137 Henri Sivonen (:hsivonen) 2001-03-19 11:19:35 PST
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.
Comment 138 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-19 12:56:00 PST
Created attachment 28145 [details] [diff] [review]
Part 1 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
Comment 139 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-19 12:56:35 PST
Created attachment 28146 [details] [diff] [review]
Part 2 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
Comment 140 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-27 16:49:26 PST
Created attachment 28968 [details] [diff] [review]
Part 1 Ver 8. Updated to new XUL syntax
Comment 141 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-27 16:50:04 PST
Created attachment 28969 [details] [diff] [review]
Part 2 Ver 8. Updated to new XUL syntax
Comment 142 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-27 16:58:26 PST
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...
Comment 143 Alec Flett 2001-03-28 09:17:31 PST
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
Comment 144 Jonas Sicking (:sicking) PTO Until July 5th 2001-03-28 23:37:05 PST
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.
Comment 145 Karl Ove Hufthammer 2001-03-29 12:04:29 PST
> 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.
Comment 146 Alec Flett 2001-03-29 22:06:23 PST
ok, fix is finally in! thanks!
Comment 147 Karl Ove Hufthammer 2001-05-13 04:11:41 PDT
Reopening. This can't be fixed since there are four open bug this depends on 
(bug #1996, #18779, #37209 and #57399).
Comment 148 Jonas Sicking (:sicking) PTO Until July 5th 2001-05-13 04:25:48 PDT
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
Comment 149 Hixie (not reading bugmail) 2001-06-22 07:39:54 PDT
verified. Other bugs have been opened on the feature now.
Comment 150 Christine Hoffman 2001-08-29 18:46:17 PDT
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.
Comment 151 Jonas Sicking (:sicking) PTO Until July 5th 2001-08-29 20:22:32 PDT
rightclick on the quote/ins/del and select properties. Then you should be able 
to see the data you want.
Comment 152 Christopher Aillon (sabbatical, not receiving bugmail) 2002-08-15 00:36:13 PDT
*** Bug 97711 has been marked as a duplicate of this bug. ***
Comment 153 Brant Gurganus 2002-10-13 11:13:37 PDT
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Comment 154 Alan Thomas 2009-12-26 22:53:43 PST
Regressed by bug 513147. No longer fixed; should be reopened.
Comment 155 Martijn Wargers [:mwargers] (not working for Mozilla) 2009-12-30 06:16:54 PST
You should probably file a new bug that is blocking bug 513147.

Note You need to log in before you can comment on or make changes to this bug.