Problem displaying text in Safari

W.W. Webster · December 25, 2014

I don't know if this is a SmugMug problem or a Safari problem, but it can't be my doing and has been bugging me for a long time.

Some text displayed on my Turbo-based site in Safari is not correctly formed (i.e. partly broken up), whereas any other browser (Chrome, Opera and Firefox examples are shown below) do not show this problem. The problem exists for both standard SmugMug windows (for example, text in galleries) and for text boxes created by me.

See the breadcrumb in the same screen segment displayed in different browsers on the same (Apple 30" Cinema Display) monitor below. What gives?

Safari example (borked) -

Opera example (ok) -

Firefox example (ok) -

Chrome example (ok) -

leftquark · December 26, 2014

It looks like it's a Safari thing. It's making the text slightly transparent when it shouldn't be. If I put a black background behind it, the issue goes away, but obviously you don't want a black bar behind your breadcrumb. If you move the window size you'll see the transparent part changes as the background moves. I've also tried setting the text to be completely non-transparent with no change to the behavior. Looks like something weird with Safari (and I hate putting the blame on something else without being able to offer a solution).

tomnovy · December 26, 2014

Yea, unfortunately this is how Safari is rendering some thin fonts.

To solve this issue - you could try this CSS code:

.sm-user-ui h1 {
font-weight:300;
-webkit-font-smoothing: antialiased;
}

This will make your font little bit thicker and antialiased, which should improve the look of it when viewed on Safari.

W.W. Webster · December 26, 2014

Thanks guys. That's certainly fixed the Safari problem, although it has also made the font thicker in all browsers, which is unfortunate.

I presume it's not possible to make the fix Safari-specific. And I also presume all Safari-browser visitors to every other SmugMug user site suffers this problem, but that the SmugMug user either doesn't realise it or just accepts it?

leftquark · December 27, 2014

W.W. Webster wrote: »

I presume it's not possible to make the fix Safari-specific. ?

Does this work:

.sm-browser-safari .sm-user-ui h1 {
font-weight:300;
-webkit-font-smoothing: antialiased;
}

Allen · December 27, 2014

I looked in the Safari page source and couldn't find the sm-browser-safari class name in the body tag.

leftquark · December 28, 2014

Allen wrote: »

I looked in the Safari page source and couldn't find the sm-browser-safari class name in the body tag.

It's in the HTML tag at the very top ... hiding!

W.W. Webster · December 31, 2014

leftquark wrote: »

Does this work:

.sm-browser-safari .sm-user-ui h1 {
font-weight:300;
-webkit-font-smoothing: antialiased;
}

Thanks, but this code appears to leave the text unaltered for all browsers!

W.W. Webster · January 1, 2015

Anyone know why the suggested code is not responding to a visitor using Safari?

moiraine · January 5, 2015

Instead of:

.sm-browser-safari .sm-user-ui h1

You need:

.sm-browser-safari.sm-user-ui h1

Note the missing space.

W.W. Webster · January 5, 2015

Thanks Moraine - that's it!

Makes me wonder whether SmugMug should implement this change (and for other font sizes) to maintain compatibility with Safari (which is a supported and widely-used browser), as they have done to deal with the innumerable idiosyncrasies of IE (now in steep decline, if not on a path to extinction) over the years!

BTW what would I replace the "h1" with to apply a minimum font thickness to ordinary text?

moiraine · January 5, 2015

what do you mean by ordinary text? Just in the breadcrumbs? or across the whole page? A "minimum font thickness" might be achievable by overwriting the base smugmug font styles with your own font-weight or some such.

.sm-browser-safari.sm-user-ui body {
font-weight: 400;
}

might be the simplest rule that would catch the most default cases, but I'm not sure how many that might actually *be*. If it doesn't work, you'd have to return with examples of places of text where you'd like the rules to be applied

W.W. Webster · January 5, 2015

moiraine wrote: »
what do you mean by ordinary text? Just in the breadcrumbs? or across the whole page? A "minimum font thickness" might be achievable by overwriting the base smugmug font styles with your own font-weight or some such.
.sm-browser-safari.sm-user-ui body {
font-weight: 400;
}
might be the simplest rule that would catch the most default cases, but I'm not sure how many that might actually *be*. If it doesn't work, you'd have to return with examples of places of text where you'd like the rules to be applied

By "ordinary text" I mean what might be called "body text" (i.e. not involving h1, h2, etc), such as in gallery descriptions. Thanks for the suggestion - I'll give it a try.

W.W. Webster · January 6, 2015

I happened to go to another user's site here today (linked by another Dgrin post somewhere) and I think he would be horrified if he could see how poorly it is displayed in Safari!

Doesn't SmugMug have an obligation to deal with this, rather than individual users needing to hack their sites?

leftquark · January 6, 2015

W.W. Webster wrote: »

Doesn't SmugMug have an obligation to deal with this, rather than individual users needing to hack their sites?

The problem with this is that it's a font by font issue. Some fonts have it, others don't. Each font and each browser on each OS decides to render fonts slightly differently and the fix for them is dependent upon the font, the browser and the OS. Some fonts, like these 2, are fixed by forcing anti-aliasing (which only works for OS X Safari but not for other OS's or other browsers on OS X) while other fonts are fixed by performing a text shadow hack or changing the stroke width. Since it depends upon each font it's really hard to do a global fix that solves the issue entirely. I'll see if we can come up with something more globally though.

W.W. Webster · January 6, 2015

leftquark wrote: »

I'll see if we can come up with something more globally though.

Thanks Aaron!

Problem displaying text in Safari

Comments