tl;dr

• my mum is potentially very ill – waiting on dr’s full diagnosis,
• I am a diabetic – this will mean less booze and delicious food

I’ve got type 2 diabetes – meaning that it was largely preventable if I had taken a bit more care of myself and tried to live rather less excessively than I have been, but saying that it has been pointed out to me that I’ve at least done it the right way and ate all the good food opposed to crap but still, not the nicest thing to be told and for someone who likes to beat himself up over his poor choices rather a doozie.

I went to the doctor thinking that my lack of energy was down to me sleeping like shit because of stress/anxiety and while that might still be part of the case it was in fact being made much worse by diabetes.

So what does this mean?

The good news is that as it currently stands I don’t need any pills or injections and can keep things under control with a healthier life-style. Alas I’m now going to be diabetic for life but I’m pretty sure I can make this be just a fact rather than something that’s going to hinder me in any big way, indeed it’s not like I’ve felt at my best for a while now so I’m going to see if I can use this in a positive way.

Fitness

It’s fair to say that I’ve let this slide rather. I was and never will be a long distance runner but I’ve dunked basketballs, taken life-guarding grade swimming classes and been a surprisingly fast mover when I need to be.

I’ve joined a gym, have swum for the first time in probably over 10 years (to amusingly bad results) but I’ll get there, just need a bit of time for my legs to get used to things.

I like gadgets so I have a fitbit to keep track of things, and to provide me with a bit of a push in regard to doing stuff. It’s not great viewing right now but my profile is here – http://www.fitbit.com/user/25H864, feel free to friend me if you want.

Food

Along with doing bugger all exercise food is probably my Achilles heel, and indeed it’s one of very few ways I have to turn my brain off.

I still want to eat good food and I’m hoping I still can, just maybe a bit less of it. And those nights when I get home late and order take-away will not be happening again. If I get back to where I was before, where good meals out are a treat opposed to just something I do for the sake of it I’m hoping I should be good with this – the occasional burrito, home cooked goodness and less crap along with more activity should work out just fine.

Beer

Hmm yeah – I tracked the calories of the beers I was drinking at the last Pub Standards I was at, and it wasn’t a fun time; indeed I left before it even got dark because it wasn’t a pretty sight.

As someone who has made a bit of an alter-ego out of my enjoyment of beer this is going to be difficult but I’m going to have to drink less of the stuff, maybe drink other stuff instead and maybe go for water every now and then – which to be honest is a drink I enjoy anyways and already drink a fair bit of. Also teas feel like they’re having rather a renaissance – in place of wines flights they’ve started doing tea flights (one of which I’ve got a review waiting on Ross Eats) and while I’ve never really been patient enough for teas I might well give them a go.

So yeah – not the best of weeks but hopefully, at least for me, there are lots of things I can do to make things a lot better. I’ll keep you all posted.

Assumptions

1. While the steps I’ll be outlining are easily reproducible across any version control system the code snippets I’ll be proving are assuming that we’re using git.
2. There are numerous git clients out there but I’m suggesting that using the CLI (command line interface) is the best way to go. I’ve not found any desktop client that makes things easy, or in some cases possible. Let me know in the comments if I’ve overlooked a good one
3. You’ve already got a repo checked out locally and set an upstream remote to keep in-sync

tl;dr

I’ve written a lot of words with this article where I try and explain what’s going on. In essence the process is this:

1. git checkout master

git pull upstream master

git checkout -b branch-name

2. Do work
3. git rebase -i HEAD~{number of local commits you made to fix things}
4. git pull --rebase upstream master
5. Send pull request
6. Go through code review
7. Party

I’m also feeling that this could be a perfect time for a screen-cast…

Getting started

Before you start coding there are a few things you should do in order to make your code easy for the project team to accept.

Fix a real issue

Check the project bug tracker for a bug to fix and assign it to yourself (this will stop anyone else working on it and let people know that you are). If the thing that you want to fix isn’t found then file a bug yourself (follow my article on good bug writing) and assign it to you.

Fix one issue at a time

One problem I’ve found people get frustrated about is when their pull request gets stuck in limbo because while 90% of it is good the remaining 10% is causing issues; the 90% is good to merge and solves a number of issues but can’t be because of the stuff holding it up. You can solve this with a bit of focus and in the same way that filing one issue per bug (and not a mega bug with about 5 different problems in them) makes them easier to resolve in your contributions it makes it easier to land in the project.

Update your local code

Depending on when you checked out the repo things might have changed a little. Out of habit whenever I start work on a new issue I run:

git checkout master
git pull upstream master

This makes sure that you’re on the master branch and have everything up to date – meaning that you should be working on the same code as everyone else in the project.

Work in a branch

git checkout -b branch-name-of-choice

Working in a branch means that you’re always able to update master without worrying about any local changes you might have made to it. This also means that if you need to work on a new bug before finishing an existing one you can just checkout master and create another.

Do the work

At this point you’re ready to work. There is nothing specific to open source projects here and you should work as you normally do. Make sure that you’re:

• commenting your code,
• writing tests if they’re needed,
• not breaking existing tests.

The only thing to look out for is that you’re following the code writing style of the project – if variable names are all in camel-case don’t start naming them with hyphens or underscores, if end line colons are required then don’t go leaving yours out. Hopefully the project has a CONTRIBUTORS.md file containing this information or a style-guide document to follow.

Once you’ve fixed the issue

You’ve done the work and fixed the issue. While you could open the pull request now there are a couple of things you can do to make things easier for yourself.

Send an atomic commit

In your local branch you might have completed the work over a number of different commits. Locally this is fine but to get into master it’s good practice to have just one commit. You’re going to want to do an interactive rebase; this is also sometimes referred to as ‘scrunching up your commits’.

First up see how many commits you’ve done, for this example I’ll assume 3 (one for the initial work and another where you fix stuff you didn’t notice beforehand – something I do all the time!)

Now run:

git rebase -i HEAD~3

This will give you you’re list of commits and a few options. Generally what I do is pick the top commit and fix-up all the remaining ones. If you want to change the commit message use reword (instead of pick) and you can do once the rebase has finished.

What an interactive rebase looks like

Update your branch

Depending on how long the work has taken there is a big chance that something might have been updated in the upstream repo.

git pull --rebase upstream master

Fix any conflicts and once this is complete just re-test your code to make sure it’s all still working as expected.

Send in your pull request

This is done via github. Make sure to reference the bug somehow in the summary or description so people can check that it does what it is supposed to.

Fixing conflicts while rebasing

Up to only recently this used to frustrate me no end. The key part is to not commit things once you’ve fixed the conflicts, just add them and use git rebase --continue. If you commit you’ll start working on a non-existing branch and leave a incomplete rebase – and that really is as confusing as it sounds!

Code review

Be attentive to any comments made and fix them up (remembering to re-run git rebase -i HEAD~2 each time to ensure the atomic commit, you’ll also need to re-push your branch with the changes to git git push -f origin branch-name).

The code review process is one worthy of it’s own article but the main thing to remember is that all the comments will be done for reason, and it’s a conversation so if you’re unsure on anything please do ask questions!

Code is merged

Once you’ve passed review you’re code should be merged in – and you’re now an open source contributor! Follow these steps each time and it’ll soon become a habit and second nature.

Bugs can come in a couple of flavours, and I’ve tried to split this guide into two sections to cover this – reporting errors and asking for new features or enhancements. Depending on what you want to do the required information is a little different.

Reporting errors

It’s really easy to file a bug saying “this is broken” but broken can mean a load of things and can also mean different things to different team members. No one likes having bugs in their projects so the goal here is to provide enough information for people to initially see what the problem is and then understand how it comes about so it can be quickly fixed.

One thing to also remember is that where it comes to errors a load of small bugs are much better than one bug containing multiple issues. If a developer manages to fix all the issues except one (which for whatever reason is too difficult to fix quickly) then the remaining fixes could get held up for ages – and that’s not good.

Information to provide

1. Briefly describe the problem – if you can do this in the bug title then great, if you need a little bit more space then include that first in the description,
2. URL – provide a URL to the page the bug is happening on,
3. steps to reproduce – what did you do to find this bug? Reproduce the error and provide a list of steps that the team can follow so they can see what you’re seeing. If you’re filling out a form include what you’re putting in each field – as there could be something in there that’s causing the error,
4. screenshot – if this is a visual bug (things not looking correct or information not displaying as you’re expecting) then a quick screen-grab will tell a 1000 words,
5. some technical information – not all computers are alike so before it’s tried on a developer machine and closed as “works-for-me” let us know:
   • the operating system (mac OSX, Windows…),
   • browser you’re using (firefox version 19.0.2, IE9…),
   • if you’re using anything other than a desktop or laptop computer what that is (nexus 7, iPhone 5, xbox 360).

Remember if extra information is needed then it will be asked for – but I think in 95% of cases this will be more than enough. Also remember that opening the bug is just the start of the journey and there might be some additional aftercare needed once work has done on it.

Asking for new features or enhancements

When you’re asking for new things to be added to a project you should be looking to provide enough information for the project team to know what exactly you want and (I think most importantly) why you want it.

Things to tell us

1. Briefly explain the new feature/enhancement you want – if you can do this in the title than great, but an additional paragraph in the description is fine,
2. inspiration – is this a feature that you’ve seen implemented on another site? If so send us some links so we can see it in action. Is this an idea that you’ve thought up in your head? Get it out or your head and on some paper and attach your simple (or complex) wireframes to the ticket,
3. why you want this feature – if this is something that you believe will open up the project to new users and markets than that’s good information for the people who prioritise the work schedule to know.

Importantly with feature requests is the aftercare, if you’re wanting your feature to be developed and made a reality pay attention to my bug updates!

A bug is for life…

As I mentioned in my opening paragraph filing a bug is the first step into a community around the project, so stick in there until your bugs are closed. If you’re asked for additional information about something try and provide it as soon as you can, and if a code bug you filed has been reported fixed and pushed to dev take a look to ensure that it has been (and if not provide any new details on the current ticket).

For extra credit if you can fix the bugs you’re filling then feel free to assign them to yourself and get hacking, what better a way then to introduce yourself to the project

While summarising rather the big things that I took away from @media’s past were:

• progressive enhancement – this is the true way to build sites,
• content is king,
• performance matters,
• ensure that you’re site is useable via devices other than the mouse

and after reading my notes from the 12 talks during the day, give or take a few of the reasons behind them being important issues this is what I’m guessing many people took away from Responsive Day Out, a conference happening a good 4/5 years since @media was at it’s peak epicness.

Progressive enhancement

From some top tips from Richard Rutter on avoiding text-gliches when loading in webFonts, to tips on making sure that your users “time to content” is as quick as possible, to advice on how to make sure that your work is viewable on as many devices as possible by starting off with HTML and then layering on your CSS/JS to was clear that any developer at the conference not doing progressive enhancement will hopefully start thinking about and practising it now.

One thing I liked was this code snippet:


if('querySelector' in document
&& 'localStorage' in window
&& 'addEventListener' in window) {
CODE!!
}


from Tom Maslam – this is what the BBC responsive dev team use to define if a browser is ‘modern enough’ to get the full mobile experience.

I’ve said a few times that I was never sure when progressive enhancement stopped being the top way to build sites but if it gets back into fashion again then that can’t be anything but a good thing.

The focus on content, “content is king”

Most of the design talks centred around ensuring that the content that you start with is suitable and consumable on small screen devices. Content out design (all content first then build a site around that) was touched on and a talk about responsive navigation patterns by first time speaker David Bushell started off with him saying that if you don’t know your content/IA then you may as well just pick any one of the options that he was about to present.

Performance matters

Following on nicely from both the content is king and progressive enhancement streams the thing touched on during pretty much all the development talks was performance, and the need that to ensure that low-bandwidth users don’t get pissed off and leave we have to strive to keep our pages as light weight as possible, or at least give the impression of it being so.

From JS loading strategies, to a couple of tips on caching and image optimisation (*cough cough* – http://www.thecssdiv.co.uk/2013/02/images-why-the-right-format-matters/) the performance cost of a fast loading site was hammered home. I also found it funny that people were talking about a ‘performance budget’ for sites – meaning to keep things fast and under a specific page weight trade-offs would be made. I remember some developers I used to work with in my very first web-job talking about page weight being important during the dial-up days, and here we are again

Multi-device usage

Wrapped up in a couple of talks were the need to design/develop your sites for usage with a wide range of input types. I didn’t twig things during the first time I saw Anna Debenham’s talk on console browsers the gist of that talk is that while we can’t guarantee the code support we also can’t the input device, meaning adding in support for keyboard events like :focus and not relying on :hover are potentially as important to responsive development as coding for touch and swipe events are.

I also liked the sound-bite “code for one universal event” (again from David Bushell), doing should also be helped with pointer events which got a mention in Bruce Lawson’s talk. While we were clearly talking about device and console users support the fact that multi-input support is being talked about again I am sure will help with pushing some of the old accessibility practises that seem recently forgotten to the fore again.

Summary

That responsive design is scary or that we’re winging it was repeated a number of times through-out the conference and while from a design perspective I can imagine that from a dev perspective it feels that as long as we continue to stick to our tried and trusted techniques we’ll at least start off on a very good path that’s easy to move around on while new best practises are being discovered.

Full coverage from Responsive Day Out should be up soon on lanyrd, the sessions were recorded so hopefully they’ll be released soon – there is some good stuff in there.

The three image formats I’m going to cover are .gifs, .pngs and .jpegs – they all have a subject matter that suits them best. Using the correct one can save you a ton in page weight.

jpegs

Simply put – if you’re uploading a photo always use a jpeg.

JPEG stands for “Joint Photographic Experts Group” and is named after the committee that created the standard – pretty much meaning that it’s specifically MADE for photos and made by the EXPERTS in this field – listen to them!

A jpeg of some delicious food – 45kb

If you’re creating a new file make sure to play around with the quality setting – if you start off with a high-res image you can reduce the quality (and filesize) with in many cases no obvious visual loss. Be aware that each time you re-save a jpeg it will automatically loose some visual quality so always try and work on hi-res or original files.

pngs

Use a PNG for graphics, logos and anything requiring a transparent background.

PNG stands for “Portable Network Graphic” and like jpegs the hint is in the name, GRAPHICS. Image software tools provide a number of settings on transparency type, matting and colour dpeth that can squeeze out as many bytes as possible and still provide a crisp image with a smooth edge.

The same delicious food but now a png; and 445kb (10 times bigger)

They come in two flavours – 24 and 8 bit. If IE6 support is still important you need to use 8-bit, if not 24 bit will give a slightly larger filesize but a much better quality image.

gifs

It used to be that gifs were the image format of choice for transparency but with the introduction of PNGs the one main use for gifs online are to spread animated fun and laughter through sites like – memebase.cheezburger.com/senorgif and giphy.com/.

If you have a flat graphical logo and you really want to squeeze every last byte out of your page weight a gif might just do the job.

other image formats

There are other image formats, here are my feelings on using them on the web.

bitmaps or tiffs

Please do not use them in your websites.

webp

Something to look out for. This is a new image format and one that is said to provide images a good percentage smaller than both jpeg and png. The problem right now is lack of good out the box browser support but it’s worth having a look out for updates on developers.google.com/speed/webp/.

Bruce Lawson has provided a nice post around the benefits of webP, and also the downsides in implementing it right now if easy cross-browser support is required, have a read over on his blog – save-bandwidth-webp-with-fallback

And finally

Once you’ve got the right format in place you can save even more bytes through running your images through an image optimisation tool. The best one I’m aware of is imageOptim, it’s free and can always seem to squeeze some file size out of somewhere.

I hope this little article helps you with your 2013 webpage diet, I think we could all do with shedding some bytes somewhere!

To put this in perspective last year’s positive achievements include:

• launching and then supporting 8 new websites,
• upgrading ‘Team Ross’ into ‘Team WebDev’ by bringing Andrew Hayward into the Mozilla Foundation,
• helping in a number of events being run inside and outside of @MozLdn (our lovely office in Leicester Square).

And you thought all I did was drink and swear.

MozFest – an amazing event (with a blimp) that I was largely silent about (original photo by paul_clark)

So how am I going to manage these things?

Work load

Last year I certainly did too much, it got to about November and I was gone, dead on my feet and running on fumes. 8 websites aren’t too much work if they’re equally dispersed through-out the year, but when you get to the point when you’re being asked to launch a number of these sites in the same week (some the same day) that’s something you can’t continue doing for long. One of the initial changes that has been made in 2013 was to remove ‘Team WebDev’ and bring it into the greater Mozilla Foundation engineering team. This means that I’m no longer a team lead and I don’t manage anyone but hopefully should have the positive of meaning that I’ll no longer have to do the majority of my work on my own. We’ve got a fairly big team now in the Foundation and some very clever people are part of it so this sounds like nothing but progress.

This is Erin Kissane talking to someone at MozFest, probably about a website I made with her and a bunch of other cool people called source.mozillaopennews. I’m glad someone said something about it because I didn’t (original photo by mozillaeu)

External contributions

I look on with envy at the work that the Mozilla community get up to on Firefox, FirefoxOS and our larger website projects. I’m hoping this year that we manage to get webmaker tapping into that community too. We’re already moving our stuff around to make things easier to find and easier to work on (more details coming soon) and we’re hoping to learn from our own popcorn dev team to see how they managed it. This is probably what I’m most looking forward to as I’m also hoping that this kicks off a greater level of process around code-review, code-quality and standards.

Out-reach

As I found last year people aren’t going to be able to contribute and be interested in what I’m doing unless I talk about it. Obviously the blog is a big part of this – and already I’ve hit the 50% mark in equaling my post total from last year but I’m trying to also be picky with the conferences I go to. I’m still at my most comfortable when in a pub with a pint talking about our Mozilla projects so I’m aiming to go to things with a lot of interested, or potentially interested folk with the skills we’re looking for that can help us out, or can show us how to be better.

I’ve got a pretty good schedule of events lined up so far, so if you want to chat about what we’re up to please come and say hello.

And finally…

Let this be my stick in the sand while 2013 is still really getting going. I hope at the end of the year I can say that I’ve met my years work goal of:

“Trying to focus more on quality opposed to just getting shit done – quality of code, experience, accessibility and the ability for potential contributors to pick up and run/contribute to what we’re doing”

If it looks like I’m not getting there please kick me.

• has produced numerous projects that have since become core components to the Mozilla Foundations work efforts,
• helped us run international events in Barcalona and London,
• lead numerous community events worldwide.

We wanted a platform where people could let people could tell the world about their web projects, have the community help them out and have them made better. We received loads, with some of my favourites being:

• popcorn.js
• the Mozilla Journalism project
• Hackasaurus
• Universal Subtitles
• The New Social Web Project
• Social Book Publishing
• Peer to Peer University
• the Open Badges Initiative

These are all amazing projects but you might have noticed one thing – they’ve all now outgrown what we provide at drumbeat.org. They have their own websites and twitter streams with some having their code posted on github for community involvement.

Now we have these tools and sites we’re looking at moving our focus from being a community of web builders to a community of web makers who will use the tools that we have previously made. We think it’s time that we let it relax in a warm chair by the fire with its’ coat and slippers and remember the good old days and gaze lovingly at what the things that it has created go on to become. Last year when we carried out a survey on how we could evolve drumbeat.org and discovered the two main reasons we found on why people were signing up was to hear about what Mozilla are up to and to contribute to an existing drumbeat project. Thankfully our plans for drumbeat.org will allow people to continue doing that.

So what does this mean for you?

On March 1st we will be turning off new site registrations, new projects and existing project content updates; recently the number of new projects coming in has dwindled and project updates have contained large amounts of spam anyways.

drumbeat.org will remain live but will be used to direct people to our site for web makers (URL to be decided) and provide access to the now external websites of our major drumbeat projects. It will be used to tell the story of what it created and what Mozilla are doing with those creations.

What about my project page?

On March 1st your project page will be turned off and redirect users to the homepage (drumbeat.org). If you let us know we can set up redirects from your project page to your new web presence so to not loose any SEO-juice you’ve built up. Please contact us or leave a comment below and provide the drumbeat URL and where you would like us to point that to. Using Hackasaurus as an example that would be https://drumbeat.org/en-US/projects/hackasaurus/ and http://hackasaurus.org

What can I do to keep my project alive?

As mentioned above if you’ve already set up an external project website it will be fine. Up to March 1st you may also use our site messaging system to message your followers of your plans. If not then there are numerous online tools that are free and can be used to keep people informed.

Project updates

Set up a project blog! There are many free options out there, some we would recommend are tumblr, blogger or wordpress.

If you’re looking for more short-hand options then creating a twitter feed, status.net stream or a hash tag for people to message at should be able to be integrated into your chosen blog easily.

Code updates

If you want people to be able to download, use, alter and potentially improve your code and you haven’t already then we recommend getting into an online code repository. This also comes with the benefit of your code being stored in the cloud and therefore safe from laptop failures.

The most popular is probably github.com but if you’re familiar with version control systems other than git there are google code (with gives you Subversion, Mercurial AND git) and bitbucket (which gives you git and Mercurial).

So what does this mean for drumbeat?

We feel that drumbeat has been a huge success, the projects that it has made, the community that it has created and the people that it has put as into contact with. In 2012 we’re so excited to see how this community can help us more forward and make the next generation of web makers. You can read more about our our future plans over at http://openmatt.wordpress.com/2012/02/16/byebyedrumbeat/

We will also be blogging more about where we will be taking the Mozilla Foundation online presence. We’ll be doing it in iterations and in the open so feedback is always welcome. Keep your eyes posted on our RSS feeds for further information.

We’re looking to recruit this week (14th March 2012) – watch this space!

At the moment I’m the only developer on my team at Mozilla, in fact I’m the only person in my team. I am “Team Ross”. Thankfully in March this will change, we’ve already hired a designer and we’re looking to add at least another developer to work on supporting the Mozilla Foundations work, events and communities.

If that’s already got you wanting to apply then please have a read of the job spec and get your application in – http://careers.mozilla.org/en-US/position/oIkXVfwE. If you’re looking for more information please read on…

What will I be working on?

Short answer – lots!

Detailed answer – just this week we’ve launched a the new Knight-Mozilla Open News partnership. The site right now is pretty basic and there are tons of improvements that need to be made. We want to do something around our events platform, including getting an events platform; you can read more about that through the thoughts of Ben Simon on the infrastructure of self-organising and Michelle Thorne on potential feature requests for web makers (trying to crowd source what things we might initially need). Mozilla are running a partnership with the National Science Foundation, Geni, Ignite and the White House called Mozilla Ignite so there is work to be done on that site as we build out the feature set there. Then there is the Mozilla Festival… So yeah, we’ll make sure you don’t get bored.

“Team Ross” as it currently stands (or sits) – come make it a proper team!

Of course all of your work will happen in the open – your code will be on github, our dev servers will have public access as will our bug tracking systems and wikis. I’ve found this a really exciting part of the job so far and it’s certainly not as scarey as you think it might be – people when commenting on your code are helping you make it better and there is a global knowledge base to tap into.

What technology will I be using?

Mozilla are a web company so everything will be based around HTML5. Server side we’ve got projects running on Django (using Mozilla Playdoh), nodejs and wordpress. We’re not tied to one technology and decide on a project by project basis what is the best fit in terms of what’s most useful for the client and can produce the best experience for our end users.

Where can I work from?

Mozilla have, or soon will have offices in 9 locations worldwide but also are very open to remote working. So where ever you are reading this from if you think you’re a good fit then please apply!. London will have it’s office opening in the next month or so, I’ve been in, it’s looking great and has a good location in Covent Garden; it will also come with it’s own bar!

So where do I apply?

As mentioned above you can apply (don’t forget to include a github/bitbucket/googlecode URL) at http://careers.mozilla.org/en-US/position/oIkXVfwE

Any further questions then please ask in the comments.

The slides

The links

Organisation

• JS Lint – the official site
• Crockford Facts
• Essential JavaScript and jQuery design patterns – FREE BOOK
• requireJS
• A thread on amsuing thread on ‘best code comments’
• JSDocToolkit – project page on Google code
• Documentation-Driven Design for APIs by Frances Berriman on 24ways.org

I like running jsLint as part of my build process, and it’s actually pretty easy. If you’re using the HTML5 boiler plate it’s built into that and if you’re a git user you can install which runs it against your JS on each include and warns you of any problems – git pre-commit.

Performance

• The Mysteries of JavaScript Fu by Dan Webb
• Event delegation with jQuery by Brandon Aron
• Writing Efficient JavaScript by Mark ‘Tarquin’ Wilton-Jones on dev.Opera

Don’t forget your accessibility

• Making AJAX work with screen-readers
• WAI ARIA live regions on Mozilla Developer Center

In a nutshell a load of CSS modules had been concatenated into one file leading to quite a large number of selectors being used. He found that after a certain point (4096 selectors) IE would ignore everything after it. I had never heard of this before and from reading some comments I got on Twitter a few other folk hadn’t either…

My boss found this online which would hint to it being this being true – http://msdn.microsoft.com/en-us/library/aa358796%28VS.85%29.aspx but this being a DOM method I wanted to make sure the same went for the CSS parser.

After a chat with Stuart Langridge (who provided me with a useful python script to make the file) I have a use case and confirm this bug does indeed exist in IE – even in IE8.

Scroll down to the bottom of this iFrame (make sure you’re using IE) and you’ll see the final 5 ‘OK’s are in the default of black and not red as they should be styled! If you’re not a fan of iFrames it’s also availiable as an external link – IE 4096 selector usecase.

In additional news IE will also bork when presented with more than 32 @import statements (http://www.agum.com/web/2008/03/11/internet-explorer-issue-maximum-of-32-css-import/) so in many ways if you have a shed load of CSS you’re damned if you do and damned if you don’t!