Particularly enjoy the "don't need to run a Java App to download" options.

I found some interesting new ways of speeding up Flash 8's broken ExternalInterface while working on dojo.flash and dojo.storage that I thought folks might find useful.

It's funny that we're talking about having IE fall back to flash to account for canvas - albeit, at the same time it's very appropriate.

Awesome snippet for ActionScript singleton pattern.

Toby Miller has released his Mootools Enhanced Element Script to the masses on MooForum - and it’s a sweet idea that falls inline with how web developers often describe as “how they always code.” How should Web Developers code? Everyone has the basic understanding of how they should be coding - semantic, clean code. They should be coding with the idea that screen readers should be able to easily navigate the site (you know Target tried to fight accessibility in court?) You should be starting with your content in mind - and often it’s always gone - Header, Body, Footer. But why? Generally, we always assume people want the navigation (in the header) at the top. We then include accessibility links to allow them to be skipped. Download lynx and test for yourself - and then hit up some e-commerce sites and see how many use it (I know that Nationwide.com does, outside of e-commerce). Of course, this leads to the question - why include a link that is necessary when we can manipulate the appearance for visual browsers? Content is King - so treat it as such! Why do we lead with our navigation when it’s the content that matters? Content - Navigation - Footer - why isn’t this how a page is coded? It’s something I’m struggling to wrap my head around and start pushing forward with in my own code - to be accessible, and also to show it can be done. Code should be clean and simple! And I hope to see a return to simple websites in the future… After you’ve got your clean, validated code - now you manipulate it with CSS - you take your skeleton and give it its skin and a coat of paint. Javascript enhances the experiment, and flash is the last piece (further enhancement, a plug-in experience). It’d be nice if the accessibility flash detection was reliable… But on to Mootools Enhanced Elements! This goes beyond the simplistic “is javascript available? Then add this ID/class to the body tag.” It goes beyond saying “if less than IE7, load this style sheet and javascript.” If you understand these ideas, you’ve got the basics of what Enchanced Element is about. Yes - this is taking it up a notch. Adding classes, properties, custom elements and styles! I suggest reading the article and checking out the posts about it and looking at the site built with it! Copyright © 2008 iKeif - tech and social media geek, mootools fan, and a ton of links. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact legal@ikeif.net so we can take legal action immediately.Plugin by Taragana

As a web developer, you’re constantly approached with pulling off zany schemes. In the words of Ian Malcolm: Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should. Replace “scientists” with “designers” and you see the dilemma. They know you can pull off some funky effects in flash, so they opt to flash. However, flash is still not quite as easilly accessible and searchable that we all would like - and please, you can try to argue this point, but the majority of flash efforts I’ve seen tend to bypass the accessibility and searchability because it’s just easier to do the cool animations/sounds/effects/transparencies in flash (or flex) than it is to do in javascript. Internet Explorer be damned! The unholy bastion of a front-end developers existence tends to fall on IE6 - which is at 24% and dropping in its market share. This is always the what I end up falling on when talking to a fellow developer, and it usually goes like this: Me: We could totally pull off that flash effect! We can do multiple animations using mootools, and it’d be indexable and still be applicable without javascript if we code it right! Him: You mean those large transparent PNG images that would be sliding into place? Me: Right! We could..totally… pull it off… in everything except IE6…. Him: … Me: …shit. I mean, this isn’t too far from the truth, but the point is - accounting for IE6 is a bitch. I recently had to redo someone else’s code that used a PNG script I had rewrote because the alphapng filter was hitting multiple images on the page (dozens of images had a filter alpha opacity of 1). A quick audit of the code and reorganizing the javascript (ahhh… another blog post for the future, me thinks?) and suddenly IE6 was back in action, faster than ever!….not really, but it was at least usable. So you see a lot of our ideas rely on javascript being utilized - or flash, which still will rely on javascript to be embedded - again, because of IE and other cross-browser issues - so we need to keep in mind that hankering feeling… What if they don’t have javascript? No doubt, some people with disabilities may still be able to use a site that utilizes javascript. It’s possible that they may have some ability to use a browser, but if they don’t turn off javascript, it may make it a more difficult browsing experience. Don’t forget, there are a plethora of mobile browsers that may/may not do javascript well, if at all. This falls into a certain realm of uncertainty - and as I ran through a gamut of big e-tailers sites (American Eagle, Anthropologie, L.L. Bean, amongst others) L.L. Bean was the only one that I could purchase from (well, reach a point where they ask for payment). The inherent problem of this, they rely on AJAX calls to do their server side form validation - so it’s possible that if you don’t have javascript, you could still enter bad data and find out your Christmas order is incorrect, maybe too late when they call to tell you why your credit card was declined, or that it was sent to a non-existant address. Understandably - from a SEO perspective, they only need to index up to the product pages. If they’re smart, they don’t have any “highly relevant, high-traffic” content in their shopping cart pages or payment pages (it seems that those are generic, so it should be moot). The dilemma occurs in how they handle that percentage that is browsing without javascript. Maybe it’s a small percentage. Maybe it’s corporate users, or users from the large assortment of mobile devices. The point is - why should you neglect a sale just because they’re on webTV? Enter the Dragon <noscript> PPK on quirksmode wrote about the use of <noscript> and it’s use in helping point out (to the majority of browsers) that we can throw a little message stating that “hey - you need javascript.” I’ve looked at L.L. Bean’s source code, and they’re littered with <noscript>. But really, this shouldn’t be a concern as… You shouldn’t be catering to a rich experience. Really. You should be presenting a website that works - period. I should be able to hit it in lynx. In Safari. My iPhone. His blackberry. IE6. IE5. We shouldn’t be relying on javascript to pull off effects and basic, fundamental functionality. Javascript is an enhancement, not a requirement. If it’s required, you’ve failed. I’m not saying I’ve got all the answers - but I do know that if we want to code in a way that no matter what crap happens in the near future, we need to focus on the basics and get them executed as cleanly, and simply as possible. There may be a point that we finally say - okay, you’ll need javascript to get these cool “up to the minute” updates, live editing, in place context editing, etc. But that’s really at a point when you have to decide - who is this website for? Who am I catering to? Why do I care if the degraded expeience means things pop instead of fade in? More than likely, this same day will be when you say… Shit, a fraction of a percent of people visit my site on IE6. I might want to tell them to upgrade. Copyright © 2008 iKeif - tech and social media geek, mootools fan, and a ton of links. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact legal@ikeif.net so we can take legal action immediately.Plugin by Taragana

EDIT: So I talked to Toby Miller and he helped clarify some issues I was having - the script has been updated below!

So I’ve been discussing compression - I’m a fiend for it. It’s like a drug to me. I squeeze every byte out of production code. I’d compress HTML into a single line - I’m just that phucked up. Maybe it’s my OCD, maybe I’m just nutty, but GZIPping seems like a no brainer to me. 1-2-3 COMPRESS! What’s GZIP? I’m glad you asked, friend! According to the never-wrong wikipedia article on GZIP: gzip is a software application used for file compression. gzip is short for GNU zip; the program is a free software replacement for the compress program used in early Unix systems, intended for use by the GNU Project. What this basically does is compress your files and let the client unzip them. We’re talking about massive decreases in bandwidth, so that 200k website suddenly shrinks down. No More Optimizing, YAY! NO NO NO! I’m sorry friend, but GZIP is not an excuse to get lazy. You can use GZIP on Javascript Frameworks so that compressed 60k core file can become a 15k file. Wow. Just take that in. 75% reduction of an already compressed file! That’s awesome. 101k html text file can be compressed to 15k. Frickin’ badass. So naturally, why wouldn’t I want to enable this on my Dreamhost sites? The GZIP Code Please note: As I’m using Apache2, we’re calling mod_deflate instead of mod_gzip. I’ve added this to my .htaccess files:

BEGIN GZIP

<ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript </ifmodule>

END GZIP

Danger, Will Robinson! Naturally, their are a few caveats from GZIP, as better explained by BetterExplained.com (heh):

Older browsers: Yes, Virginia, no doubt you may be asked to support crappy browsers. We’re talking old-school-extreme, like Netscape 1.0 on Windows 95. Apache mod_deflate has some rules to avoid compression for older browsers. Already-compressed content: As BetterExplained.com details, you probably only need to compress the “big 3″ (HTML, CSS and Javascript) as images/flash/etc are usually already compressed. Usually. CPU-load: Compressing content on-the-fly uses CPU time and saves bandwidth. Usually this is a great tradeoff given the speed of compression. There are ways to pre-compress static content and send over the compressed versions. This requires more configuration; even if it’s not possible, compressing output may still be a net win. Using CPU cycles for a faster user experience is well worth it, given the short attention spans on the web.

So enjoy the benefits friends, pass on the glory of GZIP! Copyright © 2008 iKeif - tech and social media geek, mootools fan, and a ton of links. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact legal@ikeif.net so we can take legal action immediately.Plugin by Taragana