Ok, it seems that “display tooltip with cursor” might not be clear enough.

What I meant is to use cursor mode (put finger on the left side of the screen,
and drag it to the center, a cursor will appear, which you can put on the
image), put the cursor on the image and wait a bit. The tooltip will appear
(truncated).

*** This bug has been confirmed by popular vote. ***

turning off images lets you view the entire contents of the alt tag.

tooltips are not a requirement of browsers and we are not required to show a
tooltip containing a million characters. alt tags are not supposed to contain
essays.

Excepted that image tooltips are not necessarily the alt image. Only IE 6
displays the alt tag as a tooltip, which is an erroneous behaviour. The correct
behaviour for a tooltip on an image should be within the title attribute of the
img tag. This is valid HTML / xHTML, and hence should be displayed correctly as
such.

Regardless of your own beliefs, timeless, the HTML / xHTML standard does
include the fact that tooltips should be rendered properly -- or at least,
provide a means to be able to display the title in an alternative method
(whether this means a long press on an image, and then an option "Show title").

Source: http://www.w3schools.com/tags/att_standard_title.asp
Source: http://www.w3schools.com/tags/att_img_alt.asp

I suspect you are referring to xkcd, however, xkcd behaves as the standards
expect. The alt attribute is a concise alternate for the image, however the
title provides additional information.

For reference, w3schools is *not* canonical, it's merely a guide and is often
inaccurate.

> The information is most often shown as a tooltip text when the mouse moves over the element.

Note the use of 'most often'. Even w3schools isn't saying it's a requirement.

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-title-attribute

The html5 spec is more or less canonical.

> The title attribute represents advisory information for the element, such as would be appropriate for a tooltip.

It does not mandate how it is presented. Or that it be presented at all.

I actually have a bookmark somewhere which you can use in microb to get image
info, I don't remember if it includes titles, if it doesn't, extending it
wouldn't be hard.

xkcd's use of title while interesting is mostly wrong. FWIW, links (the web
browser) is unable to show me the content. This is not links's fault, it's the
fault of the xkcd authors misusing html.

Note that as of pr1.2, you can use view-source:<url> to read the title of most
content (unless the content is dynamic, in which case you'd need to figure out
the wyciwyg url, which is probably not exposed anywhere).-- Or you could also
write a tiny bookmarklet which did something like:

javascript:x='';for(y=document.firstChild;y;y=y.nextSibling)if((z=y.innerHTML))x+=z;void(window.open("data:text/plain,"+x))

fwiw, afaict Fennec (on OS X) does not present the title attribute for the
current xkcd article (Safari on OS X does). If you feel that it is critical for
some future browser, I'd suggest you find or file a bug in bugzilla.mozilla.org
in the Fennec product.

(In reply to comment #5)
> For reference, w3schools is *not* canonical, it's merely a guide and is often
> inaccurate.

Sure, let's look at http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
then (does MicroB support HTML5? Considering it's only a draft, I'd expect not
really).

Quoted from that page:

"This attribute offers advisory information about the element for which it is
set.
Unlike the TITLE element, which provides information about an entire document
and may only appear once, the title attribute may annotate any number of
elements. Please consult an element's definition to verify that it supports
this attribute.

Values of the title attribute may be rendered by user agents in a variety of
ways. For instance, visual browsers frequently display the title as a "tool
tip" (a short message that appears when the pointing device pauses over an
object). Audio user agents may speak the title information in a similar
context. "

> Note the use of 'most often'. Even w3schools isn't saying it's a requirement.

And never did we say it was, however what's the point of showing something
which most probably be truncated? Isn't the point of usability, especially in a
browser that is oriented towards a mobile platform with limited screen real
estate to display things in the most usable manner?

What exactly is the rationale behind simply classifying this as WONTFIX,
without any further discussion? I really hate to be the guy saying this, but it
sounds more like a dictatorial, unilateral decision.

> I actually have a bookmark somewhere which you can use in microb to get image
> info, I don't remember if it includes titles, if it doesn't, extending it
> wouldn't be hard.

I would love for a workaround to be found for this, would you mind sharing? A
workaround is a possibility, rather than simply saying "WONTFIX" and then
ending the discussion.

> xkcd's use of title while interesting is mostly wrong. FWIW, links (the web
> browser) is unable to show me the content. This is not links's fault, it's the
> fault of the xkcd authors misusing html.

Where are the guidelines that say that using more than 50 characters in the
title is mostly wrong? The whole point is that the title property of the img
tag isn't content, so whether links displays it or not is completely
irrelevant. There is absolutely no misuse of HTML. Run xkcd through a
validation tool, and you'll note that there are no errors being given on the
use of title.

> Note that as of pr1.2, you can use view-source:<url> to read the title of most
> content

I'm sure that UX experts would love this. Thanks for the recommendation though
-- I was sometimes even tempted to wget | cat.

> fwiw, afaict Fennec (on OS X) does not present the title attribute for the
> current xkcd article (Safari on OS X does). If you feel that it is critical for
> some future browser, I'd suggest you find or file a bug in bugzilla.mozilla.org
> in the Fennec product.

So who controls the behaviour of MicroB on Maemo? Mozilla? Is there no
integration team?

-Thanks,

microb is mostly a dead product. control is by a maintenance group. *at nokia*.
it is of course open source, so you are of course free to fork it. However,
doing so is a huge waste of resources.

generally one does not take a product which had a ui design and make radical
changes to it during maintenance.

and i gave a workaround in the bug.

Please don't bother me about this bug again.

ok,
the ONLY time I have ever heard of this bug is wrt: xkcd
to add useful information here and to workaround this bug:

use http://m.xkcd.com and the problem practically never exists.

/thread