Liked / Thanks hover not displaying properly?

[#1]

I’ve just noticed that when you hover over the thumbs up counter all you see it the Alt text saying what it is, when it used to show you a list of who’d thanked a post. Just thought I'd mention it.

[#2]

That's a recent change, @Anonymous , not that I worry about it that often.

Edit - on my system, providing there is a number in the counter, hovering does show the 'likeess'

[#3]

It's still there and working.

The alt text does get wiped out if you recently clicked it and not refreshed the page. This is because the ajax call replaces the alt text when clicking. The collection of usernames is done on page load, put into a hidden container next to the like button, javascript then clones that hidden container and applies it to the alt text, replacing what was there and then deletes the hidden container.

I could extend the js so that it keeps the username collection and does something else when clicked as I was under time constraints when I created it and by the time I finished it I had run out of time to make any improvements.

[#4]

@jaread83 See my edit, should have tested before replying.

[#5]

It does work but there are some extra fluff needed in the code for when you click the thanks. Give it a try - hover over a post with a thanks counter of 1 or more, you will see who thanked the post, then click the thanks button and hover over the number, it resets because the alt text is replaced when you clicked it. That is the normal behaviour and I have hacked the component to bits with JS to get it to display a list of users as that isn't something the software does by default.

[#6]

Thanks for that @jaread83 I did the hover after I'd clicked the like button, so the above explains what I saw but as a result of that I did refresh the page and it still showed the Alt text, which is why I posted here!

[#7]

That's odd. Can you link me to the post that this happens on please?

[#8]

@jaread83, it's message 9 of this thread.

[#9]

Looks like it is working for me....

Do you have any javascript errors on that page?

[#10]

As it does for me now, but when I posted it wasn't, as for errors I don't know. Don't waste your time on this @jaread83, you'll have better things to do. If it happens again I'll try and get some screen grabs for you.

[#11]

No worries I will keep a mental note of this and check every now and then.

[#12]

Jack,

Talk of more client side JS skin grafting is concerning.  I find page load / rendering is already too sluggish - I too often find that having started to do something on an essentially loaded page, things change in front of my eyes... particularly on write a post page.

The magic of this stuff is excellent, but needing to 'shape' this heap of crud client side has a pay-load delivery (bandwidth) and rendering (performance) cost which users ought not to be 'paying for'.  Somehow Lithium need to be made to get their fingers out and fix these issues properly server side.

[#13]

@Townman, there really is no issue to fix server side, well not in this instance, as this as you know is a custom component asked for by us users. I agree there is a huge amount of bloat in this system, but not wanting to defend Lithium, they have to cater for the majority, not the minority as this leads to a maintenance nightmare.

Maybe if @jaread83, could suggest the functionality as a core component with the backing of other Lithium board users then they may take it on board, but ironically it wouldn't reduce the code base size, so no benefit would be gained.

[#14]

---

@jaread83 wrote:
Do you have any javascript errors on that page?

---

As a side note to this, I had the developer tools open on my browser and on loading this page it counted over 500 errors, granted not the page in question but 500+ errors!

To see what I mean if you are using FF on OSX open a new tab then call up the Developer Toolbar using Cmd + F2 then load your page of choice and you'll see the error count in the bottom right of the screen.

[#15]

@Anonymous,

I had not intended to suggest that THIS issue needed a server side fix.  Rather that this functionality ought to be facilitated by server side customisation, not client side customisation.  May be on this occasion we might need to agree to disagree. 

A smart system (and I'm far from convinced that without Jack's sterling work in the skin, that this could be considered to be one) would facilitate customisation BOTH server side and client side.  Reading between the lines, client side JS is picking up place holders, making queries back to the server and generating / inserting HTML on the fly.  This adds payload to the delivered web page (code) and delayed rendering (execution of code) time.

If such customisation were facilitated server side, the delivered pay load would be smaller and it would be ready for rendering without further processing.  From comments Jack has made, server side customisation is not facilitated by Lithium ... which I suggest is a serious omission.  I think I would be correct in stating that the majority of SMF's customisation is performed server side.