Most popular articles from 2015

I know March seems like an unusual time to do a roundup of last year, as we’re already 2 months into 2016, but I was recently encouraged to do a roundup of all articles on my OngoingWorlds blog, so thought it wasn’t too late to do it for this blog too. So here’s the most viewed articles I wrote in 2015:

  1. I’ve finished a game but too embarrassed to show it anyone because it’s about a giant turd
  2. Exporting a sprite sheet from Flash into Unity animation
  3. So I’m uploading something to the Google Play store
  4. My CSS layout – group by component, not by screen-size
  5. I use BEM – A good clear naming convention
  6. Chrome pulls Unity plugin
  7. My opinions on using or not using Bootstrap
  8. My favourite CSS comment style
  9. How long before we get cool curved desktop screens like this one from Black Mirror?
  10. A vertical-align mixin that changed my life

Also, I wrote this article about what I did in 2015.

jQuery – check if an element contains element

Forgive the jQuery! I’m just putting it here so I can find it again later 🙂

I’ve recently just had to create a menu in Foundation, in a CMS where I can’t change the menu markup (it just outputs lis and uls). So have had to use JavaScript to add the classes that Foundation needs to turn this into the slidey mobile menu. It feels like a horrible hack I know, but there’s no better way – and the Foundation menu needs JavaScript to display anyway.

So I needed to add the .has-dropdown class to any li containing a ul, which I did with jQuery’s .has() function:

//-- Add Foundation dropdown classes to subnav (so mobile nav works)
$("#main-nav li").has("ul").addClass("has-dropdown");
$("#main-nav li ul").addClass("dropdown");

The internet, a living graveyard

I stumbled across the blog today of Alex King, who wrote an article titled “We’ve made web development complicated” (see it here), which is something I’ve been thinking about recently (I also wrote a blog article about it called “Editing websites has never been more time-consuming” (see that here).

The most interesting thing about Alex’s blog though is that, well, he’s dead. Continue reading The internet, a living graveyard

Particles in Unity appearing in front of mesh

I had a weird bug in Unity today where particles that are supposed to be in the background were actually appearing in front of meshes that are closer to the camera.

After quite a lot of searching, the solution is actually simple, but wasn’t obvious so I thought I’d write it here.

So my particles are exactly where they are supposed to be, behind the land mesh. But are appearing in front (see image above).

Unity particles behind mesh

This is actually caused by the particles being scaled. I first found out about it from this thread on Unity Answers, linking to this forum post about it.

If I set the particles’ scale to 1, it resolves itself. I thought I’d have to muck about with sorting orders or layers (still not got to grips with those in Unity yet. Doesn’t seem to change anything to me).

6 reasons why I still prefer Bootstrap to Foundation

bootstrap vs Foundation

The versions I’m comparing are Bootstrap 3, and Foundation 5. Although I’m aware Foundation 6 has recently been released, which makes up for some of the shortcomings in this article – which is better late than never! But I’m still locked into Foundation 5 for many projects.

Bootstrap 3 has sliding animations out of the box

Both Foundation and Bootstrap have accordion components that expand and collapse. But only Bootstrap’s animate nicely out of the box. You can probably change this in Foundation but it’d involve rewriting the component – which is annoying when I’d rather have it working the best way possible right out of the box (that’s why we use frameworks right?!).

Same problem with the navbar. Bootstrap’s mobile nav slides down nicely, allowing you to see where it appears from. Foundation’s just appears and overlays the content, which is sometimes surprising.

I’m glad to see the new Foundation 6 does have an animated slidey accordion and navbar.

Foundation’s config variables

Foundation is very customisable, which is great! And in some ways it’s better than Bootstrap because you can change the look and feel of a component without having to override it’s basic styles.

The way it does this is by using config variables, and plenty of them! Each component has at least 10 variables, about sizing, fonts, colours, background colours etc, which when you compile all your SASS will style the component as you need. Without having to override any styles (and overriding some of Foundation’s styles is a horrible battle of specificity!).

Problem is – you’ve got to figure out what variables there are, what each do, and type them our (or copy & paste), which is more time consuming than writing CSS, because I’ve got CSS styles committed to memory, not Foundation’s arbitrary variable names.

It’s a good idea, but sometimes it’s faster to write normal css.

Bootstrap has glyphicons

I use Bootstrap’s glyphicons all the time. In my Foundation projects I’ve been using FontAwesome, which is great, but it’s nice to have decent icons built-in.

Foundation’s installation process

The tutorial for installing Foundation uses commandline functions to get it installed. Maybe if you’re used to using commandline all the time, you’ll see the advantage in this. But for a light user like me, I feel much more comfortable copying and pasting files into the correct directories.

The ability to @extend more stuff

I use @extend all the time, and find it useful to extend the styles of a class into another. But many places I’ve found in Foundation this errors, for example I was trying to @extend the .show-for-sr class into a new class that did the same thing and more, so that I didn’t have to type out all the styles (SASS will also smush these together in the css for optimisation), but this didn’t work in Foundation because of how these styles are written. Whereas extending .sr-only in Bootstrap is easy.

By default Foundation looks like ass

So out of the box, Foundation looks quite basic, and Bootstrap looks… well… like Bootstrap. This isn’t really a problem which is why I left it til last. There’s a very valid argument that a framework shouldn’t make your site look like anything – and you don’t have to look very far to see the impact Bootstrap has had on the web – many websites that all look the same!

Foundation is deliberately basic so you can apply your own styles, although I quite enjoy working on a site that looks nice right from the start.

All this being said…

…Foundation is decent, and I still think it’s much better to work with a framework than no framework. It does also have some cool things that Bootstrap doesn’t, like Joyride built in (although I’ve not used it yet), and Equalizer, a bit of JavaScript that makes all columns the same height – something that’s been an annoyance in CSS for so many years! (although has been finally fixed with Flexbox).

How I’d make English better


I saw today that there’s some proposed French spelling changes, and it made me think we should do the same for the English language too, which is riddled with inconsistencies and unnecessary letters that create bizarre exceptions that need to be learned.

Here’s what I’d change:

  • Remove that pointless first “d” from “wednesday”, and the first “r” in february.
  • C at the start of any word should be replace with a k (unless it’s followed like a h, like “church”). Making “kool”, “krafty”, “krust” the same as the “k” in “kangaroo”.
  • Remove all silent ks, as in “knight” because it’s pointless. If people wanted to differentiate “knight” from “night” written down, they shouldn’t have used the same word to begin with!
  • Remove pointless silent gs from “gnaw” and “gnat”, they’re not needed.
  • Any w before an “r” at the start of a word is unnecessary too. “Wrap”, “wrinkle” and “wrist” would still make sense without it.
  • Replace any “x” at the start of a word with “z” as in zebra. Because z is cool and doesn’t get used enough.
  • Actually we can make use of z more, for example the word “lose” doesn’t seem to follow normal rules (it’s nothing like the similarly spelled ‘dose’ for example). So maybe we should spell it ‘looze’.
  • We pronounce a z in “organise” and “normalise”, so we might as well spell it that way.
  • Remove the unnecessary “ue” from the end of “dialogue”, “monologue” and “analogue”. I actually agree with Americans on this. Also on simplifying “doughnut” to “donut”.

Just think of all those letters we’re omitting. If everyone adhered to this in every email and Facebook statuses, just think how many bytes we’d save on the internet! It’s like adding our own level of compression 😀