Flogging English » javascript

Navigating the changing IE landscape

retsoced — Tue, 19 Oct 2010 03:51:57 +0000

Now that the IE 9 beta is available, people have started popping up on some of the stats of a few of the websites I maintain, and this is proving to be just as troublesome as just about every other new release of IE. The thing I noticed right off the bat, in fact it was impossible to miss, is that a site running a DHTML menu throws JavaScript errors like they were free, but only in IE 9, and only if it is not in compatibility mode. So, rather than monkey about in some damn fugly JavaScript, I opted to just set the site to force IE to render in compatibility mode.

There are a couple of ways to do this, the most basic is to drop a meta tag in the head:

or

This way would have been laborious and quite tedious going through all of the pages in the site and making sure the ones that are not content managed have this new tag. Meh – so not doing that.

The way I opted for was to simply add it as a custom header in IIS (thanks to Joel Varty for the nudge), and be done with it. It’s pretty simple, just open up the IIS snap-in, right click on your site and open properties. Select the HTTP Headers tab, click add then enter “X-UA-Compatible” in the custom header name field, and “IE=7″ or “IE=EmulateIE7″ in the custom header value field. I used the IE=EmulateIE7 value because it seems to be the most flexible, and doesn’t absolutely force IE7 rendering, especially for pages using Quirks mode.

Pretty simple: now it’s all fine for even the most cutting edge of IE users.

You’re welcome.

Return from the 3rd level of malware hell

retsoced — Sun, 08 Aug 2010 19:19:50 +0000

There are days, that the interwebs suck dynamically placed, interactive Donkey Balls. Yesterday, was one of those days.

Come to find out at some point on Friday, Flogging English was, for lack of a better word, hacked. Two JavaScript files had some malicious code embedded in them that tried to do something well…. malicious. What? Dunno man, I just deleted that shit.

Google alerted me late in the day on Friday, meaning I didn’t see it until I checked my email a mere 30 minuted before my scheduled 50 mile ride. I fumbled about a bit, did several full searches of my blog database and found nothing. Then I started scanning the code of the pages that Google was reporting as infected. Still nothing. I made a few changes, thinking maybe it was in error – and requested a review, then went for my ride.

Well, it wasn’t an error, and Google showed me a couple more pages, one of which led me directly to my swfobject files that had been injected with the poopy code. So off I went to download the latest version of swfobject, and to rewrite all of my static Flash pages to use the new code file. Whew. With that done, I went back in a started looking at my admin setting for the blog. I had been allowing everyone who wanted to register to do so, and come to find out, I’m guessing through a hole in WordPress, someone was able to make themselves an admin. Well, not for long, and now I’ve locked it down, and only a handful of users remain. If you were one of the folks I deleted, my apologies, please let me know and I would be more than happy to sign you up again, although you do not need to be a registered user to sign up for updates if that’s all you really want.

The final mistake I made was allowing the blog directory to be written to. This is a total n00b mistake, and I’m not sure when I did this or why – so in some respects I deserve what I got, and I’m lucky it was pretty simple to fix.

All in all, I’m pretty lucky it was as easy as it was to get fixed, authenticated by Google, and the malicious code warning removed. This system seems to work pretty well, and pretty quickly since all of this went down on Friday, and not weeks before. On the plus side, now I have new clean files, a more organized directory structure, updated code files for all of my javascript frameworks, and a better understanding of how to fix these things when they happen.

Mobile device support through JavaScript and CSS

retsoced — Thu, 18 Jun 2009 11:01:54 +0000

If you are in the business of designing, building or maintaining a website these days, you should also be concerned with making sure the maximum number of people are able to view the content on those sites. Meaning that if you aren’t doing something to support mobile web browsing than you are a bit behind the curve. It’s really an accessibility issue, not too far off from the ideas implemented in making websites accessible to people with disabilities. We’re just talking device accessibility, so let’s take a look at a couple of really simple ways to get this done.

JavaScript

If you go the JavaScript route, I found this little gem some time ago, that covers both the client and server side detection using JavaScript and PHP. Here is an example page of what the output looks like if your detection should fail. If you are on a mobile device, the page redirects you to the root of FloggingEnglish.com. I know some older and low-end devices may not support JavaScript, but since it’s pretty freakin’ ubiquitous these days, so I think it’s pretty safe. There are other JavaScript solutions out there, but this is one is clean, simple and easy to update.

This would be a good solution to incorporate into a Flash site as well, especially since the iPhone doesn’t support Flash yet. I know the iPhone is not the most widely used device, but that doesn’t mean you shouldn’t consider that too. With the output from the example you could place special tags or content based on the type of device, offer alternative viewing solutions for your visitors, or simply redirect to a CSS based solution for faster viewing.

CSS

Working a well written CSS style layout into your site is always an excellent option whether you’re primarily concerned about mobile devices or not, but with CSS 3 it’s becoming easier for developers to target mobile devices accurately and reliably. Media Queries are relative newcomers to the CSS scene and they are becoming more supported and in the case of Apple, the way they recommend you target the iPhone. They are currently Supported by all main stream browsers that are standards compliant, and supposedly IE is even on board with this one, but Opera, Safari and Firefox all support media queries.

So what is it then?

Yup. That’s it. The above code would target any mobile device where the viewport measures 320px or wider, like the iPhone for example. Granted that’s a simplistic example, but you get the idea. Dean over at Bushido Designs posted a great article Bulletproof Mobile device detection. In fact that example doesn’t really convey the strengths of media queries and how flexible this method really is. If you take a look at the W3C recommendation, you will see the following features:

width
height
device-width
device-height
orientation
aspect ratio
device-aspect-ratio
color
color-index
monchrome
resolution
scan
grid

So you can begin to see the strengths of this method and how it could be the key to blissful mobile CSS support. Using the color feature for example would allow you target a specific stylesheet for devices capable of rendering in color, while using aspect-ration you could target 16:9 devices as well, like the PSP (480 x 272).

Of course none of this would be an issue if Apple and Opera hadn’t decided to ignore the handheld media type with their mobile browsers. With the two biggest mobile browsers off the tabel, that pretty much renders the use of handheld useless. A move that is decidedly Microsoft-esque.

Test your site for IE goodness with IE Tester

retsoced — Tue, 23 Sep 2008 01:16:13 +0000

Looking for a functional way to get IE 8 and IE 7 to run on my machine today, I found the IE Tester project, and I have to say that for an all in one IE testing app, it works quite well. Up until today the only tool I had at my disposal was Multiple IEs from TredoSoft and the biggest limitation here is that it doesn't incorporate 7 or the 8 beta (1 or 2); which IE Tester does. Since IE 8 is due out this quarter (I think) it is absolutely imperative that devs start testing (if they haven't already) for this new wonderful application to see how it destroys, or interacts with the web. For more detail on what the IE team is doing with version 8, check the IE Blog.

The biggest benefit to IE Tester so far is that it can be installed along side all of your other browsers (including Multiple IEs), unlike the frustrating paradigm that Microsoft operates under of not allowing multiple versions of IE installed on a single desktop. Instead they say you should test using Virtual PC and load up separate version of the OS virtually – yeah…. that's a lot better than just opening a browser.

Working with IE 8 so far I have found a lot of the expected CSS weirdness but above that I have also found that the xFx JumpStart DHTML Menu Builder menus fail irrecoverably, and since there is an open thread posted in May with no replies, I have a very low confidence threshold that anyone cares enough to fix it. This is bothersome simply because I have sites that use this menu, and now I am forced to find alternative solutions since a wait-and-see mentality doesn't really work for me.

IE 8 has a compelling list of new features and standards oriented enhancements, being a quantum leap in the right direction for the kings of the one-way road. Continually having to go to battle to get everything to work across 5 browsers and something like almost 8 versions is a bit tiresome and far more complicated than necessary. I still get a ton of hits from IE 6 users both here and my day-job sites, which I mainly attribute to the bad press IE 7 received after launch – much in the same way Vista has gotten vilified. People and corporations have made the flawed decision to not migrate to IE 7 under some false ideology that they are better off with 6, never mind the gaping security holes and out dated rendering engines.

Okay, so I getting off topic… again. Since I have to find a new menu anyway, I am compiling a list of AJAX menus to replace the DHTML menu, so once I have that worked out I will post that list here – in the meantime test your sites with IE Tester.

Copy source code with JavaScript and Flash

retsoced — Fri, 18 Apr 2008 03:44:10 +0000

My latest project to go into production is a retail targeted newsletter site designed to deliver content both on the site itself and, naturally, through a newsletter to the subscribed members. As a little background, the site has a custom-built CMS managing 90% of all of the content, including every issue of the newsletter and all of the contained articles. One of the obstacles that I needed to overcome was a way to easy way to get the dynamic content from the database into a seperate mass email application fo delivery. This sounded pretty simple, so I saved it until last.

After a bit of searching, I found information about Firefox and Opera having security measures preventing this from working right out of the gate. Okay, but I know sites like Google, Amazon, and countless others have pulled this off – so I know it's possible. My criteria was pretty simple:

copy the source code of a
that wrapped the essential content to the clipboard by clicking a button.

That's it; nothing too fancy. The next thing I found was an example of pulling text from a textfield on Jeffothy's Keyings blog. I didn't have content in a textbox though, it was in a

– so I altered the code to pull the data using innerHTML.

document.getElementById('sourceDiv').innerHTML;

That resulted in undefined being copied to the clipboard (I'm still not sure why). So back to Google to find some .net examples, but they turned out to be far more complex than what I wanted to use. I knew I could do it with JavaScript though; so I went back the first example. First, I simply set up a function to grab the code and fire an alert.

This worked fine. So the next part was to get it to the clipboard, but I kept running into not being able to pass it to the clipboard function I downloaded from Jeffothy's site – so I added a textarea, and set style display:none. Then copied the code out of the textarea onto the clipboard and viola!

But not quite. IE doesn't like the textarea set to not visible and wouldn't recognize it being there at all (throwing a JavaScript error), so I had to change the style to width:1px and height:1px to get it work cross browsers.

Now the interesting part about this is the swf file. It is the key to getting this whole deal to work. By using the _clipboard.swf file (originally built by Mark O’Sullivan of http://lussumo.com/), you are able to get the copied code out of the browser and onto the clipboard by passing it to Flash's System class using the setClipboard method. Pretty ingenious really.

All you have to do now is just drop a form in the page around everything you want to copy, and a button and textarea.

I wrapped it all up in a zip file for those who want to download it.