(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.
cite Q, BLOCKQUOTE, INS, DEL
datetime INS, DEL
hreflang A, LINK
href A, LINK
longdesc IMG (has its own bug report)
Currently, AFAICT only "href" is made available.
This is really an application question rather than a layout issue. Rick: I
haven't a *clue* who owns the browser in the new world so if it's not you, then
please reassign this to who is the owner so that they can have a debate about
the issues here.
My new Evil Test Suite contains an improved version of this test.
Changed platform and OS to All, component to Apprunner, and whacked priority and
Rick, this is gonna be you and Nisheeth, right?
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
I do not think this will be in for Dogfood. But need to know for sure so I can
add to Release Notes.
Changed component to XPApps and milestone target to M4.
Re-assigned to email@example.com and changed target milestone to M5.
If I understand this bug properly we need a UI design which provides a way for
the user to see the metadata? I don't think there is any chance of me doing this
moving to off to m7
I am reassigning to the UE people. If we choose to impliment this feature it will
need a spec on how the data is be presented to the user. I have not idea how
important this bug is but if a spec is written reassign the bug to me with a
pointer to the spec.
Assign it to UI designer to review whether we will need a spec/UI design.
(cc'ing ekrock wrt standards comliance, returning bug to don for cost
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
- as a tooltip for the 'title' attribute showing up on mouseover for the whole
- as statusbar message after the link destination for the attributes
lang,hreflang and datetime(in this order if specified/applicable for the
element) as shown in
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/metadata.html. The behavior
is much like the 'href' attribute shown as status message on mouseOver in 4.x
browsers today. I believe a tooltip would be too obstrusive and interventive for
the user's browsing experience (due to delay and due to covering up valuable
content context). The statusline message would simply show a list of
concatenated value attribute pairs. This approach should balance a pleasant
browsing experience with the needs of the HTML 4 spec.
- For the cite=URI I agree we should add an element to the context menu right
before the basic navigation commands and separated from those saying something
like "Open Quote Source" which would open a new window.
I do not know what to do about the Q element, I am not sure that our stylesheets
can support having them rendered
as quoted. Anybody?
Changing to enhancement bug and moving out to M14 ...
I'm not an expert on the DOM, but does alecf's new DOM Viewer
(37698C04.9D651741@netscape.com in RDF) expose this information? The picture in
that message shows META tags (would a click or mouseover show the attributes?).
I think this is a desirable enhancement, but would be happy with getting it
through the DOM viewer, although non-savvy users wouldn't necessarily be for
the subset of meta-data that concerns them, like Author.
See also bug 2800, concerning the metadata contained in the <LINK> element.
I think that saying the DOM viewer is adequate is on about the same level as
saying that the tags show up in View source;)
That's a point. =)
Ok, the strawman proposal has been discussed on the mozilla-ui newsgroup, and
I have written a summary of what was brought up. The summary is written as a
UI spec. Basically, german's proposal survived. The main new issue present in
the full UI spec concerns details such as how to convert language codes (e.g.,
lang=en) into readable text (e.g., English).
SUMMARY OF SUMMARY:
* All this should be done in XUL.
* We should show 'title' and 'summary' attributes in tooltips.
* We need have a status line with three panels, one for UA messages,
one for js messages and metadata, and one for language information.
* We need code to interpret the metadata attributes into
* We need a new menu item for elements with attributes that are links.
The UI spec / thread summary is available online:
*** Bug 1358 has been marked as a duplicate of this bug. ***
I don't see a need to have information in the `lang' attribute available to the
user. It seems most useful to search engines, etc. See
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.
<p> And he said <q lang="de">Ja!</q> immediately. </p>
"What language is the fourth word in? Hmm, I am not sure. Lets see. Oh, German.
Well there you go."
Basically, I am all for being able to show _all_ the metadata we have available.
OK, I finally got around to reading Ian's UI spec. Nice work, Ian! You really
have a passion for this.
As to the cost assessment ...
For the XPApps team to implement the chrome (i.e. the tooltips, status messages,
language panel, etc.) we're gonna need a lotta support first from the Gecko
team. All this metadata needs to be pushed up to the app in some form of
notification or some such if we're gonna show tooltips and status messages.
Also, APIs will need to be created by the Gecko team to access additional meta
data so the XPApps team can then write XUL chrome display it in the language
panel, page info dialog, or whatever. This looks like a lot of work for the
Gecko team before we ever get to it over here in XPApps. So ...
I'll first need a cost assessment by ekrock (post dogfood/beta) as to whether
the Gecko team is up to doing all this infrastructure work for us. If ekrock
says "no" or "not yet" then there's not much XPApps can do now.
Adding firstname.lastname@example.org for evaluation of UE implications.
Shuang, could you please scan the proposed UI spec for exposing meta at
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.
Created attachment 1556 [details]
Screenshot of metadata displayed when hovering over a link.
Created attachment 1557 [details]
Screenshot of metadata displayed for an <ins> inserted section </ins>, with notes.
Created attachment 1558 [details]
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."
<p> This is a new section </p>
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
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
> 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
the messages instead of replacing them, the problem is _less_ than with legacy
Reassigning to Shuang for assessment of possible UI to provide access to this
data and setting to M19 because this issue is definitely a post-dogfood/beta
issue and a lower priority than basic usability of the browser and mail. I hope
we can get this issue addressed for the first release, but if we don't we can
release note it and shoot for resolution in 5.1.
I think German will have to work on his strewman proposal more after Beta if
this will still be reqired. Reassign it to german for m19.
Shuang: His strawman proposal _has_ been worked on. There was a long discussion
on the mozilla newsgroups that resulted in the following comprehensive UI spec:
Shuang: Oops. Wrong URI. I see why you thought that the strawman proposal still
needed work. The actual URI for the spec is:
...the URI I just quoted (which is the one Eric also quoted) is the test page.
I will read through the latest spec. Since it's not dogfood, I'll put other
things higher up on the list.
*** Bug 7045 has been marked as a duplicate of this bug. ***
*** Bug 19129 has been marked as a duplicate of this bug. ***
*** Bug 22822 has been marked as a duplicate of this bug. ***
German, are we going to want this for beta1? I expect the tooltip part of this,
certainly, should be implemented by then since it is implemented in legacy
browsers. (The statusline side of things can probably wait a milestone or more
after beta1, though, IMHO.)
This is definitely not a beta1 blocker. Candidly, because this would require a
lot of new work (including UI changes) and is a fairly minor requirement of the
spec compared to a lot of other critical priorities we face in terms of
producing a usable, commercial-grade product, I'm strongly leaning towards
release noting this unless someone from the Internet steps forward to do the
work and shuang/german sign off on a UI proposal from that person.
I think the proposal for a 3-line status bar won't work because it sacrifices
too much screen real estate from the content area to chrome in order to provide
functionality few users understand or care about.
Ian--Could you clarify what you mean when you say "this" is implemented in
"legacy" browsers? Which functionality and which browsers are you referring to?
I was referring to the 'title' attribute causing a tooltip to appear in IE4 and
above. (Nav4 does this for the 'alt' attribute, which is wrong but is basically
the same idea.)
Also, the proposal does not suggest a three _line_ bar, just a three-panel bar,
split horizontally. See
...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 email@example.com on some random bugs
Sorry everyone, but the time has arrived where we have to start making some
tough decisions. This won't make nsbeta2, so it's out for FCS. Setting to M20
and marking helpwanted and relnote.
The release notes should say something like "HTML 4.0 specifies that all
metadata attributes should be visible through the UI. Currently, the following
attributes are visible only through the DOM viewer: _______" (can someone please
fill in the list?)
Outstanding issues to be resolved when we revisit this:
1) I'm concerned that a three-panel status bar would lead to having three panels
which were each too narrow to display all their contents, creating an unpleasant
UE and frustration at the fact that panels always showed "cut off" text.
2) For some of the elements that have been mentioned as examples such as INS and
DEL, the HTML 4.0 spec passed on defining any standard way to express things in
a meaningful way. e.g. "This section was inserted on the fifth of February" is
readable English, but what if IE or Opera or an authoring application were to
express the same idea as "2000/02/05-ins-section" for example? The reality is
that since the standard took a bye on defining a meaningful way to interoperate,
even if one browser implements its own way to express such ideas, interoperable
handling/parsing of semantically meaning info is unlikely to occur.
To solve problem #1: every previous version of Navigator has merged the UA bar
and the metadata bar (flicking between the two depending on the cursor
position), and I don't see why this practice can't be continued. The only
problem with this approach would be if BODY itself has metadata; and BODY
metadata would probably belong in Page Info, or in the same frame used to show
LINK elements -- not in the status bar.
When hovering over a link, the title attribute could be displayed in the status bar followed
by the href attribute. That doesn't require a multi-pane status bar and could likely be
implemented sooner than the advanced metadata display.
I have the tooltip side implemented, more or less. It's a very very small patch,
a one-line bug fix to nsXULPopupListener.cpp and a short snippet of XUL/JS which
lives in the chrome. I am displaying IMG ALT attributes if the element has no
TITLE element, because it matches Nav4 behaviour and I find it useful.
One question: if the hovered element has no TITLE attribute, I plan to go up
through its parents in the document tree until I find a parent that has a TITLE
element (or reach the top), and display that. Is that a good idea or a bad idea?
Please do *NOT* display image ALT attributes as tooltips. This encourages
people to use ALT attributes for tooltips, which is wrong. ALT attributes have
a very important purpose, which is to provide replacement text for images for
browsers that cannot or do not (by user's choice) display images, and if
graphical browsers display them as tooltips people will be discouraged from
using them for their correct purpose. MSIE gets this correct.
Going up through the tree does sound correct.
My copy of MSIE (5.01, Win98) does indeed display IMG ALT tags as tooltips. I
find this perfectly useful... dbaron, why again is this a bad thing? I don't
understand why this would discourage people from using them "correct[ly]".
I agree with David, *don't* the ALT attributes as tooltips. *PLEASE* don't.
Displaying it as a tooltop will cause people to continue using the ALT
attribute for text which really isn't appropiate as alternate text (see
<URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/alt-text.html>). If they want
tooltips, there are *no* reason not to use the TITLE attribute.
How odd that three of us tried to post the same link within five minutes of each
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
`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
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
Robert: Since you are writing a patch for this, could you please take a look at
the current UI proposal:
...and in particular look at the "FREE FORM TEXT: title AND summary" section.
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.
Created attachment 8750 [details] [diff] [review]
Navigator chrome for HTML TITLE and TABLE SUMMARY tooltips
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.
Created attachment 8757 [details] [diff] [review]
Patch to make XUL tooltips work properly across Documents
Created attachment 8758 [details]
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
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 =
I have updated the UI spec to take into account XLink's 'title' attribute.
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
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.
Created attachment 8773 [details]
Simple XLink test case with XLink title attribute
Created attachment 8775 [details] [diff] [review]
Updated browser tooltip code
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!
Created attachment 8779 [details] [diff] [review]
Version 3 browser tooltips
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...).
Created attachment 8783 [details]
XML file trying to present an HTML TABLE with XLink attribute
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
"height: auto" doesn't help at all. I can track this down and fix it sometime
The tooltip issues are now covered by bug 27828.
To answer Eric's points from 2000-04-21:
> The release notes should say something like "HTML 4.0 specifies that
> all metadata attributes should be visible through the UI. Currently,
> the following attributes are visible only through the DOM viewer:
> _______" (can someone please fill in the list?)
datetime, lang, hreflang, rel, rev, action, longdesc, and cite.
(That's assuming that title and summary are shown by Robert's
tooltips, and longdesc is fixed -- see bug 1996. longdesc should be a
very simple fix. In fact, Robert, you may be interested in looking at
it after the tooltips are checked in...)
> 1) I'm concerned that a three-panel status bar would lead to having
> three panels which were each too narrow to display all their
> contents, creating an unpleasant UE and frustration at the fact that
> panels always showed "cut off" text.
But we currently have four sections! The sidebar, the progress bar,
the UA message line, and the build ID.
I am merely suggesting that we swap the build ID for the language
status line, the UA status line for the metadata status line, and the
progress bar for a combined progress bar + UA status line section,
depending on context.
> For some of the elements that have been mentioned as examples such
> as INS and DEL, the HTML 4.0 spec passed on defining any standard
> way to express things in a meaningful way. e.g. "This section was
> inserted on the fifth of February" is readable English, but what if
> IE or Opera or an authoring application were to express the same
> idea as "2000/02/05-ins-section" for example?
What of it? That doesn't matter to us. We should display it in what we
think is the best way. Are we worried about how/where we currently
display the "href" attribute metadata? Opera displays it as a tooltip,
we display it in the UA status line. So what?
> The reality is that since the standard took a bye on defining a
> meaningful way to interoperate, even if one browser implements its
> own way to express such ideas, interoperable handling/parsing of
> semantically meaning info is unlikely to occur.
No, because the standard is very explicit about the format the data
should be *stored* in (on which the "interoperable handling/parsing of
semantically meaning info" depends), it is merely how we _display_ it
that is in question here.
Checking with don, german, ekrock, and hangas on status of all these issues.
Putting on [NEED INFO] radar.
"I will not have time to even touch this for the beta2 time frame. If
technically easy and safe we should probably get it in. Although the bug is
long and winding, I think it is harmless for the 90% user case. But getting it
in would get it some real world user exposure, so we can see whether it works
for those who use it. That we the contributors would have a chance to make it
better for beta 3..."
Setting to [nsbeta2-], adding nsbeta3 keyword.
Even if the rest of this bug is pushed out, it would be cool if someone could
check in the tooltip code. The TITLE attribute seems quite useful, and we need
to start reeducating Web designers to use it instead of IMG ALT.
Shuang, could you arrange for the checkin of the TITLE tooltips?
I want this too, but it's unclear which patch I want. All of ``Patch to make
XUL tooltips work properly across Documents''?
That C++ patch was already checked in by Mike Pinkerton, weeks ago. You want
the XUL/JS code in "version 3 browser tooltips". Actually, that patch had a
couple of conflicts with recent tree changes; I'll give you a new version.
Created attachment 9720 [details] [diff] [review]
TITLE tooltips patch, version 4
Created attachment 10191 [details] [diff] [review]
TITLE tooltips patch version 5
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
Clearing nsbeta2 nomination and moving all TITLE patch related stuff to
about the rest of the attributes (not title).
How about showing them in a "properties" dialog that are avalible in the
context-menu (ala IE). This "properties" dialog is really a very nice feature
in IE and a perfect place for showing metadata stuff.
Adding PATCH keyword for easier querying. The patch should really be checked in
by somebody with the permission!
Removing patch keyword. See bug 27828 to track the status of the tooltip patch.
No patch has been submitted to fix the other metadata issues discussed in the
given UI specification.
Since this bug suggests re-using status areas we already have to display meta
data this could be a good thing, although few of the top 500 pages actually use
meta data in that standard way.
I want somebody that works on checking in the browser engineering pieces to take
that bug away from me, it is still help wanted as far as I am concerned. The
patches and suggestions have matured to a point though where in IMO it would
useful and safe to integrate them. I am assigning this to Don's eng team for now.
*** Bug 47575 has been marked as a duplicate of this bug. ***
nav triage team:
Question: Should Mozilla also handle (i.e. show somehow) the summary-tag of
"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
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 !
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:
...then yes, I guess.
Taking QA per managerial policy.
Changing severity to enhancment and moving to "Future" milestone.
how can this be an enhancement? It is a html4 conformance requirement
This is an enhancement request because we don't have the functionality in the
product yet. An enhancement is orthogonal to conformance.
If tables were not yet implemented, they were an enhancement, too?
Making an optimistic target milestone nomination.
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
Almost nothing in HTML4 is a conformance requirement. Even things like <p> are
not required to be a "conforming implementation". Some of the few things that
_are_ requirements are: quotes around the content of <Q> elements (don't ask me
how you are supposed to do that if you are not a visual browser), and no default
character set selection (which is impossible short of refusing to display a page
that has no charset specified -- i.e., most of the web).
Conformance in HTML terms is not really a useful concept. Of course, this is
still a requirement for full support of HTML4, as are all the bugs that block
meta bug 7954.
Fair enough. I think that means this shouldn't be considered an "enhancement"
with respect to Mozilla 1.0.
That said, this bug is covering a number of issues which aren't necessarily
related (in implementation). I think it ought to be broken up.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
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.
Created attachment 21638 [details] [diff] [review]
part1 of properties window patch
Created attachment 21639 [details] [diff] [review]
part 2 of properties window patch
the attatched patches adds an "properties" entry to the context menu. When
selected it opens a window with a bunch of information about the clicked tag and
document, including all of the metadata discussed in this bug. So if you
rightclick on an image that is also a link you get info about the both the link
and the image.
I would like to add even more data (such as physical info about an image), but
that could be done later...
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
please us 2 2, and mark it java instead of c.
no, we are not enforcing tab-widths on new files. It is up to the file author to
make sure that the tab width actually matches the emacs line, but that is it.
Personally I prefer 4, but I would never force opinion on someone else.
When modifying an existing file it's important that they match of course, but
not for new files.
I will not have time to review this patch (due to it's size) before
1/15...sorry. Feel free to find another super-reviewer, or just wait until then.
Is this patch still being actively reviewed?
There are a couple of minor things I want before rerequesting a review. Will
hopefully be able to do this during next week
*** Bug 68410 has been marked as a duplicate of this bug. ***
W3C `Common user agent problems' <http://www.w3.org/TR/2001/NOTE-cuap-20010206>,
1.9: When a Web resource includes metadata that may be recognized by the
user agent, allow the user to view that metadata.
*** Bug 69877 has been marked as a duplicate of this bug. ***
Created attachment 27604 [details] [diff] [review]
part 1 of properties windows, ver 2
Created attachment 27605 [details] [diff] [review]
part 2 of properties windows, ver 2
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
assuming the changes are straight forward to change from
getElementsByTagName("IMG") and .images, etc, then sr=alecf
Created attachment 27628 [details] [diff] [review]
part 1 of properties windows, ver 3
Created attachment 27629 [details] [diff] [review]
part 2 of properties windows, ver 3
Created attachment 27699 [details] [diff] [review]
part 1 of properties windows, ver 4
Created attachment 27700 [details] [diff] [review]
part 2 of properties windows, ver 4
The above patch (ver 4) has new namespace handling as well as uses
Node.ELEMENT_TYPE rather then 1 when checking nodetype. Also changed
img = false;
img = null;
Created attachment 28049 [details] [diff] [review]
part 2 of properties windows, ver 5 (works with part1 v4)
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.
Created attachment 28055 [details] [diff] [review]
part 2 ver 6 (spell/space fixes)
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
Created attachment 28145 [details] [diff] [review]
Part 1 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
Created attachment 28146 [details] [diff] [review]
Part 2 Ver 7. Renamed properties to metadata and added some links to bugs that was worked around
Created attachment 28968 [details] [diff] [review]
Part 1 Ver 8. Updated to new XUL syntax
Created attachment 28969 [details] [diff] [review]
Part 2 Ver 8. Updated to new XUL syntax
Alecf, could you sr this again (and check in aswell?). Nothing has changed
codewise since version 4 and the only thing that's changed since your sr is new
namespace handling. This code is starting to get rather old...
sorry, my bad.. I got as far as backing the old properties.* files out of my
build so I could check this one in, and then never finished... I'll try to get
to this soon
Oh, btw. I actually did one more thing in the last version. I removed the
access-key on the context-menu-item since "p" was already used for "paste".
Paste exists in the contextmenu for form-controls.
> This bug is about metadata in HTML 4 attributes. This bug report is also
> already very long. I think it would be better to file another bug
> about displaying Dublin Core metadata
Done. If anybody's interested, see bug #73992.
ok, fix is finally in! thanks!
Reopening. This can't be fixed since there are four open bug this depends on
(bug #1996, #18779, #37209 and #57399).
Yes this is fixed. It is not an uncommon situation that a bug is fixed although
it is marked to have dependencies. The feature asked for is implemented and
that is what matters
Please don't reopen bugs unless it has regressed or was closed prematurely, and
fixing the bug does *not* count as a prematurely
verified. Other bugs have been opened on the feature now.
This bug originally was written up because several metadata attributes were not
accessible to user. Attributes included title, cite, datetime, longdesc, etc. I
see where tooltips have been implemented for the title attribute and there are
other bugs written up for 'cite' as an attribute of BLOCKQUOTE and 'longdesc' as
an attribute of IMG, but I see nothing referring to 'cite' attribute of INS and
DEL or 'datetime' attribute of INS and DEL. I don't consider this bug 'fixed'
but since it is SO long, I will write up new bugs for the above and refer to
this bug for additional info.
rightclick on the quote/ins/del and select properties. Then you should be able
to see the data you want.
*** Bug 97711 has been marked as a duplicate of this bug. ***
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Regressed by bug 513147. No longer fixed; should be reopened.
You should probably file a new bug that is blocking bug 513147.