When a user’s own letter avatar doesn’t load, discourse doesn’t show any placeholder for it. That means the user’s “profile/messages/preferences” menu at the top-right completely disappears, preventing them access to many features. Typing a P will bring it up, but first-time users won’t even know anything is missing, and looking-up those keyboard shortcuts is too much to expect of users in general. This problem also shows up elsewhere, like making it impossible to show which users have “Liked” a post, as the elements collapse, preventing mouse-over.
I suspect that this could be most quickly and easily fixed by merely filling-out the alt= field for the avatar images, instead of leaving them all null. Including a small screenshot made in the sandbox, for those who haven’t seen this effect first-hand:
I’d like to sidestep all the reasons why avatars don’t always load (as a dozen other topics have), and focus on ensuring the UI is more robust to that eventuality. Whether it’s network issues, CloudFlare issues, local caching issues, or even the user choosing to disable image loading in the browser. I don’t believe image load failures should break the functionality of a website.
This is no argument for not improving the status quo, especially if the work required to do that is rather minimal. You can always reduce the what-ifs and provide sensible fallbacks (where they are possible). Browser will show the fallback fonts if the Web Fonts fail or are slow to load (some browsers are better at this than others, e.g. Safari is the worst). Images will show placeholders (the alt text or broken image icon) and these placeholders will even have the right dimensions of you specify width & height. I’m all for making Discourse available (in a limited way) even if the JS fails to load, but that’s quite some way down the road (if it will ever happen). But back to the issue at hand.
Especially the Avatar service is an issue since you’ll need to load a ressource from a remote centralized server. I’ve encoutered OPs issue before as well (did not realize at first that the avatar was missing) most likely because the avatar server was under heavy load or the route to it was congested – which happens even if the service is heavily CDN’ed.
So here’s what I’d like to see:
Specify alt as much as possible (and sensibly). This is also good for accessibility. Note that an empty description (i.e. alt="") is valid and recommended for elements that do not carry a particular meaning (e.g. graphical elements or image replacement techniques).
Specify image dimensions as much as possible (and sensibly). Some may be set within the HTML, others can be specified in the CSS, e.g. if it concerns groups of images or the containers of images (rather than the images themselves).
Long-term: Add the avatar service to the Docker container, i.e. make it self-hostable within the Discourse instance. Provide an option to use the self-hosted version or the centralized, remote one. This reduces reliance on another external host and also improves loading times through re-using the already-open connection.
Very dubious value (and only works for 404s), we already specify dimensions everywhere we use avatars, if we specified a bg color or some other crazy alt text hack we would mess up the ability to have avatars with transparent backgrounds.
I’m sorry, I don’t mean to be patronizing (2nd language speaker here, please bear with me). I just wanted to explain my stance on this.
Even if the case is rare, it should not fail in a way that renders part of the UI unusable. And since it is the rare case, an “ugly” solution is better than none (see @sam’s screenshot, it’s actually good in the way it clearly shows there is something missing; in Firefox, nothing is shown) – it’s definitely better than the avatar and thus profile menu disappearing altogether. This should also work for timed-out connections.
For this particular case, it might be better to have the parent a tag have the e.g. min-width/min-height specified to make sure the space for the image is reserved at all times. When hovering, the box still gets highlighted, so it’s kinda usable this way.
I did a quick & stupid test myself, just filling out a couple alt= tags with “ALT” (any idiot could come up with a better string)… And here’s how it looks, compare with previous shot above:
The value seems pretty clear… The site remains functional, and anyone who is physically disabled and using a screen-reader will appreciate the alt= tags being filled-out.
There’s at least a dozen ways avatars can fail to load. My own screenshots were with image loading disabled in Firefox settings, NOT a “404”. But I’ve been seeing this problem, daily, because of CloudFlare’s captchas, coming up because of shared public IPs.
Discourse works fine when the font doesn’t download… You just see random symbols, instead of proper icons, but the elements are still there, and you can mouse-over for a description, and click on them as needed.
Discourse already fails more gracefully than most sites, if the JS doesn’t load… At least you can continue to read everything, which isn’t universally true.
The avatars have an order of magnitude more failure modes… And it seems a trivially easy fix for Discourse to continue working when the avatars don’t load.
My apologies for what a mess this bug report discussion has turned into. Certainly not intended.
I deployed a fix for the ALT tag, but we also should stop using a blank image on failure (we send a blank dot, which in retrospect was not a great idea) and instead send a default avatar image.
