CSSquirrel

Yesterday I wrote a post at Mindfly describing how to make use of the CSS @font-face rule for embedding fonts into web pages. I figured it was timely, as I’m getting tired of the number of times I have to use an image (or putz around with workarounds like sIFR) to substitute a special header all because of a non-web safe font, or a client with very specific typographic tastes and a very poor understanding of how the web and fonts work together (or more to the point, how they don’t). Furthermore, both Firefox and Opera have intentions to add support to the feature very soon, creating a world where all four major browsers will have the function (although with IE using EOT and not TTF it won’t be all peace and happiness quite yet).

The thing is, the more I look into the topic, the more it appears that @font-face won’t going to be ushering in a Utopian society of pretty fonts. The core issue seems to be how legal is font embedding going to be, and how will typographers feel about developers putting their font files on servers in a place where they could potentially be snatched?

So far the answers seem to be ‘not very’ and ‘not good’, respectively.

Which makes me wonder, what good, if any, will @font-face actually serve us. If, as a solution, it creates only another problem, a legal problem, that standards themselves can’t fix, is it worth the effort investing into this path to web fonts? Perhaps browser people should be looking into another technique that’ll prove to be more secure for the font files. Something that won’t look good on paper but results in a lot of angry mail from lawyers.

Although, it does make me wonder. Is there a technique that could be used with the current @font-face rule that would still protect the fonts?

@font-face. Good? Bad?

I’m not a browser security expert, so I’m not weighing in on the topic as such. However, I am a web developer/designer/guy with a slash in his title, so I certainly feel free to hurl my opinion at the topic regardless.

Today’s comic is in reference to Internet Explorer’s dirty little habit of MIME-sniffing, a process by where under certain circumstances the browser politely thanks a file for trying to tell it what it’s Content Type is, then proceeds to beat it about the head until the file cries uncle and sobbingly agrees to be something else.

(I’m aware that all browsers to an extent have to do some sniffing around in certain circumstances. But rather than chastely sniffing a guest’s shoes, IE is the dog that has stuck it’s head up someone’s skirt, only to frequently come to the wrong conclusion as to what it found).

This is bound to be useful in some cases, I’m sure, such as backwards compatibility with old servers that serve all html pages as plain/text. However, historically there’s been an number of reasons to not do it, such as pictures with bad script hiding in them that IE goes ahead and runs, and the fact that it goes against specifications implementation. While we’re at it, it continues to subdivide the Internet into two different groups, those users that see a page as it should be (with a standards-compliant browser), and those that don’t (with IE).

The good news is that according to this post at the IEBlog, they’re fixing a lot of this with IE8. The bad news is, they’re not going as far as they should, for example: “…if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML.” All in the name of ‘compatibility’. The only way for a page to be rendered as plain/text in IE8 when it has an HTML tag in the file is for the server to include authoritative=true attribute to the Content-Type header.

So… wait, we’ve got to opt in for plain text files to render properly in IE8? That sounds familiar, a lot like IE8’s original plan to force developers to opt-in to rendering their sites correctly in IE8 with a new meta tag. If you didn’t include this little tag, your page would render in all future browsers as it would in IE7. Long story short, that created such a storm from developers that the IE8 team stepped back and changed their minds.

I don’t think that rendering plain/text files as HTML if they’ve got markup in them is an equally volatile subject, but it seems that this new, IE-specific attribute is another step away from standards, rather than toward standards. I think Microsoft is slowly wandering out of the dark and into the sunlight that is a standards-compliant Internet, but I get the feeling that the company will have to keep being poked with sticks to keep it moving in the right direction.

I doubt anyone needs me to tell them this, but Firefox 3 is launched. Go get it. Well, get it if you can manage to load Mozilla’s page. Talk about a heavy server load.

As a response to the last comic that featured Opera (right here), viking descendant and Opera Software web opener David Storey simultaneously did three things at once:

1. He left a comment. Which I love. Feedback of any sort is appreciated, especially when it includes the phrase “funny comic”.

2. He defended his company’s product’s implementations of standards by pointing out that one of the three CSS properties I mentioned is in 9.5 (which is now launched), one is only experimentally implemented, and the third is as he puts it “not in a stable spec”. I’ll give him the first two, but I don’t think word-wrap is unstable enough to justify not implementing it.

3. Lastly, he threatened to attack me with the SVGorilla.

The idea of a smoothly scaling primate collided with my recent CSS3 rgba colors experimentation in my head, and spawned this week’s comic.

Opera’s been doing a fine job with their browser, and 9.5 is actually pretty slick. Will I use it day to day? No. It’s feature set does not offer enough to draw me away from Firefox, which is officially launching version 3.0 in mere hours. If addons became a big thing with Opera, I think it’d have a fighting chance in sucking me in, though. As a rule, I prefer browsers made by browser software companies, not operating system software companies.

That said… although the properties I’ve mentioned earlier (word-wrap, border-radius, and outline-offset, aren’t exactly going to see a lot of use by me. However, CSS3 rgba colors? I’m all over that. I especially enjoy the ability to set an element’s opacity without it affecting all of its children. I don’t think it was a good call for Opera to skip adding this into 9.5, as it means it may be a while yet before we see it in an official Opera release.

Well, on the plus side, it let me escape the vicious SVGorilla.

When it comes to browsers, Firefox is my primary choice. It’s combination of strong standards support and large addons library makes it not only desirable, but indispensable in how I browse and work on the Net. I know I can do web development without Firebug, but I certainly don’t know why I’d want to.

Although I’ve been running the beta (then later the release candidates) for some time now, I’m excited for the upcoming official release of Firefox 3 tomorrow. Although I hadn’t planned out a release party like Mozilla has encouraged as part of their Download Day 2008 event, I’ll definitely be upgrading to the release version to help with their “most downloads in one day” goal.

In related news, while I’ve made it clear how much I dislike their tendancy to swing at IE without checking if their own zipper is up, I am also glad to see Opera 9.5 has been officially released, bringing with it a slick upgraded interface, more speed, and overall better standards support (but still no CSS3 rgba color support yet.) Between those two and Safari, a lot more CSS3 and other standards-related features are becoming available in 2008.

Now if only Microsoft would get off it’s lazy rear and announce a general target for when they plan to release IE8. Preferably this year…