Safari imgTag Extension

Inspired by the Firefox addon ‘imgTag’, this simple Safari extension adds a ‘Make img Tag’ option to the context menu to create img tags from right-clicked images. Some additional markup schemes can be activated in the extension settings, including BBCode, Markdown and Textile.


Safari imgTag 1.5.2 (2011-06-03)

Source code can be found on github:

HTTP Access Control to Multiple Origins

Here’s something that snuck in under my radar. Firefox supports the Cross-Origin Resource Sharing standard (CORS) for HTTP requests of some types of resource. This is a way for a remote host to control access to some types of resource.

The important one for me is web fonts, introduced in Firefox 3.1 (and likely video in the future). On a large site, it’s common to host media resources such as images, stylesheets, javascript, and now fonts, on one or more separate domains from the main domain used to access the page. As web fonts are subject to CORS, the appropriate Access Control headers need to be sent to the browser to allow the domain originating the request (the Origin) access to the resource.

The appropriate header here is Access-Control-Allow-Origin. This specifies which domain is allowed access to the resource. According to the developer document, acceptable values are either the URI of a specific allowable domain, or the wildcard character *. An example given being:


Allow multiple origin values

Apparently, the value can also be a comma separated list of domains, but I couldn’t get that to work in Firefox 3.5. So, how can you list multiple allowable domains? On Apache you can put this in the .htaccess file in your fonts directory:

<FilesMatch "\.(eot|otf|woff|ttf)$"> SetEnvIf Origin » "^http(s)?://(.+\.)?(domain1\.org|domain\.com)$" origin_is=$0 Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is </FilesMatch>

For files matching the common web font extensions, an origin_is environment variable is set when the Origin request header matches the value of the regular expression. In turn, the Access-Control-Allow-Origin header will only be set if the origin_is variable exists. origin_is is set to the value of the Origin header. The always condition ensures the header will be set for all responses, not just those with 2xx success codes (see Apache docs for more information about Header Directive conditions).


You can see Typekit in action on Jeffrey Veen’s website (I assume this is the proposed implementation of Typekit). [Update: 3rd June 2009, It looks like Jeffrey is no longer using Typekit on his website. No previews for you.]

A remote javascript file is linked by the website owner that includes a copy of the jquery framework, and a Typekit class that writes in the dynamic CSS and javascript files specific to that website.

From what I can make out, .otf fonts are embedded in a dynamically injected CSS file using a base64 encoded data url. Although this increases the size of the file compared to its binary equivalent, it can benefit from server compression like gzip. I’m not sure if this is an attempt at obsfucation, or used for convenience, but it’s trivially easy to obtain a fully functioning .otf file. Older IE browsers (IE7 and below) are Internet Explorer (including IE8) is served a fallback to an EOT file.

Because Typekit injects cross-site scripts, you the web developer have to be able to trust the security of their service as much as you would trust your own server setup. Potentially, if they are compromised, any file they inject into your page could also compromise your visitors.

In common with other font replacement techniques, Typekit relies on Javascript and (in Safari at least, I didn’t test in other browsers) suffers from Flash of Unstyled Content.

It seems to me that Typekit is a service where users can subscribe through a single portal to manage the embedding of @font-face compatible fonts (falling back to EOT where necessary) from participating foundries (who?). That’s nice, as far as it goes, but the hyperbole about changing the face of the web is getting way out of hand. The new thing here isn’t Typekit, but the tipping point that’s been reached of browsers that support @font-face.