Online-ish is possible, but it means making your application very chatty if you want anything even approaching real-ish time. And even at that, you have no way of knowing whether a user is actually sitting at the keyboard or just wandered off while leaving their computer on with your page open in a browser (it happens, and while you can let them manually set their online status, that's not completely reliable). Essentially, all you have to do is have the page make periodic small requests (using AJAX/AJAJ -- or an invisible iframe with a meta refresh if you feel the need to support Netscape 6), and base your status marker on the time of last request. That means a lot of requests and a lot of database interaction, and it will probably run you afoul of resource use restrictions on any shared hosting platform if you have more than a small handful of users. There's also a lot of latency; the best you can do is to indicate conditions as they were two request intervals ago on average.
You can improve on the latency by using web sockets and polling users directly, but that's going to come at the cost of increased traffic (and will require an "always on" server script/program, so you'd need to be using a reserved-instance host or a dedicated/colo server).
A lower-cost approach is simply to record the time of the last "ordinary" request, whether that be a proper page request or an AJAX/AJAJ request that was going to happen anyway because of normal user interaction with your app/site, and base your presence markers on a time scale that you think is a good indication of freshness/staleness. That'll work well with "little" pages or with an application that demands a lot of interaction, but it will be lees good with a long-form content site (if it takes a reader twenty minutes on average to read a page, then at the end of that time they'll be seeing things as they were twenty minutes ago based on the assumption that twenty minutes of inactivity means nothing -- so the data may be forty or more minutes old).
Keep in mind that this here web thing is meant to be stateless. I make a request, you answer the request, then we cut off communications until I make another request. It's what HTTP is all about. Web sockets can get around that to a degree, but they have their own problems and restrictions, and they're not compatible with (most) shared hosting. You really need to be using a protocol designed for the task, like XMPP, if you want something approaching actual presence indication, and that can get really hairy since you need a lot of service nodes (either a metric crapload of servers or cooperative peer nodes) to manage the traffic it generates if you have more than a few tens of users.