Mark Ledford's Web Dev Blog

can be found at MobileXWeb. With the usual major features I found some less noted but notable features/issues, some of which I’ve already run into with development:

• there is no way to detect the user is on an iPhone5 explicitly you have to check screen height

You can check for the iOS version and Mobile Safari version but not the device version. I also noticed an app saved to your homescreen via bookmark does not return safari version in navigator.userAgent.

• The ‘Take Photo or Video’ upload option won’t appear if you set the ‘multiple’ attribute on your file input for html5 uploads
• There is a new undocumented metatag ‘apple-mobile-web-app-title’ to declare your homescreen title when your web app is save to the homescreen
• The Javascript engine in in Web View (PhoneGap/Cordova apps, embedded browsers) runs 3.3x slower then the new Safari App.

This is a little alarming. It sounds like Web View has not been getting any of the Javascript engine optimizations Safari has been getting.

• iOS 6 is available as a free update for every iOS 5 device but not the iPad first generation so the iPad market is being fragmented for the first time
• ios6 gets requestAnimationFrame for optimized animations
• Chromeless webapps (using the apple-mobile-web-app-capable meta tag) now have their own storage sandbox.
• Remote Web Inspector for webapp debugging works in Phonegap apps but is not available on Windows as it requires Safari 6
• WebView: A new supressesIncrementalRendering Boolean attribute that can eliminate the partial rendering mechanism

Interesting, will have to experiment with this one.

• Mutation Observers from DOM4 are now implemented. You can catch a change in the DOM using the WebKitMutationObserver constructor

FYI here are some nice notes on new web features available to iphones / ipads now that ios6 has been released. Of note is native file uploading is finally available in html web apps without relying on phonegap/native. Also “Smart Banners” that indicate to the mobile safari user that there is a native app that will take the user directly to the app store

Remote debugging on IOS6 is beautiful. Just connect your device to your computer and go to IOS Settings > Safari > Advance > and switch Web Inpsector toggle to ON. You’ll be able to initiate a desktop safari Web Inspector session (via Desktop Safari > File Menu > Develop > Device Name) complete with live DOM interaction. Its very snappy and will help speed up development compared to the janky 3rd party remote debuggers I’ve been using like Weinre.

This Chrome support ticket points to a browser bug in the Chrome Browser itself to be the likely culprit.

Recent versions of Chrome exhibit the curious behavior of only preloading HTML5 <audio> files in 2MBish chunks, requesting the next chunk only when you are playing back the current chunk it has preloaded. This sounds like a smart optimization for network traffic, etc, but exacerbates and is likely related to the issue of stalling and failling-to-fully-load mp3s.

At its core the issue appears to be with network connections timing out and not being able to resume downloading chunks once they have timed out but curiously the audio often cuts out long before the preloaded marker is reached.

Here is a test player loading 8 mp3s

And another with only 1 mp3

I am using MediaElement.js styled audio players here so you can see the preloaded percent of the bar in blue. With even the single player I was able to reproduce issues with playback permanently stalling, especially after leaving the files partially preloaded for 5-10 minutes.
Hopefully Chrome will push out a fix for this in their next 6 week silent browser update. In the meantime, I’ll dig around for a solution. An annoying possible fix that comes to mind is to not render your player until you are ready to autoplay it. Also using an audio library that you can force to fallback to Flash for Chrome is an option.

Mainly some notes for myself:
* utilizes HTTP Pipelining (Sends multiple requests on the same connection) to avoid round trip delays on servers that support them
* GPU accelerated rendering (for CSS transitions and such)
* “async” attribute for scripts now supported
* Loading of CSS scripts are now blocking
* HTML5 Web workers support
* CSS position: fixed
* CSS overflow: scroll (-webkit-overflow-scrolling: touch;)
* Still no browser based file upload (input type=”file”)
* new input types: date, datetime, month, time, range
* new EcmaScript 5 stuff

iOS5 seams to have broken functionality in our HTML5 mobile webapp. Requesting audio media assets are currently failing 1 out of 2 times with one of two errors:

The operation couldn’t be completed. (NSURLErrorDomain error – 1013.)
The operation could not be completed

After much research I’ve come to the conclusion that our authenticated media host is having issues with the updated HTTP Request behavior in iOS5′s version of mobile Safari. iOS5 now uses its own flavor of HTTP Pipelining to speed up data transfer and my theory is somewhere along the line our host’s web server is disagreeing with it.

Since mobile networks usually have very high latency HTTP Pipelining allows the HTTP client to avoid round trips to the server by send multiple requests on the same connection without waiting for the server to respond. You can read up on iOS5′s version of HTTP Pipelining and the concept in general here:
http://www.blaze.io/mobile/ios5-top10-performance-changes/
http://www.blaze.io/mobile/http-pipelining-big-in-mobile/

We’ll be reaching out to our media content provider today to validate but I figured I would throw up a place for others experiencing the same issue to discuss as I am not seeing other posts about it yet.

Building javascript heavy webapps using html5 and css3 is tough when you have old but still stubbornly popular Internet Explorer browsers to support. The solution: Chrome Frame

In Google’s words:

Google Chrome Frame is an open source plug-in that seamlessly brings Google Chrome’s open web technologies and speedy JavaScript engine to Internet Explorer.

In my words: Hello IE 6 render my shit automagically using Chrome.

Once installed, this meta tag in your html will tell IE to use Chrome’s engine to render the document:

Don’t have Chrome Frame installed yet? These few lines of condition IE logic will check and prompt:

Chrome Frame is installed at the user level if the user does not have admin access (Win!). The documentation states a restart isn’t even necessary once installed but I’ve found in my tests that the browser does need to be fully restarted so I’ve included a post-install alert specifying so in my code.

Forcing a user to install a plug-in to see content is usually a no-no but when it comes to all-or-nothing HTML5 CSS3 webapps that need to span all browsers an devices with a single codebase sometimes those IE6 users can use a little prodding. To clarify, Chrome the web browser does not have to be installed beforehand and installing the plug-in does not install the Chrome browser. Chrome Frame’s name is a bit of a misnomer as the structure of your document is not modified and no DOM frame is used–everything is just rendered beautifully even in IE6 using Chrome’s versions of the WebKit layout engine and V8 JavaScript engine via the IE plugin.

If your videos are not loading in Firefox with a 206 Partial Content check the Content Type returned in the response header for the file. If it reads text/plain your server isn’t passing the MIME type of the video. You should be able to create a .htaccess file in your video directory to fill in the missing MIME types. For example include this:

AddType video/ogg ogg
AddType video/webm webm

For WebM support you can download the installer here.

For OGG dowload XiphQT.component from here and put it in your /Library/Components folder

Its worth noting that this will also add Webm and Ogg support to the html5 video tag in Safari.

If you haven’t installed Mac OSX Lion yet I would probably wait. So far I’m finding it:
- Breaks encoded audio over hdmi (Can’t listen to movies with AC3 Audio through HDMI when using as a HTPC via VLC)
- Gets stuck in a mode where it won’t let me copy and paste files in Finder until I restart Finder (file is pasted then immediately disappears)
- and now I find out its even made the Flash Settings menu unclickable effectively breaking every site utilizing flash’s camera permission dialogue among other things (https://bugbase.adobe.com/index.cfm?event=bug&id=2918693)
Luckily its been fixed in an update that just came out, Flash Player 10.3.183.5. Its interesting to note that Flash Player now has its own icon in the OS System Preferences.

Other things I’m not a fan of:
- Minimizes the use of scrollbars to the point where you can’t tell if you have scrollable content unless you try to scroll
- Greyscales all Finder’s color icons in the left side toolbox so you can’t tell them apart without looking at them closely
- Puts your hard drives last in the order stuff on the left hand so its often not even on the screen (apparently you can’t even change this)
- never closes files automatically in Quicktime, so as you open videos and command-q the app they just pile up forever.
For the quicktime weirdness, you can type this in Terminal to permanently disable the “resume” feature:
defaults write com.apple.QuickTimePlayerX NSQuitAlwaysKeepsWindows -bool false

Webkit has extended their css3 gradient options with -webkit-linear-gradient which uses the standard “gradient rotation” value found in Mozilla’s -moz-linear-gradient but unfortunately this is only supported in Safari 5.1+ and Chrome 10+. Until Safari 5.1 becomes the norm any programmatic references to gradient rotation have to be converted from the typical 360 based rotation value to Webkit’s powerful but awkward (powerfully akward?)  -webkit-gradient point syntax where your linear gradient’s start and end values have to be defined as X,Y value pairs that explicitly state at what point the gradient starts and ends.

For a linear right-to-left gradient you could define percentage points like so:
-webkit-gradient(linear, 0% 50%, 100% 50%, color-stop(0, rgba(80,80,80,1)), color-stop(1, rgba(80,80,80,0.5)));
Which reads “start the gradient at wherever “0% width and 50% height” is and end the gradient at “100% width and 50% height”.

This is easy enough to calculate by hand but if you have a project with a ton of regular gradient rotation styles already defined you’re going to need to convert via javascript and some Trigonometry which is the situation I was in. A bit of googling turned up no clear cut method of converting a gradient rotation value to a pair of percentage based X and Y values so here is what I came up with. First the code:

//webkit has updated syntax from -webkit-gradient to a much more sensible -webkit-linear-gradient with angle but
//this is only supported in Safari 5.1+ nd Chrome 10+ so we’ll have to do the math to convert gradient rotation to
//start and end points on a circle
var gradientRotation = 0 – (node.gradientRotation%360);
var centerPoint = {x:0, y:0};
var rotatedStartPoint = KickUtils.pointOnCircle(50, 180-gradientRotation, centerPoint);
var rotatedEndPoint = KickUtils.pointOnCircle(50, 360-gradientRotation, centerPoint);
rotatedStartPoint.x = Math.round(rotatedStartPoint.x+50);
rotatedStartPoint.y = Math.round(rotatedStartPoint.y+50);
rotatedEndPoint.x = Math.round(rotatedEndPoint.x+50);
rotatedEndPoint.y = Math.round(rotatedEndPoint.y+50);
return ‘background-image: -webkit-gradient(linear, ‘ + rotatedStartPoint.x+’% ‘+rotatedStartPoint.y+’%, ‘+rotatedEndPoint.x+”% “+rotatedEndPoint.y+’%, color-stop(0, …

Since a numeric gradient rotation value defines a gradient that passes through the center of a circle, you can use the trig function above to calculate the 2 points that line intersects the radius of the circle. Defining the center of the circle at 50, 50 you can get values returned in the -50 to +50 range. Add 50 to that value and tack on a % and voila your 2 percentage based points start and end values are defined.