I can't say for all browsers, but I'm sure the major ones have fixed their "title" implementation. Maybe lynx still has a problem displaying them, I just don't know....
Also, I'm not sure if this is something that's finally resolved in all browsers, but title attributes have traditionally had issues with line breaks.
Did that and...(and I've yet need to read the other comments after your post also).
I like the above-the-title approach, but unfortunately that is virtually impossible to achieve due to the fact that the tooltip is positioned with top/left coordinates, which would have to change as the content is loaded and animated into place.
Here are a few alternatives I've been playing with:
Tooltip shifted right by 50px:
View attachment 1301
Shifted right and 10% transparency added to body:
View attachment 1302
Positioned over metadata area:
View attachment 1303
I'm not too keen on the idea of having the tooltip directly attached to the right of the title, I think that opens up all sort of possibilities for the tooltip to disappear off the edge of the screen etc., but I might be able to be convinced.
what happens if the thread title is as long as the field it's filling , wouldn't making the placement of the overlay relative to the end of the title have erroneous behaviors for people running at low resolutions and placing it over the metadata makes people like me running at 1920 x 1080 look completely on the other side of the page which makes me look away from my mouse pointers location so the time I saved by not covering thread, is wasted looking to the overlay , finding my pointer and looking at the next title to do the same.. if your reading a preview of one thread i don't get why you need to see the one below it until you are done reading the preview
( unless you can read from two points at once and then you have my complete attention forever )
Yes, my bad. I have an extension installed that is responsible for handling line breaks in the tooltips.From a quick test using Firebug, Firefox still seems to be broken here (it ignores them). Maybe it was just a Firebug oddity.
Would this be a good idea? Could it solve the desire for fast vs slow preview?
?
- Long initial wait time for the casual users
- Once that wait time is met the preview pops up
- Then it is in a 'quick preview' mode where there is no wait time when going between threads to see the other previews.
- Then it would require a full 1-2 seconds without showing a preview to go back to #1
Sorry, but this doesn't seem that hard to me at all.I should qualify my previous statement - although there are major technical challenges involved with placing the tooltip above the title, that is by far my preferred way of doing it. Mike and I have just been discussing a relatively major change to the approach in the code that might make this possible. I'll let you know.
$("div.title-link").click(function() {
// code to fetch data and append div to body
position = $(this).offset();
$("div.preview#uniqueid").offset(function() {
return {
top: position.top - $(this).outerHeight(),
left: position.left
};
});
}
I should qualify my previous statement - although there are major technical challenges involved with placing the tooltip above the title, that is by far my preferred way of doing it. Mike and I have just been discussing a relatively major change to the approach in the code that might make this possible. I'll let you know.
That's something that would rarely happen and is not nearly as big of a problem as covering the other thread titles.if you put the tooltip above the Title, then when hovering over the very first title in the list, it would cover the Forum-Title and the page-navigation......
if you put the tooltip above the Title, then when hovering over the very first title in the list, it would cover the Forum-Title and the page-navigation......
jaja, I already changed my point of view.....
+1On the contrary, this implementation penalizes the users with the slow connection as displaying each popup requires a separate request back to the server. My connection is unfortunately isn't that fast so I have to wait about a second for the content to appear in a popup.
From that reply, the main point seems to be:
But it works for vBulletin, doesn't it? Since it seems to be the gist of your reasoning, I went and checked the real performance impact of enabling the thread previews in vBulletin. Here are the durations of the relevant query (lowest values after a dozen of runs), for the page size of 25 threads:
0.00251 seconds with thread preview
0.00203 seconds without thread preview
I like that they are now animating to the top instead of the bottom. It not only looks better, but keeps the threads below visible too. Better UI over the whole line.
We use essential cookies to make this site work, and optional cookies to enhance your experience.