Javascript

Stripping down for IE6

2
1011 days
by in Best Practices, CSS, Development Strategies, Javascript, XHTML

This is a big subject for me as it’s very annoying, IE6 is a pain in the arse, and it always has been, my previous posts will tell you how much I hate the browser.

Recently I have been working on CSS/JS based graphs. The designs for these graphs are amazing, but I shuddered at the thought of porting transparent PNG’s over to IE6 to make this work, and the unforeseeable problems faced by using css/js “hacks” to add certain features to a browser that never fully supported it.

My solution is this… use what’s there, don’t even think of enhancing it. By adding support for transparent PNG’s for a browser that doesn’t fully support it seems silly to me, and goes against my rule of not modifying the browsers default behavior. Why should we keep entertaining IE6 and nudging along a dying horse, whilst we shouldn’t take a shotgun and shoot the fucker point blank in the face, there’s no point in attempting to enhance it and add support by using IE7 support JS to make IE6 behave like IE7.

If you’re more of a visual person, here are a few graphs to show you what I mean…

bad

This is a graph to show the headache caused when trying to backward port features from modern day browsers to IE6

This is a graph to show what should actually happen, IE6 development should stop where the features are no longer supported, i.e. transparent PNG's, then you can enhance the experience for people who don't use "broken" browsers

This is a graph to show what should actually happen, IE6 development should stop where the features are no longer supported, i.e. transparent PNG's, then you can enhance the experience for people who don't use "broken" browsers

We should seriously take a look at this and consider what we’re doing here, by supporting dying browsers we’re encouraging people and companies not to upgrade their browsers, we’re supposed to be driving technology not dragging it by it’s heels.

Let me put it another way… if Microsoft didn’t screw up IE so much we would be doing things like this now! Without Flash!

JS – Adapting to the situation (smart coding) with Portlet’s

4
1021 days
by in Best Practices, Design Patterns, Javascript

Preface

For the past few months I’ve been workin with a content management portal to deliver my XHTML/JS/CSS I can’t stress how big a pain in the arse this is, as with any CMS there are limitations in the way that it works and problems when you try to use it for more than what it’s really made for. Limitations of a CMS can include:

  1. not being able to add code/css to the header
  2. the CMS just spitting out any old JS/CSS in the HTML
  3. HTML not being formatted correctly, or just spitting out random XHTML tags

The list could go on, but I’m too tired to really carry on. It puts a big downer on you most of all when you’re so anal that all of your HTML is well formated and perfectly indented, only to find when the site goes live, all of your code is on one line or it looks like it’s been run over by a bus.

My main concern with coding for CMS’s that use portlet’s is the simple fact that each portlet is in essence it’s own self contained application/controller. It becomes a pain when you have to constantly check to see whethter a portlet exists in the DOM on runtime.

How can you work around this? Think like a CMS. You might be thinking, what the f**k is he talking about? The simple solution is to adapt the way you code to suit the CMS. Instead of having one big JS file for a page or site section, seperate your code into small chunks, this will also help you unit test your code which I’ll come to a bit later.

(more…)

Agile Development

5
1259 days
by in Development Strategies, Javascript, PHP

Working at Channel 4 I’ve been introduced to Agile Development, to sum it up in one sentence…

“It’s a way of working in a development team, where the specification for a project is constantly changing and the waterfall approach (you get a spec, build to it over a long period of time, get feedback and make amends) just doesn’t cut it.”

It’s a completelty different way of working, and it’s full of terms which I would say were thought up by some drunk developer, introducing words such as “brown bag”.
(more…)

JS Lazy Developer

0
1396 days
by in Javascript

With JavaScript being taken alot more seriously, we’re seeing a rise in JS best practices, the days when JavaScript would be mocked based upon annoying popup’s, really crap navigation systems that broke in every browser except IE, and seriously disgusting page effects that should stay relegated on people’s myspace pages are pretty much over. JavaScript has reached a new standard and coders are helping to drive it.

(more…)

{ Publisher Subscriber Pattern }

2
1396 days
by in Design Patterns, Javascript

A few weeks ago I was introduced to the Publisher Subscriber pattern in JS, pretty much confused by the methodology behind it I decided to give it a go.

The publisher subscriber pattern allows several methods to subscribe to a particular event. Methods and functions can unsubscribe and subscribe to any event at will, this is handy if you want to remove or add a method to an event handler at runtime.
(more…)

Zend Framework and DoJo

34
1396 days
by in Dojo, Javascript, PHP, Zend Framework

I pretty much wet my self when ZF announced that they’d be integrating Dojo with the next iteration, and low and behold the first RC was made publicly available a few days ago. I literally dived in head first today, only to find the documentation was some what lacking.

I don’t think the documentation is quite complete, but hats off to ZF for taking a step in the right direction.

Here’s a quick tutorial on using Dojo’s container’s and pane’s with ZF. I’ve added line breaks so it fits into the old blog.

(more…)

Go to Top