HTML5, CSS3, jQuery, JSON, Responsive Design...

Android on ChromeOS - the revolution beigins?

Michael Brown  September 13 2014 12:49:34 AM
Despite what you might read from pro-Microsoft trolls in the various forums about how "ChromeOS needs an always-on internet connection",  the OS actually boasts a large (and increasing) number of offline-enabled apps.  Check out Google's own word processor and spreadsheet apps, for example.  You can edit speadsheets and documents locally, with not connection.  When ChromeOS does detect a connection, it syncs those changes up with your Google Drive, just as you'd expect.

Still, far too many Chrome Apps are little more than jumped-up URLs that really do nothing if you're not online.  The Evernote ChromeOS "app" is just such a beast.

But now there's an alternative.   You can now ... drum roll, please ... run the Android version of Evernote under ChromeOS! You can install it from the Chrome Web Store.

And here's how it looks on my Samsung Chromebook (the ARM-based 2013 model):

Android Evernote on ChromeOS

The good news is, that it works!  And it works off-line, unlike "Evernote Web" (which is still available as a separate, Chrome App, FYI).

The bad news:
  • It's slow in operation
  • The window is a fixed size and can't be maximised.   It remains at, what I guess is an "Android size".
  • The fonts are small and hard to read.  I could see no way of resizing them either.

Still, it's a start!  There's three other such apps: Vine, Duolingo and Sightwords.  But Evenote was the only one that I was already using (or had even heard of).

Note: you a need the full ChromeOS to get this to work.  It won't work on the Chrome browser for Windows, Mac or Linux.

See Chrome Owners Get Access to Android Apps (PCPro).

Responsive CSS Sprites

Michael Brown  May 4 2014 02:36:00 AM
On my earlier post Rocket your website speed with CSS sprites!, I showed (I hope!) how can really speed up your page load times by loading a single, combined sprite image instead of multiple individual images.  As I said at the near the end of that post, however, things get a little trickier when you have to take Responsive Web Design into consideration.

Let's examine the two pages again.  This time I've added a media query to them both.  The media query kicks in when your browser width drops below 700px, so you just need to drag the edge of your browser in to see the effect.  Or if in Firefox, use Ctrl->Shift->M (Command->Alt->M to call up the Responsive Design View.

Here's the CSS:

@media all and (max-width: 699px) {
     .flag {
             width: 32px;
             height: 21px;

All it does is set the elements to be half of their normal size.  Let's see how it works in the multiple img tag version first:

No probs there.  The flags all reset to half size, and the flags are shrunk down nicely with them.  No let's try the CSS prite version with the same media query code:

Woah!  What's going on here?  The flag div tags are resizing okay when I narrow the browser's width, but the sprite images aren't.  Suddenly, we have an abundance of Union Jacks!  That's because instead of resizing the images, the CSS code is cropping them instead.  So the Australian flag loses all its stars, and we're just left with the Union Jack at the top left.  (What's that at the back?  "That's actually an improvement", you say?  Well, you may have point there, but...)

So is there way that we can resize the sprite divs and have their images resize correctly too?  Yes, there is, but it takes little bit of work.  The only way that I could find to do it is to specify the image sizes as percentages instead of pixels.

Percentage for Sprites

For the calculations on how convert pixel values into percentages, I followed this Stack Overflow thread.  Particular thanks to vals, who got me most of the way there, although there were some errors in his calcs.  I posted my corrections (as ChillyPenguin) on the same thread.

First off, you have to add a new CSS attribute to your divs.  This is called background-size, and it has to be set as a percentage.  It takes X and Y values, and the percentage calculations go like this:
x percentage width = (total image width / display image width) x 100
y percentage width - (total image height / display image height) x 100

My combined flags image is 1110px wide by 799 px high.  My flags sizes (handily, all the same) are 64px wide by 42px high.  So the background-size values go like this:
x percentage width = (1110 / 64) x 100 = 1734.375%
y percentage width - (799 / 42) x 100 = 1902.380952%

Because all my flags are the same size, I can apply to background-size attribute to a flag class, which I add to all my flag divs:
.flag {
      display: inline-block;
      background: url('../images/sprite.png') no-repeat;
      width: 64px;
      height: 42px;
      background-size: 1734.375% 1902.380952%;

Now the hard bit: we have to reset the background-position attributes on all of the flags.  So here's the calcs for that:
x percentage pos = (x pixel pos / (total image width - display image width)) x 100
y percentage pos - (y pixel pos / (total image height - display image height)) x 100

So for my first flag, which is Afghanistan, my absolute background size looks like this:
.flag.flags-afghanistan {
      background-position: -5px -0px;

So the percentage calc for the x dimension goes.  Note that the negative x pixel position is converted to positive when you do the percentage calculation:
x percentage pos = (5 / (1110 - 64) x 100) = 0.4780114723%

The y percentage is zero in this case, because the pixel y position is also zero.  Here's the resulting background-position code:
.flag.flags-afghanistan {
      background-position: 0.4780114723% 0;

Phew!  Got there.  Repeat and rinse for all the other flags, and here's the result: fully responsive sprite images!!

Note: I've reduced it to only eight flags to try and prevent RSI!!  Yes, the calculations are fiddly but you ought to be able to set up a simple spreadsheet to help you.

Internet Go Faster switch

Michael Brown  May 4 2014 08:04:44 PM
No, not a joke.  Not clickbait.  I just found out that my ISP does, quite literally, have a Go Faster switch for my ADSL2+ connection.

It's called ADSL Line Profiles:

The ISP seems to err on the side of caution when they first set you up.  My ADSL2+ Line Profile was set to Very High Reliability, which was giving me download speeds of 800/900 kb/s (on a good day).  After I switched it (in stages) all the way up to Very High Speed, I'm now getting 1.4 Mb/s downloads!!  Still a small fraction of the line's supposed maximum, but a massive improvement on what I had before.  Shame it took me seven and a half years to discover it!!

I don't know which other ISPs in Australia offer this, let alone ISPs outside of Australia.  It's worth checking into if you have ADSL though.

Rocket your website speed with CSS sprites!

Michael Brown  May 3 2014 04:37:23 AM
Here's two not very interesting web pages that show the national flags for various countries:

At first glance. they look identical.  But did you notice how much faster the second one loads up?  For me at least, the second one loads pretty well instantaneously, whereas the first is so slow that I can actually see the individual flags slotting into place.

The difference?  The first page uses bog-standard html img tags, whereas the second uses a CSS sprits.  So, the first page has to load 248 images.  The second loads only one, combined image (the sprite), and then uses CSS to display the correct part of that one image (i.e. the individual flags) over 248 div tags.

When measured, the speed difference is a wee bit special.  For me, Google Chrome reports that that the img tag version loads up in 2.96 seconds, whereas the CSS sprite version takes only 631ms.  Yep, that's a 469% speed increase!!

Why such a difference?

When trying to increase page load speeds, Web developers quite rightly zero in on the size of their elements - smaller equals faster, after all.  But just as important is trying to decrease the number of connections that a page has to make to load up its constituent elements.  All those those individual image file loads have to go through the entire connection/hand-shaking routine before the download actually starts.  There's also limits on the number of concurrent downloads a browser will allow from a single server.  This seems to be six concurrent downloads for most browsers, although for IE 8 and below it's only two.

Things get a little more complicated if you should need to resize the sprite-based images responsively, however.  And that will be the subject of a future post...

Note: I borrowed this bit of AppleScript from a StackOverflow post , in order to generate the HTML img tags for the first version of the flags page:
-- select multiple files, limited to images
set filelist to choose file of type "public.image" with multiple selections allowed

set html to ""

-- make a loop that goes through each file
repeat with imagefile in filelist
tell application "Image Events"
  set img to open imagefile
  -- get dimensions of image
  copy the dimensions of img to {W, H}
  -- build / concatenate html string
  set html to html & "[img alt=\"\" src=\"" & name of imagefile & "\" width=\"" & W & "\" height=\"" & H & "\" /]
  close img
end tell
end repeat

set the clipboard to html
display dialog "html for " & length of filelist & " images copied to the clipboard!"


(I changed the angled brackets to square ones to prevent the code from parsing on this page.)

To combine the flag images into the single image for the sprites, I used  This site also generates all your HTML and CSS automatically as it combines your source images into the sprite.

Faster mobile JavaScript click responses with fastclick.js

Michael Brown  April 10 2014 04:39:07 AM
As I pointed out in my post Speedier responses for iPhone web apps a couple of years ago, it's a little known fact is that iOS devices, and older Android devices too, are slow at responding to JavaScript click events.  This is because they have a built-in 300ms delay, due to them needing to respond to other types of tap, such as double tap (to zoom), drag and pinch to zoom.

That 300ms might not sound like a long time, but it is noticeable when you're clicking web page controls that triggers hides and shows etc with JavaScript.  I'd say it's one of the main reasons why so many web apps seem so sluggish when compared to native iOS apps.

Here's a sample page to demonstrate the issue:

Open it on an iPhone or iPad and start tapping on the radio buttons.  Notice the short delay before the box colour changes?  Perhaps not.  Okay, so try this page instead:

Much faster to respond to the radio buttons than the first page, yes?

If you don't have an iOS device to test with, then I've done a video capture of my accessing the two pages with my own iPhone.  (The white circles that you see, correspond to my finger tapping on the screen.)

There's only one difference between the two pages: the second page has the fastclick.js library loaded.  This library does some behind the scenes re-mapping of click events, so you can get that speedier response time without having to rewrite your click events to touchstart or touchend events, as I'd recommended in my original post.  (Using the touchstart event has the disadvantage of disabling drag for the element on which you have it set.)

When, hopefully, the whole 300ms problem is fixed in a later version of iOS - as it already appears in more recent versions of Android - then all you have to do is remove the fastclick library from your apps.

Serving HTML5 Video from Domino

Michael Brown  February 14 2014 01:00:25 PM

I'm looking at rolling out HTML5 video for a site that I'm working on.  The site is made up of Notes documents, and I would be storing the video files on Rich Text fields within those documents.  I last looked at this about six months ago, and well, things in the HTML5 Video world were something of mess.

Six Months Ago

There are three HTML5 formats:
  • H264 (.mp4 file), favoured by Microsoft and Apple
  • Theora (.ogv file), favoured by Mozilla
  • VP8 (.webm file) favoured by Google
If you looked at the W3 Schools' HTML5 Video page, you would seen the major problem with the whole thing:  there wasn't a single one of those file formats that was supported by all 3 of the major browsers!  Furthermore, Internet Explorer requires at least version 9 to support any kind of HTML5 video, and my site needed to support IE7 and IE8.  So, we would have been forced to keep at least two versions of our video files converted to cover the big three browsers, plus a JavaScript/Flash fallback for IE8 and earlier.  I decided to keep using our Flash/JavaScript video solution, which has the major problem that it won't play on iPads or iPhones.


Look at that W3 Schools' HTML5 Video page now though, and you'll see that there's been some major movement: Firefox now supports H264 .mp4!!  Only on Windows, and then only Windows Visa or higher at the moment, although Mac and Linux is supposed to be coming (maybe XP as well?)

The second major change is an internal one: my site no longer needs to support IE8 or earlier.  So, yes, that means we can use only one file format!! .mp4 saves the day!

That's when I ran into problems.  The videos would play on some browsers but not others.  


If you have such problems, then you need to check your MIME types are set up correctly for HTML5 video on the Domino server.   If the MIME type is missing on your Domino server, then you'll likely see the video as something like "application/octet-stream" in Chrome:
MP4 with missing MIME type

For .mp4, the browser should show a MIME type of "video/mp4" as shown below (in Chrome):
MP4 with correct MIME type

To fix this, you need to have your friendly Domino admin edit the httpd.cnf file, which should be somewhere in your server's Domino folder.  For .mp4, you need to add the following line to the that file:

AddType .mp4 video/mp4

Your admin will need to restart the HTTP task after saving the file.  (I don't think a refresh is enough.)

Apple iDevices

That fixed things on the desktop browsers, but there was still one major problem.  My .mp4 files wouldn't play on iPhones or iPads.  It worked fine on desktop, and most annoyingly, on a test Android phone!  On the iPhone though, it just showed with a line through it, and refused to play:
MP4 video won't play on iPhone

As iDevice compatibility was one of the big pay-offs for doing this project in the first place, so I had to simply get it working.

At first, I thought it must be something to do with the video file encoding.  Apple's devices are very fussy about the .mp4 encoding for HTML5 web video.  It has to be H264 encoded for video, with AAC for audio.  But I couldn't get that to work on our internal network.  Oddly enough though, the same video file was served up fine to me iPhone by my own, personal Domino server.  Was it the company network messing things up then?

Nope, it was something far more dumb than that.  It was Domino compression.

Don't Compress Video in Notes!

When I was adding the .mp4 files to my Notes Rich Text fields, I was doing it dragging and dropping them from the Windows File Manager.  But if you do that, the files are always compressed.   This was pointless because these kind of files are already compressed up to the eyeballs before they reach Domino.

I knew all this, but didn't think it could possibly be the problem.  Almost out of desperation, I deleted the video from the Rich Text field, then reattached it using the paperclip icon, remembering to untick the Compress checkbox as I did it.  Bingo!   My .mp4 file now plays fine on my iPhone:
MP4 video ready to play on iPhone

Why this should be the case, and for iDevices only, I'm not really sure.  My guess is that when Domino serves up a compressed file, there's a short delay while the server decompresses it, and the iPhone is being over sensitive to that delay.


"Google’s Threat To MIcrosoft, Chromebooks Are Now ... 10% Of All Computers"

Michael Brown  December 29 2013 05:32:02 PM
This is from Forbes, and the full quote is:

"Google's Threat To MIcrosoft, Chromebooks Are Now 21% Of All Notebooks And 10% Of All Computers"

As Shaggy used to say, "like wow!!!"

There have been signs that this was coming for quite a while: the Samsung Chromebook sat at the top of Amazon's PC sales charts for months on end, yet Amazon refused to release any actual sales figures.  Yet here it is, and not from some nerdy, IT blogger either. Nope, this is from Forbes, the darling of Wall Street.

Suddenly, Microsoft's anti-Chromebook "Scroogled" adverts make some sense: I mean, would the company spend time and money trying to dismiss something that they weren't afraid of?

There's zinger after zinger quotes for Microsoft in here.  Here's just one:

Sales [of Windows] were driven forward in the past by those network effects: everyone else had Windows, everyone was writing for Windows, therefore I must have Windows too. But if those things are no longer true then we’re going to get, pretty rapidly, to a state where Windows isn’t even the default OS for a laptop or notebook: and I can see that following to the desktop soon enough.

Here in Australia, I've seen figures that show Windows usage is down 10% from calendar year 2012 to calendar year 2013.  10%!!!!  And sorry, but Windows 8.1 isn't going to stop that rot.  Once the tipping point is reached, and people stop thinking of Windows as that default thing that you have to have with every PC, then that will be the end for Microsoft in this space; maybe in every space.

Notes Calendar invitees - hidden web service!

Michael Brown  November 14 2013 02:51:13 PM
I've been working on a Web-based calendar that has an ordinary Notes calendar as its source at the back-end.

I was struggling on how to get the invitee status for a Notes calendar entry.  Digging through the Notes mail file design, there's a lot of undocumented LotusScript classes and methods at use for that purpose.  I managed to lift some of that stuff and got it half-working, but not quite there.  Then I came across a way to get it all put on a plate for me!

First, here's a direct link to my calendar entry itself:

Now, see what happens when I append the "&Form=s_ReadPartStatus" parameter:

Wow!  There's the participant statuses served up for me as XML.  Too easy!

I couldn't find a way to get it to produce JSON, so I used the xml2json library to do that, then ran the following jQuery function to map the relevant data to a smaller JSON object:

var jsonObj = $.xml2json(xml);
var mappedObj = $.map(jsonObj.viewentries.viewentry, function(value, index) {
       lineObj = {};
       if (value.entrydata[1].text.value) {
               lineObj.primaryName = value.entrydata[1].text.value;
       if (value.entrydata[2].text.value) {
               lineObj.alternateName = value.entrydata[2].text.value;
       if (value.entrydata[5].text.value) {
               lineObj.roleName = value.entrydata[5].text.value;
       if (value.entrydata[7].text.value) {
               lineObj.statusName = value.entrydata[7].text.value;
       if (value.entrydata[16].text.value) {
               lineObj.delegee = value.entrydata[16].text.value;
       return lineObj;

If you're looking for the s_ReadPartStatus form in your mail file design, you won't find it.  It's actually in iNotes Forms database (iNotes\forms85.nsf).

Taskbar on every monitor!

Michael Brown  November 7 2013 04:01:28 AM
Some time ago, I inherited a widescreen monitor from a friend who as about to leave the country (thanks, George!)  I have it set up as my main monitor, right in front of me, in a dual monitor config with my old 4:3 Acer monitor, which I've positioned to my right.

In the last few months though, it's developed a serious glitch. (Really, can't you get eff all for eff all money any more?)  The glitch is that it flickers so badly that it's unusable for about 10 minutes.  After that, it seems to "warm up" and start behaving itself again- perhaps with few sharp slaps from my hand to help it along.  

No problem, you might think: I can still use my 4:3 monitor while the widescreen one is warming up, right?  Which brings us to the taskbar.  I want the taskbar on my main, widscreen monitor, rather than the 4:3 monitor.  But that means that for the warming up period, the taskbar can't be used while my widescreen monitor is warming up.  And with no taskbar, I have no program switching, no program launching for that matter.  Sure, I can move the taskbar to my secondary monitor, but I don't want it stil there after my main, widescreen monitor finally comes online.  And moving it back and forth between monitors is a pain. (When I shutdown my PC, I have to remember to move the taskbar back to the secondary monitor, otherwise it will be unavailable when I start my PC up the next day.)

What I need then is a way of puting the taskbar on both of my monitors.  In KDE/Linux, it's a piece of cake; I simply add a new panel on the second monitor!  Windows 7, however, doesn't seem to have any built-in way of doing this.

Enter Actual Tools Multiple Monitors, which (according to their blurb) allows "you will get a fully functional taskbar onto each display".  It's $25, but they do offer a free 30-day trial.  I'm running the latter at the moment, and it seems to work quite well (see screenshot below):

Actual Multiple Monitors

My first Chrome extension: Forum Troll Blocker!

Michael Brown  August 31 2013 10:39:15 PM
A couple of weeks back, I wrote a post called Dealing with trolls on ZDNet comments, which showed how to block trolls in the technical forums by using the Tampermonkey Chrome extension.  Although I was pretty pleased with it at the time, it was rather obviously a "geeks only" exercise.  You had to edit JavaScript by hand to define your own list of trolls; not exactly a layman's task.  So I thought, why not make it a Chrome extension in its own right?  I could then give users an basic GUI to define their trolls rather than having to mess with JavaScript.  So that's what I did.

And here it is; the Forum Troll Stomper extension for Google Chrome!

Forum Troll Stomper extension in the Chrome Web Store

It's basically the same JavaScript code that I was running under the Tampermonkey extension, only with some extra HTML and CSS to make it an extension in its own right.  It took a bit of time to acquaint myself with the basic ins and outs of developing Chrome Extensions, but  it's nothing too difficult for anybody who's done any kind of web development.  There's a one-off Developer Fee of $5 - yes, five whole USD - to pay in order to load Chrome Extensions and apps on the Chrome Web Store.  In fact, when I went to pay even this modest fee, I discovered that I'd already done so over a year ago!  (Which makes me either far-sighted or just bone idle.)

As it says in my blurb on the Chrome Store, the Forum Troll Stomper extension is only for the forums at the moment, just because it's a forum that I happen to frequent that has a real troll problem, IMHO.  But it shouldn't be any real problem to adapt to other forums if there's a need.