Now for something a bit off-topic. As a side project I handle a friend’s company’s website. He asked me to add a button that links to his facebook page and another button that opens the review form for his company’s google page.
Easy peasy. I made two images and embedded them in a link element:
As expected everything worked as expected. Not exactly rocket science.
Until I looked at the webpage in Mobile Safari. The two buttons were not showing up there. They were showing in Chrome for iOS but in Mobile Safari: no Facebook button, no Google button!
As it turned out the image filenames were the problem. Naming them “btn-facebook.png” and “btn-google.png” was triggering my Mobile Safari’s content blocker app!
The solution was really simple. Just renaming the image filenames did the trick:
Now the images are “hidden” from the content blocker and show up in Mobile Safari.
Recently I used CSS transitions to animate some images inside an UIWebView. Everything worked fine and the transitions where really smooth. I used the translate transition to move the images that where inside a div HTML element:
To move the images I created a CSS class that contained the transition:
This worked as expected. However, when the images moved, there was an ugly flicker. It turned out that this is caused by a CSS property call “backface-visibility”. Normally this is used, when you do 3D CSS transitions (e.g. 3D rotations). “backface-visibility” determines whether the backside of a HTML element is visible, when it is not facing the screen. As I am not doing any 3D transitions it should not matter how this property is set. Wrong. Obviously in Webkit Browsers it does matter. To fix the ugly flickering you have to add the following to the CSS class:
Recently I encountered a problem with the keyboard while displaying a HTML form inside a UIWebView: The HTML form was a simple form to ask the login credentials from a user. Nothing more than 2 text input fields and a submit button. When the user tapped on an input field the iOS Keyboard came up, as it should. But then, when the user tapped the submit button, the keyboard stayed in placed and was not dismissed. The normal behaviour would be that the keyboard would be dismissed as soon as the textfield loses it’s focus. But somehow this was not happening.
Then I found the solution to that problem. I turned out that the lingering keyboard was a UI design choice by Apple. The keyboard dismissal is disabled when you present your UIWebView using a modal ViewController with presentation style UIModalPresentationFormSheet!
The solution is quite simple: You have to override your ViewController’s disablesAutomaticKeyboardDismissal method: