Perhaps you found a span containing the string ‘BESbswy’ in your content? Maybe your Google results contain the word ‘BESbswy’ repeated many times? Think you’ve been hacked? You haven’t.

You’ve fallen prey to a runtime test in the Typekit/Webfontloader! I began noticing this in drafts I’d written while testing old versions of my TinyMCE Typekit plugin. It would appear that this issue doesn’t affect the asynchronous version.

As part of the font loading process, a span element is created with the text “BESbswy”. But why ‘BESbswy’?

A comment in the font loader source explains:

/**
 * Default test string. Characters are chosen so that their widths vary a lot
 * between the fonts in the default stacks. We want each fallback stack
 * to always start out at a different width than the other.
 * @type {string}
 * @const
 */
webfont.FontWatchRunner.DEFAULT_TEST_STRING = 'BESbswy';

This is all part of the font loading test. The font loader creates 2 spans, and then compares their widths. If the widths match, the font loading has failed, and the inactive fallback fonts are used. If the spans do not match, then the requested fonts have been loaded and the test string now is now rendering a different width, and font loading was a success!

/**
 * Checks the size of the two spans against their original sizes during each
 * async loop. If the size of one of the spans is different than the original
 * size, then we know that the font is rendering and finish with the active
 * callback. If we wait more than 5 seconds and nothing has changed, we finish
 * with the inactive callback.
 *
 * Because of an odd Webkit quirk, we wait to observe the new width twice
 * in a row before finishing with the active callback. Sometimes, Webkit will
 * render the spans with a changed width for one iteration even though the font
 * is broken. This only happens for one async loop, so waiting for 2 consistent
 * measurements allows us to work around the quirk.
 *
 * @private
 */

So how did this get into your page content? More so why does it show in Google results, but when you visit the page, it isn’t there? The most likely culprit is the editor itself.

When using an editor such as TinyMCE, with typekit fonts enabled, the loader creates the span element. The markup for the span is then included into the content by TinyMCE, and gets saved. The span itself has inline styling preventing it from being seen, preventing you from viewing it on the frontend or in the editor.

As it’s assumed the page is freshly loaded, the typekit font loading will happily recreate the element however many times it likes, unaware that a test element from a previous page load is already present and saved.

Fixing the Issue

In WordPress, you should be able to see the hidden spans in the text/html content view. Deleting and saving in this view will remove the tags, but you may want a more permanent solution.

The three choices are:

• Use the asynchronous typekit code ( see my previous post for my TinyMCE plugin )
• Modify your Typekit TinyMCE Plugin to remove any spans containing the word ‘BESbswy’ after a second.
• Add a filter to the content on post save that removes the span