Closed Bug 1995 (metadata) Opened 26 years ago Closed 23 years ago

[RFE] metadata attributes not accessible to use

Categories

(SeaMonkey :: UI Design, enhancement, P4)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: ian, Assigned: sicking)

References

(Depends on 2 open bugs,
URL
)

Details

(Keywords: helpwanted, relnote, Whiteboard: relnote-user)

Attachments

(26 files)

Screenshot of metadata displayed when hovering over a link.
16.15 KB, image/png
Details
Screenshot of metadata displayed for an <ins> inserted section </ins>, with notes.
29.04 KB, image/png
Details
Screenshot of status line displaying a JavaScript-generated message shown when hovering over a link.
2.34 KB, image/png
Details
Navigator chrome for HTML TITLE and TABLE SUMMARY tooltips
3.28 KB, patch
Details | Diff | Splinter Review
Patch to make XUL tooltips work properly across Documents
1.08 KB, patch
Details | Diff | Splinter Review
Test case
894 bytes, text/html
Details
Simple XLink test case with XLink title attribute
281 bytes, text/xml
Details
Updated browser tooltip code
3.71 KB, patch
Details | Diff | Splinter Review
Version 3 browser tooltips
3.46 KB, patch
Details | Diff | Splinter Review
XML file trying to present an HTML TABLE with XLink attribute
594 bytes, text/xml
Details
TITLE tooltips patch, version 4
3.41 KB, patch
Details | Diff | Splinter Review
TITLE tooltips patch version 5
3.45 KB, patch
Details | Diff | Splinter Review
part1 of properties window patch
14.04 KB, patch
Details | Diff | Splinter Review
part 2 of properties window patch
21.25 KB, patch
Details | Diff | Splinter Review
part 1 of properties windows, ver 2
7.51 KB, patch
Details | Diff | Splinter Review
part 2 of properties windows, ver 2
21.60 KB, patch
Details | Diff | Splinter Review
part 1 of properties windows, ver 3
7.05 KB, patch
Details | Diff | Splinter Review
part 2 of properties windows, ver 3
22.11 KB, patch
Details | Diff | Splinter Review
part 1 of properties windows, ver 4
7.05 KB, patch
Details | Diff | Splinter Review
part 2 of properties windows, ver 4
22.49 KB, patch
Details | Diff | Splinter Review
part 2 of properties windows, ver 5 (works with part1 v4)
22.23 KB, patch
Details | Diff | Splinter Review
part 2 ver 6 (spell/space fixes)
22.22 KB, patch
Details | Diff | Splinter Review
Part 1 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
7.21 KB, patch
Details | Diff | Splinter Review
Part 2 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
22.47 KB, patch
Details | Diff | Splinter Review
Part 1 Ver 8. Updated to new XUL syntax
7.07 KB, patch
Details | Diff | Splinter Review
Part 2 Ver 8. Updated to new XUL syntax
22.47 KB, patch
Details | Diff | Splinter Review 
(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.
Assignee: kipp → rpotts
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.
Severity: minor → normal
Component: Layout → Apprunner
OS: Windows 95 → All
Priority: P4 → P3
Hardware: PC → All
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
Target Milestone: M3
I do not think this will be in for Dogfood.  But need to know for sure so I can
add to Release Notes.
Component: Apprunner → XPApps
Changed component to XPApps and milestone target to M4.
Target Milestone: M3 → M4
Assignee: rpotts → davidm
Target Milestone: M4 → M5
Re-assigned to davidm@netscape.com and changed target milestone to M5.
QA Contact: 3853 → 3849
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.
Target Milestone: M5 → M7
moving to off to m7
Status: NEW → ASSIGNED
Assignee: davidm → shuang
Status: ASSIGNED → NEW
Component: XPApps → UE/UI
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.
Assignee: shuang → german
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 ...
Severity: normal → enhancement
Target Milestone: M7 → M14
Summary: metadata attributes not accessible to use → [RFE] metadata attributes not accessible to use
Component: UE/UI → XPApps
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.
Whiteboard: A long thread concerning this bug is playing out on the mozilla-ui newsgroup. I will post a summary when a conclusion is reached. - py8ieh
See also bug 2800, concerning the metadata contained in the <LINK> element.
Blocks: html4.01
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.  =)
Whiteboard: A long thread concerning this bug is playing out on the mozilla-ui newsgroup. I will post a summary when a conclusion is reached. - py8ieh → UI spec available, see notes
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. ***
Whiteboard: UI spec available, see notes → awaiting cost assessment from don for proposed UI spec (see notes)
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.
Assignee: don → ekrock
Whiteboard: awaiting cost assessment from don for proposed UI spec (see notes) → Waiting on cost assessment by ekrock (post dogfood/beta)
Target Milestone: M14
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.)
Assignee: ekrock → shuang
Whiteboard: Waiting on cost assessment by ekrock (post dogfood/beta)
Target Milestone: M19
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.
Assignee: shuang → german
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.
Status: NEW → ASSIGNED
Priority: P3 → P4
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.
QA Contact: beppe → paulmac
Severity: enhancement → normal
*** Bug 7045 has been marked as a duplicate of this bug. ***
*** Bug 19129 has been marked as a duplicate of this bug. ***
Blocks: 19425
Depends on: 18779
*** 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.)
Whiteboard: waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt)
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
QA Contact: paulmac → jrgm
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.
Keywords: helpwanted, relnote
Target Milestone: M19 → M20
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.
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
Keywords: nsbeta2
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.
Depends on: 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.
Whiteboard: waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt) → [NEED INFO]waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt)
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.
Keywords: nsbeta3
Whiteboard: [NEED INFO]waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt) → [nsbeta2-]waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt)
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?
Keywords: patch
Whiteboard: [nsbeta2-]waiting for german to read through UI spec proposal (http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt) → [nsbeta2-] partial fix (TITLE tooltips) ready
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.
Depends on: 37209
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.
Keywords: nsbeta2, patch
Whiteboard: [nsbeta2-] partial fix (TITLE tooltips) ready
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!
Keywords: patch
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.
Keywords: patch
Depends on: 45380
No longer blocks: 19425
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.
Assignee: german → don
Status: ASSIGNED → NEW
*** Bug 47575 has been marked as a duplicate of this bug. ***
nav triage team:
nsbeta3-
Whiteboard: [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.
QA Contact: jrgm → py8ieh=bugzilla
Changing severity to enhancment and moving to "Future" milestone.
Severity: normal → enhancement
Target Milestone: M20 → Future
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.
Keywords: mozilla1.0
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.
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
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.
Severity: enhancement → normal
Depends on: 57399
Depends on: 1994
Depends on: longdesc
No longer depends on: 1994
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → 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.
Assignee: vishy → pchen
Keywords: nsbeta1-
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.
Assignee: pchen → sicking
Keywords: nsbeta3 → patch, review
Whiteboard: [nsbeta3-] relnote-user → relnote-user
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
Keywords: review
*** 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.
No longer blocks: 68427
Blocks: 68410
*** 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)
Status: NEW → ASSIGNED
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!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reopening. This can't be fixed since there are four open bug this depends on 
(bug #1996, #18779, #37209 and #57399).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
verified. Other bugs have been opened on the feature now.
Status: RESOLVED → VERIFIED
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.
Depends on: iptc
Depends on: 106420
*** Bug 97711 has been marked as a duplicate of this bug. ***
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
Product: Core → Mozilla Application Suite
Alias: metadata
Regressed by bug 513147. No longer fixed; should be reopened.
You should probably file a new bug that is blocking bug 513147.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: