gallery names not always displayed after search term used

colindivercolindiver colindiverRegistered Users Posts: 12 Big grins

Problem: in the SEARCH box I specify a search term for gallery (e.g. noctuidae) and all the galleries matching that term are displayed. Some galleries show the gallery name in the grey translucent box at the bottom of the gallery image, and most do not. When I move the cursor over a gallery, some galleries show the gallery name and some do not. I have checked the Appearance criteria set for each of the galleries and they are the same. why are the gallery names not displayed for all galleries? I'm not sure if this a bug or not. username: colindiver. thanks

Comments

  • JtringJtring Major grins CaliforniaRegistered Users Posts: 582 Major grins

    I ran across something similar a few weeks ago. My situation was as you described, but only on Chrome. There was no problem on Firefox. In looking closely, I observed the boxes where the gallery name showed were ones where the name would fit on one line. If it wouldn't completely fit, the line was coming out blank. Searches for folders or pages acted same way. Does that match what you are seeing?

    If so, this appears to be an issue with different browsers implementing (or interpreting) CSS specifications differently. This may be more than you want to know, but as far as I can tell, the overflow property manages this situation and, officially, the overflow property only applies to items with a "block" value for the display property. Smugmug is using a "inline-block" display value here. Firefox, however, appears to be applying the overflow property values anyway. I haven't checked other browsers, but I'd expect Safari and the Chromium-based Edge to behave like Chrome.

    The fix I applied was a bit of custom CSS inserted in a CSS block on the search page to patch SmugMug's CSS. (I think it would work just to put this code in your theme or entire site CSS, but I haven't tried that.) This moves the display property value back to "block" and makes sure the appropriate overflow values are in place.

    .sm-search-tile-info p {  
        display:block;
        overflow:hidden;
        text-overflow:ellipsis;
    }
    

    If, in your case, this is not just a Chrome (or Chromium) problem applying to situations where the name exceeds the space available, then it's something else. I'm not sure what. Maybe post a link to your site?

    Jim Ringland . . . . . jtringl.smugmug.com
  • colindivercolindiver colindiver Registered Users Posts: 12 Big grins

    I use a PC with Windows 10 (updated). I have checked this problem on 4 browsers: Chrome (which is my regular browser), Edge, Brave and Firefox. The first 3 all give the same problem but on Firefox it shows all gallery names perfectly.

  • colindivercolindiver colindiver Registered Users Posts: 12 Big grins

    thanks Jtring, I figured out how to apply your fix to the whole site and it worked! :) much appreciated!!!

  • JtringJtring Major grins CaliforniaRegistered Users Posts: 582 Major grins

    Glad it worked.

    Turns out my explanation of what is going on is too simple-minded. There's an interaction between inline-block displays and the overflow property that causing the problem, but it's more than just "works" and "doesn't work". I'm still working to understand the details, but clearly problem is fixed by the patch I posted.

    Jim Ringland . . . . . jtringl.smugmug.com
  • JtringJtring Major grins CaliforniaRegistered Users Posts: 582 Major grins
    edited June 29, 2020

    Just one more follow-up should anybody find this thread on a future search. A simpler piece of patch CSS, and one that maintains the height of those little title boxes (my CSS above does not), would be

    .sm-search-tile-info p {  
        display:inline;
    }
    

    After a few quite interesting hours of learning about inline-block displays and testing various alterations to the search page CSS, I still have only guesses, nothing solid, on why Chrome and Firefox render SmugMug's code differently.

    Added note: after posting this, I wrote the help desk, suggesting one of the SmugMug engineers look into this.

    Jim Ringland . . . . . jtringl.smugmug.com
  • rainforest1155rainforest1155 SmugMug Support Hero Registered Users Posts: 4,524 Major grins

    This has been reported to our QA team for investigation. Thanks for reporting this and Jim as well providing a workaround.

    Sebastian
    SmugMug Support Hero
  • colindivercolindiver colindiver Registered Users Posts: 12 Big grins

    i replaced the original fix with this and it works fine, thanks

Sign In or Register to comment.