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.
So there you have it, your lovely new navigation bar. The trouble is, you want the text to be bold on hover, but you also need your elements to be fluid with. This creates the problem of the buttons changing width when hovered on, because of the change in font weight.
The way around this is to simulate our font weight with text shadow instead. Text shadow declarations do not affect the box model, so your elements won’t change in size when hovered on.
To see an example of this working, click here to see a jsfiddle.
If you’re working on a project that involves any sort of geolocation, distance plotting or such like – you’ll probably need to do this. But calculating a distance between A and B is not as straight forward as you’d think, primarily because Earth is not flat. Neither is it a perfect globe. Therefore, you need to take this into account when plotting distances between two points on Earth.
We do this using something called the Haversine formula. This formula allows you to take two co-ordinates on a globe and plot the distance between them.
where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km), note that angles need to be in radians to pass to trig functions!
The main drawback of the Haversine formula is it assumes Earth is perfectly spherical, when really it’s not. In fact, Earth is slightly ellipsoidal, but even taking this into account the error deviation is at most 0.03%, so for most purposes the Haversine is accurate enough. It’s also worth baring in mind Haversine is “as the crow flies” – so it does not take into account hills, mountains, canyons etc that may actually add to the length of the distance.
So how do we turn this formula into usable code? Using PHP, we take five variables. We need the latitude and longitude of point A and point B as well as Earth’s radius, which is 3959 miles.
We input them into a function which converts the degree co-ordinates into formula-friendly radians, and then inputs them into the Haversine formula, exactly as you see it above.
I’ve been waiting so long for date time input type implementation, and Chrome desktop has it. But frankly, the implementation is terrible, from the point of view of usability, as well as being pretty ugly.
With the date field, you get three controls. Unfortunately, they’re all tiny and quite fiddly, and whilst the button to bring up the date picker is fairly self-explanatory, the up/down controls are a little more ambiguous. The function of the field is also not in line with traditional date pickers, when clicking the field you would expect the picker to appear, but it only appears when you click the drop down. This may mean many users simply never even realise it exists.
The styling of it all is pretty ugly too, which surprises me. For example whilst the up/down controls have a gloss look consistent with other form controls in Chrome, the drop down button is a flat down arrow with no button styling at all. The date picker is the worst part, it’s far too small and has some strange styling, for example a blue border around each month.
There’s also a button with a dot, who’s function is not immediately clear. It turns out clicking it puts into the field the current today’s date.
The time field is also quite difficult to use, for example much like in the date field you have to manually move between each part (hours to minutes) either with your mouse or arrow keys. Granted there’s not really another way to handle this, but I would imagine most people will be switching between mouse and keyboard which makes it feel clunky.
In my honest opinion, the usability of the date field would be massively improved if the date picker was larger and better styled, and displayed automatically when selecting the field. I also think the time field would work better if it also displayed a picker – perhaps one that works similar to those on mobile devices.
Your initial reaction to this is possibly a “whoa, you crazy fool!” But in all honesty, I think the time has come to drop support for IE8. By doing so, I’m following in the footsteps of many others, including the agency Zurb.
But why? Simply because IE8 usage is dropping off very fast, and the trend is a downwards spiral. Last year, I dropped IE7 support when IE7 usage was hovering at about the same point IE8 usage is now. Now, IE7 is pretty much finished.
A quick look at worldwide browser stats gives compelling evidence, IE8 usage is only three percentage points above IE10, which has doubled in just one month. By that trend, we can expect IE10 to have eclipsed IE8 usage within the next two months.
Of course, you shouldn’t go purely on global stats, you should also look at the stats specific to your site. But those paint an even more damning picture, out of 1200 visits in the last month to our main website, only a meagre 84 were IE8. In comparison, about 300 visits were from mobile devices, making the case for responsive design more compelling and justified than ever.
The time has therefore come in my mind to say goodbye to IE8. Hasta la vista, baby.
Purely just for fun, I’ve put up an Instagram app I made.
This is a fun little page that grabs all your photos and arranges them on a grid. You can then re-arrange the photos by changing the filter you used in Instagram. It’s incredibly light weight – just 117kb.
It’s responsive, and on desktops you can enlarge the pictures. It uses Quicksand.js.
Do what you want with it but if you do use it, show me. If you’re comfortable with the code you can change it, or if you think the code needs to change, change it.
Wondering why your lovely jQuery UI autocomplete isn’t working in IE10 Mobile? In fact, no jQueryUI widgets work properly out of the box with IE10 Mobile, or for that matter IE10 on Windows 8 when used on a touch device.
The problem is that IE10s touch events conflict with jQuery UIs touch events. Handily, Microsoft have provided a very simple CSS declaration you can use to remove the inbuilt IE10 touch events, and therefore this removes the conflict and your UI widgets should all work.
Stick the following in your stylesheet and it should fix the problem:
So how do you use it? This assumes you’re using more than one marker on your map. If you’re only using a single marker, refer to the link above. The first thing you want to do is stick in the options code for the box.
“boxText.style.cssText” defines our styling for the box. You could do this in your external CSS file if you prefer. The rest of the options should be fairly self-explanatory. As you’re plotting more than one marker, I’m assuming you’re using a loop. So you need to now incorporate your infobox into the loop.
After you have defined your marker (e.g. “marker = new google.maps.Marker”) you’ll want to attach an event listener. This simply tells the browser what to do when the user clicks on the marker. So you want your infobox here.
The “boxText.innerHTML” declaration simply defines what content is displayed inside each box. Because you’re looping through markers, you’ll want the correct content for each marker, not the same. Therefore, you should store your information in an array, in this case the array is called “markerinfo”. The “[i]” then simply increments which part of the array is used as the code loops.
That should basically be it. Remember, this post is for Maps APIv3 code that involves looping through multiple markers. If you’re only displaying one marker, or you’re not looping, your code may need to be different.