Application shortcuts are created by clicking on the “Page” button and selecting “Create Application Shortcuts…”. If you select to create a shortcut on the desktop, Chrome then creates the Application Shortcut and puts it on the desktop. All this is simple enough, but what it actually does is make a shortcut to Chrome at the current page and passes the --app flag.

I invite you to try this for yourself with something like Gmail and see what you think. When launched, a Chrome window is open without the tab bar or address bar. The confusing part is that internally, it is treated like a normal Chrome process. So cookies are shared with any open tabs in a normal Chrome window. Why would I want that? If this is supposed to be a Gmail App, wouldn’t I want cookies to be separate? What if someone else needs to check their email quick and I have the App open? I get logged off in the App and their session is replaces mine.

The Chromium bug list has a feature request for this, but it hasn’t received much attention.

Since my job is mainly PHP and MySQL development, I don’t do a lot of theming. I actually like coding CSS, but we have a design team for that. For this blog, it’s actually something I need to think about. I’ve done a lot of CSS coding, but recent events at work have left me frustrated with legacy code, thus sparking this post. So getting to the point: CSS is not an art. Cross-browser CSS is not something one intuitively picks up and starts playing with, it is a language, and to be successful at it you need to know what you are doing.

The key concept is the possibility of writing unsuccessful or bad CSS. The art is drawing up what the page is to look like—concept art, or as some call it “mocking up” a page. CSS is the tool used to get the page to actually look and function as intended, and in every browser. I believe a lot of amateur web developers do not realize the importance of understanding both the CSS specifications themselves and how each CSS command will affect each web browser.

To further my point, this week I’ve been working with more legacy code which has CSS sprinkled all over, and always as an afterthought. This itself is not necessarily bad, as sometimes the importance of getting something semi-functional (or to a state where your boss stops yelling at you) necessitates ignoring certain parts of the process. In this, Internet Explorer 7 was forgotten about and somehow hovering over a certain set of <span> tags makes large parts of the page shift a few pixels back and forth. In an extreme case, it would hinder someone from using the application and potentially cost the company money—again an unacceptable outcome.

Having been dealing with CSS for a number of years now, I feel like I’ve learned quite a bit about how each browser treats different CSS attributes, but new web technology is embraced at a quick pace, and I still find new awkward Internet Explorer rendering engine bugs on a consistent basis. But at the least, having an understanding of what CSS was built to do goes a long way.

At first—and for a long time after that—I didn’t see the point. For example, launching Gmail in such a way still results in launching an instance of the browser, and if you are a cookie fanatic, you’ve noticed that the app window shares its session with other launched windows.

Today decided to take a second look at Application Shortcuts when I noticed the menu option mission from Google Chrome on Ubuntu, and surprisingly discovered they might actually be useful. With the example of Gmail, there is no native desktop application for Gmail so my options are either to use a web browser or some other desktop email client like Evolution, which I hate using since it ties me down to a single computer. Running Gmail as an application through Chrome surpasses this barrier and gives me more flexibility with my web browsing.

Getting to the entire point of this post though: Application Shortcuts are now available for the Linux build of Chromium. When I noticed this feature was missing I hopped onto IRC channel #chromium and asked about it. A nice developer promptly responded saying it was added to the SVN trunk a couple days ago. Sure enough, I ran updates and there it was. So, I tried it out. It’s not the best thing in the world, but Gmail is a lot better ran as a chromium application.

Nowadays a site can specify to use cookies over SSL, but even then, a site can choose not to and offer HTTP cookies over an HTTPS connection. Of course, because cookies do store data on the client and because of their implementation in browsers, a hacker might be able to steal cookie information using malicious Javascript.

Some have proposed alternative methods to using cookies to store persistent client data: hidden form fields, clever URLs passing tokens as REST queries, embedding a flash object, or even using a hidden iframe and writing ajax response text to it. But I feel like all of these proposed solutions only raise more issues.

So then left with no alternatives, I have chosen to embrace cookies when necessary and to not implement them whenever I can get around it. The specific case of having a shopping cart on a website seems to have only one good solution: storing a session ID in a cookie and send that to the server where the actual client data is stored.

Approaching the problem from a different perspective though, when a person uses a web browser, that person is given the option of turning off automatically accepting cookies, or even just rejecting third-party cookies—which I choose to do when I browse. So then there it is: I also love HTTP cookies because I enjoy using websites like Gmail which require cookies for advanced features.