mysiteonline™

So, I hear you like the idea of push notifications on the iPhone. Oh, what's that? You wish you could send push notifications from your website and/or iPhone enabled web app? Hey, didn't you know that you can?

Thanks to Mike, and his post about what John Blyberg's been doing, I got interested in Prowl. Prowl is an iPhone app ($4.99 from the iTunes store, I believe) that lets us send push notifications to iPhone or iPod Touch devices (and hey, it works with 1st gen devices too!). You would need version 3.1 of the iPhone OS, and jailbroken phones are not officially supported (some work, some don't due to how they were jailbroken), but for the most part "it just works", and it's fast. From my tests, the longest delay I've had thus far on a "normal" importance level Prowl message was about 2-3 seconds.

So what use does it have? I'm sure there could be quite a lot. There are forums for Prowl discussions, and one of the stickied topics is just about what people are doing with custom notifications, and there are a varied slew of responses. It's quite interesting, actually.

It's not much of a surprise to anyone that's been keeping tabs on this blog (hi Mike) that I have been getting acquainted with the CakePHP framework. Because of all the uses of Prowl, and my newfound love for CakePHP, I've decided to write a plugin specifically for Prowl in CakePHP. I am not the first to create extensions for Prowl by any means, nor am I even the first to think of getting it CakePHP-ready. I've found two others after having started my work that have created Prowl Components: Jacob Oehler Morrison, and Eric Holmes (note: as of this writing, Eric Holmes' domain seems to be expired). Hopefully I can add a little bit more zest and out-of-the-box capabilities to a plugin. If anyone has some ideas, let me know about it in the comments!

I've never been a fan of using JavaScript to fix up an interface. That is the purpose of using CSS. However, with that being said, I developed a very elegant website login page with a resolution of 1024x768 in mind. All of the CSS had been meticulously measured using quite a few pixel-based measurements (over EMs, because I was sure it would be fine for the two horizontal elements taking up the page width). Unfortunately, I had confused our public facing site with our backend staff site's statistics. 32% of our backend site is viewed with a resolution of 800x600. Uh oh!

Times are changing, and computers get upgraded. Although the staff members with an 800x600 resolution might be used to scrolling on some pages to view content, it really wasn't good for the staff site's login to require a scroll (the main site is not yet redesigned, and I designed that for an 800x600 display). I didn't want to have to start from scratch, and even resize images to make them fit. As time progressed, I expected the percentage of 800x600 site views to drop, so this is more of a temporary band-aid that's needed anyway... JavaScript to the rescue.

Screen resolution is easy. screen.width and screen.height, respectively, will tell you about a visitor's monitor's current resolution, but in this case I needed to know the viewport.

Many people state that each of the major browsers use a different approach to determining the viewport, and this is true. But most people also create a function or IF/ELSE case for each possible outcome. I found some code that mixes all three in one line quite intuitively. Below is the actual JavaScript I used (jQuery methods found in there) to solve my issue (I pre-determined the width/height numbers manually for this specific layout).
$(document).ready(function(){ if(vpWidth() < 850 || vpHeight() < 650){ $('#logo').hide(); $('#surface').hide(); } }); function vpWidth() { return window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth; } function vpHeight() { return window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight; }

Quite easy, quite nice, and the most important thing is that the login box is now clearly visible without any unnecessary scrolling (caused by CSS issues) at specific resolutions (tested at 600px width, minimum). If it's any less than that, I can assume it's a mobile browser and we don't (yet) support that; but when we do it'll be a completely different layout that's used.

I hope this might be helpful to someone else, but for the right reasons! (Credit to About.com for the viewport functions.)

When the Saratoga Springs Public Library website was redesigned, although I used a static width (set to something like 720px wide) for the content area, I intended for it to be easily resized with supporting browsers. I made sure to set everything (else) to size with EMs in CSS (similar to percentage).

...an issue with the top navigation cropped up on some computers that I could not identify, nor could I figure out how to solve. For 95% of browsers I tested, and 100% with a vanilla install of Windows, everything worked fine. For those others, the navigation links at the top of our site just didn't seem to align. I thought it might have something to do with DPI or visual settings, but I had no idea how to accommodate for that.

Well I completely accidentally ran in to William Kolean's solution of fixing this issue with Microsoft's CSS expression engine. As the issue was only seen in Internet Explorer (and I already had an IE-specific stylesheet to fix tiny issues), this was a perfect solution, and I put it in to use (just now, actually). I can verify that it worked (on my first and only test) so I'm quite happy. I thought I'd post this for my own records, and to help others too.

http://www.williamkolean.com/williamblog/?p=18
Thanks, William!

I was creating a replicated PDF form in HTML/CSS for work today and needed to get a portion of the form (signature field) to rest at the bottom of the page, whichever page it was. This was easily accomplished in CSS-friendly browsers by using position:fixed; bottom:0; ... however, IE6 does not support the "fixed" position with CSS. Not good...not all of our staff members in the building have been upgraded to use IE7 - most have, a couple have not.

Stu Nichols has found a way to "trick" IE6 in to allowing something almost entirely the same by way of using another CSS bug. It's a bit hackish, but it's not an actual hack. I used IE's conditional CSS to make sure it didn't mess up any other browser's rendering, but the link (and demo) is below in case anyone else needs the same functionality.

http://www.cssplay.co.uk/layouts/fixed.html

Ironically enough, this doesn't seem to work in Safari for Windows properly (haven't tried it with my Apple). Thankfully for me, I don't need to cope with that issue for this form on our intranet. I imagine it's actually a bug in the browser's rendering (only for print, it works just fine for online display).

The title of this post is a bit misleading; I was trying to stuff it for SEO keywords without it being too long.

I ran into an issue with regard to the CSS property of "overflow" that I had set to "auto". When I set some test text of about 100 or so continuous "Hello " words, the scroll bars worked just fine. I then tweaked my node's height, and text and continued, but... The scroll bars weren't showing up, and my text was outside the bounds of the box (and therefore clipped)! Oh no! Tragedy of tragedies!

Through a little experimentation (in the end, this took me about 30 minutes to track down, and then test in all the browsers), I was able to determine what the problem was.