Blog Archives oEmbed of codepen’s

To celebrate wordpress’s addition of allowing us to embed codepen’s into our posts I am going through my posts and moving all my examples and demos over to codepen and embedding them in my blog posts.

I’ll post a list of the posts as I do them here (with embed’s here as well!):

Progress Bar as Submit Button

Bootstrap and Affixed Nav for Mobile

Bootstrap and Affixed Nav for mobile.

Recently I have been working on a new website for my primary contract referrer, I decided to use Bootstrap 3.0 as my base and as an absolute necessity it should look nice on all platforms (even mobile). Note that I am part of this group that doesn’t believe that it should look the same on all browsers, platforms and screens, just that it looks nice.

My first issue was quite interesting as I found that my wonderful iPhone’s default browser doesn’t support position: fixed (See for more detail on this). This means that my nice affix plugin using navbar only worked on normal browsers and not on my iPhone. This I decided was not an acceptable solution, so I started googling, then I googled some more and came up fairly blank. Yes there were a couple of bit’s and pieces here and there that hinted it could be done, but nothing that hit all the targets of: Bootstrap 3.0 Affix Navbar.
So cobbling together some other answers I came up with this: (or for without the code frames).

Once you’ve had a look at the example keep reading for the full breakdown.


The concept is a combination of the affix plugin as it works normally, and on mobile (in this case smaller screens) we work around the position: fixed by absolutely positioning the navbar at the top all the time. Now this isn’t a perfect solution – I just didn’t want to use more javascript than necessary. You will notice that in the mobile version we do not affix to top when it scrolls down – it is always pinned to the top. My reasoning for this is that though it’s fine for a desktop site to show the menu only later when you’ve scrolled down, as a usability point I find that if I’m using a mobile it’s not to look at the pretty pictures – hence the most important thing on a mobile is navigation around the site. We put our contact us button in the menu so it’s easy to see and click all the time.


The demo has 2 main parts to it – the <header> and the <div id=”scroll-wrap”> parts. The HTML is basic, nothing fancy to see there we just place the header element then all our content inside the scroll-wrap element. In the CSS is where the fun starts. As you probably have heard – it’s a bad idea to try change how things are done via browser sniffing as IE 11 for one has started lying about what it is! So to embrace this I design my sites using modernizr and for size of screen rather than type of screen. On smaller screens – to target the iPhones in particular I use media queries to absolutely position the header and then the scroll-wrap for the remaining viewport area. We then use overflow: scroll to make this the scrollable area (Note the use of  -webkit-overflow-scrolling: touch this means the div scrolls nicely on my iPhone). Nice thing about this approach is that the menu stays “Fixed” at the top. If you are using this method do keep in mind that the screen is small – the bigger your fixed area the smaller the screen to read on I’d recommend not using up more than 10-15% of the screen height with fixed elements especially if you set user-scalable to no.

Last Words

Another thing I haven’t demoed here is using bootstraps scrollspy in this situation – a simple solution is to initialise it twice:  $(‘body’).scrollspy(); $(‘#scroll-wrap’).scrollspy();. Though not perfect it does get the effect to work as only one scroll event will fire depending on how the CSS has changed the scroll-wrap.

Admittedly this won’t suit everyone and for some if you are fine with an always absolutely positioned navbar (or similar) on smaller devices you won’t need any of this. For those of those it helps – do leave a message, it’s nice to know the views aren’t all spam-bots!!

Reference: For why browser detection is bad:

AngularJS drag ‘n’ drop re-order in ngRepeat

EDIT I’ve just got a github up for this here: I’ve fixed some of the bugs in the code and updated it to run on the 1.2.x angularjs codebase.

I’ve been busy on some small projects that I’ve been doing recently and a little problem I’ve had to overcome is the difficulty of doing drag ‘n’ drop reorders in an ngRepeat.

After looking around the web I came up with the following solution:

See the Pen AngularJS ngRepeat Drag n Drop by SimeonC (@SimeonC) on CodePen

How It Works

In short this works by starting with the ngRepeat code in angular.js. Which in itself is complex as you have to also copy over a bunch of functions that it uses that are hidden elsewhere in the codebase. Then you add all the lovely complexity of moving elements around – I decided to simplify this by limiting the movement within the list bounds and only do vertical re-ordering. I animate this by fiddling with the margins – creating a gap where the ‘dragged’ element is going to drop into and then using +/- margins to position the dragging element correctly. Also we add in classes for display purposes.

The last hurdle I had to overcome is to modify the ngRepeat element before our modified ngRepeat compiles the element, I did this with a second directive that executes before the ngRepeat and adds the event tags onto the element.