Multiple CSS selectors on one font fail with new Fonts.com JavaScript [#1648262]

I had a major problem last week -- all of my web fonts disappeared off my site (and no fallbacks displayed -- the page was just blank where web fonts should be) and the site slowed to a crawl, hanging up and screwing up caching and content to the point of timeout errors.

I spent half a day with my host (Pantheon) and then on the phone with with Fonts.com, and finally determined the problem. Here's my synopsis.

In short, @Font-Your-Face module UI only lets you enter all CSS selectors for one font together, separated by commas. However, on Fonts.com, it requires each selector have it's own entry, with a font selected for each (even if that font is also duplicated for other selectors).

So, when Fonts.com receives the info via @Font-Your-Face from our site, it doesn't process the commas properly and thus treats it as a line of multiple selectors all mushed together. It then proceeds to send those selectors back to our site via Javascript and modify them temporarily to hide them to avoid visual flashing while they load. When it tries to re-modify them back to normal intended display, it trips up on the bad string of selectors and thus can't unhide the fonts.

Apparently the old version of Fonts.com's Javascript was more fault tolerant of this problem with @Font-Your-Face's data entry.

However, their latest JavaScript version (from about June 5th) is not. When (on June 12) I made one minor font change, Fonts.com "republished" the font project to our site, which also updated the Javascript code they embed on our site to the latest version. That's why that day, the Fonts.com fonts disappeared, and the site started hanging for a long time in its attempt to finishing loading the fonts.

I had to spend half a day on Fonts.com manually re-entering all the selectors individually and re-linking them each to a font again, and then deleting the "mega-selector" versions sent over by @Font-Your-Face. Upon completion of this, web fonts started loading again perfectly, and a lot faster.

I'm not touching the module UI for now, and making changes at fonts.com. However, I'm guessing this is something that is going to start cropping up on other sites as they make new font changes.

Note that this is a brand new issue Fonts.com noticed -- they figured it out in the course of the couple of hours of phone conversations with me re our site. So, this may very well be brand new breaking information regarding this matter.

I don't think there's any way Fonts.com is going to change to the @Font-Your-Face data entry method, so I'm hoping the module authors can look into adjusting the module to this.

Comments

Comment #1

sreynen commented 20 June 2012 at 13:13

Title:	Major data connectivity/compatibility issue with Fonts.com via @Font-Your-Face module -- total failure built in to module!!	» Multiple CSS selectors on one font fail with new Fonts.com JavaScript
Category:	bug	» support
Priority:	Critical	» Major

Thanks for reporting this and your time tracking down the issue.

This sounds like a new bug on the Fonts.com side. They've always used a different way of managing CSS selectors, but it never caused a problem before. If it now causes a problem now, that's a regression in their API. I've had long conversations with Fonts.com about how their CSS selector behavior differs from that of @font-your-face, as well as most other web font providers, so it should be no surprise that the module is sending grouped CSS selectors, as it always has. And it doesn't require any sort of "fault tolerance" to handle those, as they're completely valid CSS selectors. The JavaScript just needs to treat them as normal CSS selectors, not assume that they're ungrouped, just as it did previously.

I'll contact Fonts.com and discuss reverting this new bug in their JavaScript, which seems like the simplest and quickest way to resolve this.

I'm switching this to support request, as I don't view it as a bug currently, and giving it a more descriptive and less hyperbolic title.

Comment #2

sreynen commented 20 June 2012 at 13:25

Status:

Active

» Postponed (maintainer needs more info)

I've contacted Fonts.com, marking as postponed awaiting their reply.

Comment #3

somatics commented 20 June 2012 at 14:25

No hyperbole was meant, no criticism, and certainly no disrespect. I understand and appreciated most module developers are working diligently to provide important services to us, the regular site developers.

I was simply trying to be helpful to alert people to the issue -- it shut down our site for 2 days right as we launched a promotional campaign (we tweaked the fonts to make the site look juuuust a leeetle bit sexier, and bam..). I would have killed to know what to do right away instead of spending two frantically trying to figure it out, and I love this module (and understand it to be widely relied upon) so I wanted to make sure this issue was understood. That was the spirit of the title of my post. Now that the module maintainer is on it and aware of, the renaming makes sense, anyone new encountering this bug is unlikely to be left in the dark and up a creek (and overwhelmed by metaphors) for weeks, as sometimes can happen with other modules even with a critical bug.

Thanks for addressing this issue so rapidly and diligently.

P.S. I do know they're valid CSS Selectors. What I meant by fault tolerance was the tolerance of their JavaScript to the "faulty" formatting relative to the format Fonts.com asserted to me was the "correct" way they stored their data for selectors -- one record per selector and its assigned font. They were the ones who told me that the selectors were being sent via the JS to the site as one big string and that string was then not adequately parsed when modified temporarily, so when re-modified it was failing to select properly and unhide the font (actually, technically they said it didn't hide the fonts temporarily, it moved them all the way over past the edge of the window). They said that when stored as one selector per record, each one could then be modified and un-modified separately. I witnessed this personally, as I fixed all but two selectors, and all but those 2 selectors started working; the second I fixed the final 2, they also started working. What they told me is that somehow the old JS handled the failure to store selectors separately better. Maybe it's more an issue that the service stored them better before, not that the JS parsed them better. All I can say is it appeared that the selectors were stored the same as before, and they told me the only thing that changed was the JS.

Also, for troubleshooting purposes, we used the old admin UI on fonts.com -- not new.fonts.com -- as the tech support guy said there were some bugs with that new system; this also limited how many new variables were introduced. So, if fonts.com says it's about their new admin system, please note that is not what we are using yet.