Michael Gunner

Michael Gunner

© 2014 Michael Gunner. All rights reserved.

the trials and tribulations of a middle-weight front-end developer and designer, topics covered include HTML, CSS, JavaScript/jQuery, WordPress & general rantings

  1. VH in old OSX Safari

    September 17, 2014 — Leave a Comment

    So now we know a new way to achieve 100% height, we need to get it working properly in all browsers. Unfortunately, Safari in particular has a very buggy implementation of VH. On iOS, this is a fairly easy thing to fix with this handy “buggyfill”:

    https://github.com/rodneyrehm/viewport-units-buggyfill

    But in older versions of OSX Safari, the buggyfill does not work. Safari will also actually parse your vh as if it supports the unit – but doesn’t actually apply the value correctly. I tried getting around this with min-height, but unfortunately older Safari has a problem with that too.

    In the end, I had to use a JS hack to identify old versions of Safari, and then re-define the height of the element. It’s really hacky but it was the only way I could get it to work. My problem was only in Safari up to 6.1. If anyone knows a better way to fix this issue please do share.

  2. The new way to achieve a 100% height element

    September 16, 2014 — 1 Comment

    We’ve all needed to do it – make an element stretch to the height and width of any browser windows. It’s something we’ve long been able to achieve using a common method, the one you will see touted everywhere on Google, and thus probably the one you will use.

    This is a good solution, but it has a pretty fatal flaw – it will break anything where you are using the height of the document. An example of this would be a progress bar which animates when the user scrolls. Because you’ve set the height of the document to be 100%, it will calculate incorrectly. This will also make any animate on scroll functionality work incorrectly.

    But there is a solution to this. It involves the use of the new viewport CSS units. Instead of setting any height at all on your html and body elements, you simply specify 100vh height on the element you need to stretch to the viewport height.

    So now you just need:

    You now have your element, at 100% height of the browser – but maintaining the document lengths, so your scroll on functionality will work correctly. Do bear in mind of course browser support, however it is pretty good and all modern browsers will work fine: http://caniuse.com/#feat=viewport-units.

    For iOS7 support, there is a fix: https://github.com/rodneyrehm/viewport-units-buggyfill

  3. I wish IE8 would die

    It’s hovering stubbornly at the 6% level. If you use IE8, you really need to be using at minimum IE9 now. Otherwise many websites you visit may not work as they should.

  4. Smooth scrollTo with variable offsets

    March 5, 2014 — Leave a Comment

    In the era of the one page site, smooth scrollTo is used everywhere. We commonly use offsets in our code to account for the vertical height of a navigation bar. However, there may be occasions where we need a different offset, depending on the link we’re clicking.

    So instead of hard coding the offset into the jQuery, we can use custom data attributes to specify an offset for each link. So in our code we use:

    And we attach the attribute to our link:

    So in this instance, our offset will be 40.

    It’s a small snippet but something I thought worth sharing.

  5. Simple Foundation 5 SASS setup

    February 16, 2014 — Leave a Comment

    Here’s my simple Foundation 5 (the framework) SASS (the preprocessor) setup. There’s many other ways of setting up your development environment locally, but for me this is what I’m doing at the moment and it works really well.

    You need to install:

    • Ruby
    • GIT
    • NodeJS
    • Grunt

    Once you’ve got those installed, open up your Node command line and enter:

    Bower is the package manager Foundation uses to update. After you’ve done that, open up the Ruby command line and enter:

     

    Next step is to create your project folder, wherever you keep your web projects. After that, open up Ruby command line again and type CD then the path to your project folder. An easy shortcut to typing in the path, is to drag your project folder onto the command line after having typed CD. Hit enter.

    Now to run Foundation in your project, type:

    “project_name” is the name of your project so just replace that with whatever you want. Next, run this command:

    And you’re ready to start!

    I suggest always using Grunt to compile your SASS, so before you start working open up the Node command line, CD to your project folder, and run this command:

    Now, any changes you make to the SASS files will compile automatically. You could then use this in conjunction with LiveReload, so you don’t even have to refresh the browser to see your changes.

    You can find more documentation on the Foundation website: http://foundation.zurb.com/docs/sass.html

  6. Graphic design for my partners daughter’s 1st birthday

    October 21, 2013 — Leave a Comment

    On October 10th my girlfriends daughter turned one, and on the 13th we celebrated by throwing an enormous party – Filipino style. I helped my girlfriend arrange the party and my favourite contribution was the graphic design I did. I designed the invites as well as various printed materials, and I also hand made a black frame portrait for a picture of her daughter.

    I haven’t done much graphic design recently so for me this was a fun side project which I really enjoyed, and I was very happy with the results.

    rM1NZ61054179msQ26761054182mwlPrP61053773m8xmGT61054196mIMAG0655_1

    Some more pictures from the party:

    BHQ5961053876mBQpDM61053509mBtCsp61053630mDw9hY61054186mG1Pm261053657mG4HJr61053827mlWNYR61054192mm6ktD61054146mnh0Q161053940mnM7rL61053654mpQ3b961053955m

  7. Is datetime-local desktop browser implementation user friendly?

    October 7, 2013 — Leave a Comment

    I really would love to get away from JavaScript widgets for entering and validating datetime inputs. HTML5’s datetime-local (which for all intents and purposes is the replacement for datetime) seems to be the solution, but whilst the controls on mobiles are superb, I have reservations about the widget controls that Chrome on desktop renders.

    This is mainly because the widget only works for the date and not the time, which the user still has to manually enter on their keyboard. This leads to an experience which I feel is confusing, it doesn’t feel intuitive. A widget should exist to allow the user to be able to fill in the input without their keyboard – otherwise what is the point?

    Clicking in the field also does not automatically bring up the widget. I understand why – but this goes against the behaviour of all other JavaScript widgets out there which could confuse users expecting to see the widget appear.

    So – I’d really like some feedback and thought on this. Are my concerns justified? Do you also feel the Chrome desktop widget is confusing and unintuitive – or do you feel the opposite?

    Try it out below (Chrome desktop only):

  8. Datetime switched to datetime-local

    If you have been, or were planning to, using input type datetime then stop. Datetime is becoming obsolete with Safari and Chrome both dropping their support. This is in favour of datetime-local instead.

    It should also be noted that when wrapping input type datetime-local in a parent container (e.g. a fieldset) you should give the parent container a min-width of zero in order to retain full control over the width of the input.