Archive for the ‘Browsers’ Category

Google Chrome?

Tuesday, September 2nd, 2008

I’m not entirely surprised that Google decided to release its own browser. Considering their whole web-based business model it was probably inevetible. Although you have to wonder how it’ll affect their funding of Mozilla.

What does surprise me is that I heard nary a peep before today’s beta. I feel like a back-country rube that just learned about horseless carriages.

Anyhow, here it is. I like that it’s open source (encourages other browser makers to see what good ideas they’ve created and theoretically incorporate them), but I admit that I’m curious how it’ll shake up the browser usage wars.

You can download it here, and see their official post about it here.

Why Opera’s Market Share Doesn’t Justify Bad Behavior

Monday, August 4th, 2008

I didn’t wake up today with the intent of revisiting old ground, but a motivated commenter rekindled the topic of Opera’s EU filing encouraging Microsoft to be forced to adhere to a series of guidelines for web standards, and my bold statements that both Microsoft and Opera needed to work on adhering to those guidelines.

As I was crafting a response, I discovered that I had more to say on the topic than could be rationally contained in a simple comment.

First, some facts: I don’t dislike Opera. I dislike hypocrisy. Also, I don’t like Internet Explorer. I hate Internet Explorer, and I would prefer to see Microsoft adhere to modern web standards with the same fervor as the other major browser makers.

However, the responses to my earlier posts made by Opera employees and by others on behalf of the browser maker, amount to the following two statements.

1. Microsoft needs to adhere to Mr. Lie’s list of rules they should play by because Microsoft is a monopoly. Opera does not need to do this because it is not.

2. Opera is justified in delaying implementations of “new” features because they’re focusing on backwards compatibility and not breaking the web.

Each is interesting, but ultimately unconvincing.

First, I don’t believe that implementing web standards and new site features is solely the responsibility of a company that is a monopoly. In his well publicized list of rules for Microsoft, Mr. Lie agrees with me. I’ve already quoted the fifth point (relating to adding a new standards-related feature to a browser if two major browsers have already implemented it), and have pointed out useful features that at least two browsers have implemented that aren’t live yet on Opera. I want to emphasize where Mr. Lie states these rules aren’t just for Opera:

“Microsoft will surely claim that it’s impossible for them to develop a browser that complies with the proposed requirements. However, other browsers have played by these rules for years. If Microsoft can’t live up to the standards of the web, I suggest they leave the browser business.”

His assertions are twofold, first that other browser makers do play by these rules (including Opera I presume, which exclusively makes a browser), and that failure to adhere by these rules is enough reason for a company to leave the browser business.

I agree with him completely. I find it comical that some of Opera’s employees apparently do not, and have yet to hear a compelling argument as to why they should be disregarding their CTO’s wisdom. This ties directly into point #2, which is that implementation of new features must be delayed as a necessary sacrifice to maintain backwards compatibility and not break the old web.

Backwards compatibility with the soccer mom-built sites of the world is the same boogeyman that Microsoft has been waving on a flagpole since at least Internet Explorer 6. The world of web developers have yet to give Microsoft any mercy for that, and often cry for blood when feature implementation or standards compatibility is sacrificed on that altar (such as the well documented IE8 meta-tag explosion). I’ve yet to hear a compelling argument as to why any smaller browser maker can justify their own delays at implementing “new” stuff with the same smoke and mirrors and not deserve the same treatment.

In the end, the simple fact is this: I expect better of Opera. I expect them to be better than Microsoft. This means I’m not going to accept Opera using the same excuses as Microsoft, and somehow get away with it due to their size.

So, chop chop. Back to the grindstone, boys.

@font-face: Solution or bandage?

Tuesday, July 22nd, 2008

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?

Comic Update: MIME-Snuffing

Sunday, July 20th, 2008

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.

Firefox 3 Is Go

Tuesday, June 17th, 2008

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.