Shiny Pebbles...

Resizable 4-way Rocker Widget

Richard — Sun, 25 Sep 2011 21:14:39 +0000

It has always seemed odd to me that the 4-way rocker switch that’s at the top of almost every TV and DVR remote and game controller has not made its way into the collection of web input widgets. Even with all the new whizzy input controls in HTML5, there’s not an analogous 2-axis control.

I took a crack at creating one and discovered that I couldn’t do it with pure CSS. While it’s possible create things that look like triangles on the screen, in (cyber) reality they are rectangles with transparent bits. There’s no apparent way to create triangular areas for hover detection.

But using mouse position detection and a bit of jQuery, it’s not too hard make something work. The code is up on jsFiddle. The widget is re-sizable, with the scale of all the various bits and pieces being controlled by the font-size property in the rockerControl div.

Simple HTML Slides – Not Ready for Prime Time?

Richard — Wed, 21 Sep 2011 22:01:27 +0000

Christian Heilmann, one of the most persuasive of Mozilla’s evangelists for HTML5 wrote a blog post titled “Why I don’t write my slides in HTML.” It’s a good read. In it he provided a list of places where he sees HTML slide tools falling short. These days, Christian spends much of his life giving presentations on HTML so slide tool developers who ignore those points do so at their peril.

I’ve remixed Christian’s list and used it as a scorecard and feature checklist to guide further development of Simple HTML Slides. If it’s possible to satisfy all (or at least most) of those requirements then I can be confident that Simple HTML Slides are actually useful in the real world of hard core presenters.

Check out the Simple HTML Slides Project Page to see a working presentation that has a slide with video on it, all embedded in a WordPress post.

Ink a Teacher!

Richard — Wed, 14 Sep 2011 21:22:43 +0000

“An apple for the teacher” is an old tradition in America that has fallen by the wayside. But doing a little something to show your children’s teachers that you appreciate their effort and understand the challenges they face is still worth the effort.

Rather than sending an apple for the teacher, I’d like to suggest you “Ink the Teacher”. No, I’m not suggesting a gift certificate to the local tattoo parlor. I’m talking about ink for the classroom printer. Teachers in the US typically spend hundreds of dollars each year out of their own pockets to get supplies that dysfunctional school systems don’t provide. We could all help just a little.

When you head to your child’s classroom for back-to-school night this year, do a little sleuthing and find the model number of the classroom printer. Contributing an inkjet cartridge and perhaps even a ream of printer paper will give you superhero status and help ensure your child has a productive school year less constrained by tight school budgets.

…and if you tweet the idea, maybe you’ll help more than just your child’s class.

Turn PDF Slide Decks into HTML5 Web Presentations in Under 5 Minutes

Richard — Tue, 26 Jul 2011 16:14:29 +0000

In an earlier post, I introduced Simple HTML Slides and an anonymous sync server that lets your audience follow along via the web. It uses some deep jQuery magic from Janne Aukia’s wonderful zoomooz.js.

There’s now a new feature that will let you take a PDF of a slide deck and quickly and easily turn it into an on-line presentation that syncs just like the earlier HTML slides.

On a Mac the process is amazingly simple. I’ve been able to put a 60-slide presentation on-line in under three minutes! Just browse to the PDF Slides page and follow the easy instructions there.

I don’t know of a workflow for Windows that is as simple as what’s on that page. It should be possible to cobble together a PhotoShop action but I’d rather find a solution that doesn’t require a $600 software package. If you know a quick, simple way to make a directory of web images from a PDF (preferably with free & open source software), please post a comment.

UPDATE: This post, and the PDF support feature of Simple HTML Slides have caused a lot of confusion. Many people see this and come to the erroneous conclusion that Simple HTML Slides aren’t actually done in HTML and the only way to make a presentation is to pour a PDF into Simple HTML Slides. That isn’t true. Supporting PDFs of other presentation formats is just an added feature of Simple HTML Slides. The real power of Simple HTML Slides shows when you write your slides in HTML. See the project page for more details.

Crowdsourced Help for Ladybugs

Richard — Wed, 13 Jul 2011 21:30:39 +0000

Ladybugs are some of our best friends in the insect world. They are voracious predators of aphids and other plant-damaging insects, but two of the major species of Ladybugs in North America appear to be in decline. The Lost Ladybug project at Cornell University is conducting a study to learn more, and you can help.

To be able to help the nine spotted ladybug and other ladybug species they need to have detailed information on which species are still out there and how many individual insects are around. Entomologists at Cornell can identify the different species but there are too few of them to sample in enough places to find the really rare ones. They need us to be their legs, hands and eyes. This is a great summer science project for both kids and adults! You can learn, have fun and help save these important critters. It’s also a great excuse to get away from your keyboard and spend a day outdoors.

If you find a ladybug in your garden or while on a hike, snap a picture and make a note of the time and location. Then visit The Lost Ladybug Project’s web page and upload the photo. You’ll help the team at Cornell learn more about where the different species live, and help our spotted friends as well.

Mozilla’s Robots

Richard — Tue, 03 May 2011 14:33:46 +0000

I recently had a chance to interview Mozilla’s new Director of Robotics. It looks like there are some big changes coming in the way humans and robots interact at Mozilla. See the video for all the details.

Web App Strategy Marginally Flawed

Richard — Mon, 11 Apr 2011 16:33:19 +0000

A Sad Tale In Which We Discover That The Bleeding Edge Is ¾ Of An Inch Wide

There is a lot of attention being payed to web apps these days. Web apps are applications written using the same technologies used to create web sites, HTML, CSS and JavasScript. Web apps offer the best opportunity for cross-platform application development for mobile devices, and there is now burgeoning interest in web apps for desktop platforms as well. Firefox 4, with it’s support of HTML5, much of CSS3 and a wicked-fast JavaScript engine, provides a better environment than ever for both developing and using web apps.

So… when a non-technical friend asked for help with a project, I decided to take a crack at solving the problem with a web app. Now keep in mind that I’m not a full-time code-cutter, so I may be missing something, but what looked like a very simple task turned out to be surprisingly difficult.

The assignment was to print some temporary business cards on pre-scored forms from the local office supply store. Because I’m a Mac user and the MS-Word templates from the form vendors don’t work on my preferred word processor, this is a problem I usually solve with Photoshop. But I wanted a cross-platform solution my friend could take home and use later, and recommending a $600 photo editing package for this task is just plain silly. So a web app seemed to make perfect sense. Using both new HTML5 features in Firefox 4 and older features like the global attribute contentEditable that have now become standardized, it was easy to cobble together a nifty little web page that would let the user edit a card in a wysiwyg editor and then produce a page full of the new cards at the click of a button.

Failing At The Margins

The problem came when I tried to print the cards. The forms from the office supply store require printing with a ½ inch margin at the top. But on MacOS, the Firefox UI does not provide any access to margins in the page-setup dialog. Regardless of what you do, Firefox prints ¾ inch margins all around, pushing part of your output to the next page. This means that aligning the card content with the pre-scored forms is impossible. (bug#648657).

Digging into about:config shows some margin prefs that are set to 0.5. Presumably those are inches, although there is some very old documentation that says it’s the number of half-inch increments. But in any event, neither match the ¾ inch margins that appeared in the printed output. Those issues aside, non-technical users shouldn’t be messing with about:config, and to change those prefs from code we’d need to write a browser extension instead of a web app. If we change all four print.print_margin_xxxxx prefs to zero, then it’s possible get the right margins, for my printer at least, by using CSS to set the left margin to 0.625in and the top margin to 0.375in. Not exactly obvious.

I opened a Windows XP VM to test the behavior of Firefox on Windows. Page Setup gives me access to margin settings, but setting ½ inch margins top and bottom doesn’t position the output to match the cards, so any web app would have to prompt the user to set some non-obvious margin value that may well vary from printer to printer. Better to set all the margins to zero in Page Setup and fiddle with CSS. I noticed that in Windows there is a separate set of print.PRINTERNAME.print_margin_xxxx prefs for each printer. On MacOS there only seems to be the one, regardless of how many different printer drivers are installed. So even finding the name of the right pref to change could be a bit of a challenge for an app developer.

Searching the Mozilla Developer Network, I wasn’t able to find any documented way to control the printing of browser headers and footers from the web app. The same is true for the “print background” and “print background images” checkboxes in the print dialog. A printing app needs to be able to control page margins, and set defaults for most print parameters so that the user doesn’t have to set everything from scratch each time the app is used.

There is a pref, print.use_global_printsettings, that is documented in Mozillazine as allowing the user to change the print settings independently for each browser window. On MacOS it appears to allow the settings to be set on a tab-by-tab basis, on Windows it didn’t seem to work. Print settings changed in one window changed the settings in all open windows, the output was scaled oddly and backgrounds disappeared regardless of the status of the Print Backgrounds checkbox. (Global print settings seem to have been a known problem for a while now. See bug#194268).

But a single switch, buried in about:config and inaccessible to a web app’s JavaScript isn’t really an answer. Wouldn’t it be better if each app tab’s settings were modified independently while keeping the global settings for regular tabs? (See bug#648950).

There are sound security reasons for making about:config prefs inaccessible from scripts on the web. However I believe there is a case to be made for having some mechanism for controlling various print setup parameters from JavaScript. The alternative seems to be to force any web app that wants to print to be implemented as a browser extension rather than as a web app. Can anyone suggest a reason that granting JavaScript access to printer prefs would constitute a security vulnerability?

Vanishing Web Fonts

The lack of page-setup control wasn’t the only problem with our little experimental app. None of the Google web fonts used by the application show up in the printed output! Firefox substituted Helvetica for all of the web fonts. Web fonts only appear in printed output if the same font is also installed in the operating system. (~~bug#648679~~ a dupe of bug#468568). This greatly complicates the installation process for web apps that print. We could limit our app to just the fonts installed on the local system, but JavaScript doesn’t have a way to enumerate those directly, and the existing work-arounds make rather unacceptable assumptions.

Shouldn’t Mozilla Be Empowering Users?

Now I’m sure that some will argue that printing isn’t important for web apps, especially web apps for mobile devices. After all, Apple didn’t implement any form of printing until the fourth generation of the iPhone, and web apps are mostly for mobile devices, right?

Wrong! If Mozilla truly wants the web to become a first-class platform for applications, we need to empower the user to print.

Web App Strategy Marginally Flawed by Richard A. Milewski is licensed under a Attribution-ShareAlike CC BY-SA.
Based on a work at http://richard.milewski.org/archives/1059.

Non-Obvious CSS: Full-Screen Gradients

Richard — Fri, 11 Mar 2011 10:07:44 +0000

Anyone who has ever cobbled together a CSS file for a web page knows that you can set the background color for the entire window by setting the background-color property of the body tag like this:

body {
  background-color: #00abeb;
}

Many modern browsers (Firefox, Chrome and Safari) support a linear gradient fill in the background-image property that, in theory, lets you spiff up those backgrounds a bit without having to load large images. It’s fast, because it happens in the browser, and it looks nice.

But if you write a CSS entry that looks like this:

body {
  background-image: -moz-linear-gradient(top, #ed5900, #eff108);
  background-image: -webkit-gradient(linear, left top, left bottom, from(#0ae), to(#fff));
  background-image: -webkit-linear-gradient(top, #0ea, white);
}

The background gradient only goes to the bottom of other page content. It doesn’t fill to the bottom of the browser window the way a solid color does. What’s even more puzzling, the documentation for -moz-linear-gradient, says:

The -moz-linear-gradient property does not allow repeating gradients. For this functionality, see -moz-repeating-linear-gradient .

But the gradient repeats in segments the same size as your content height until it gets to the bottom of the page.

I’ve been assured by people who understand why all this happens that it’s pretty much the way things are supposed to work according to the standards. (That solid color in the example above is repeating as well, but you can’t see the boundaries).

The good news is that there’s a work-around. The bad news is that before today it didn’t seem to appear in anyone’s documentation. …you could waste hours Googling for a solution without success.

Work-Around

Here’s the trick. You need to set the min-height property of the tag in your CSS:

html {
   min-height: 100%;
}

Why the tag and not the tag? I haven’t a clue, but it seems to work in all three browsers.
Try playing with the demo page.

UPDATE: Boris explains why! See the comments…

WordPress Themes Victims of Progress

Richard — Sat, 05 Mar 2011 21:59:17 +0000

If you have a blog powered by WordPress and you’re using a theme based on “Default” or “Kubrick” you need to change to another theme.

The issue is that these themes do not play nicely with many of the HTML5 parsers in forthcoming browsers.

The bad news is that WordPress shipped with default themes based on Kubrick up until the recent 3.0 WordPress release, so there are hundreds of thousands of sites using these themes.

In many cases these sites will not display properly on Firefox 4.0, Chrome 9, Opera 11.5, or IE9. They do work in Firefox 3.6 and other earlier browsers.

If you’re running a WordPress powered blog, right now would be a good time to download the Firefox 4 beta and check your site.

There’s a warning post in the WordPress Forums on the topic, and more details in Bug 638487.

New Data on Password Re-use

Richard — Fri, 04 Mar 2011 21:00:08 +0000

One of the battles in the recent cyberwar between the group Anonymous and Aaron Barr the now ex-CEO of HBGary Federal was the hacking of rootkit.org.

While most of the media attention has been focused on the personalities, egos, and the questionable ethics involved, Joseph Bonneau, a PhD candidate in the Security Group of the University of Cambridge Computer Laboratory, gleaned some surprising information from the leaked rootkit.org database.

In a blog post on Light Blue Touchpaper, the Security Group’s blog, he compares that data with the user database from the recent Gawker incident. He found a rate of password re-use much higher than most previous estimates.

“Of the 456 common users, 161 had their password cracked in both datasets, 46 only had their rootkit.com password cracked and 77 only had their Gawker password cracked, leaving 172 with neither password cracked. Of the accounts for which passwords were cracked at both sites, 76% used the exact same password. A further 6% used passwords differing by only capitalisation or a small suffix (e.g. ‘password’ and ‘password1′).”

He goes on to explain why the 76% is not a valid estimate, but that the real number is somewhere between 31% and 43%. These numbers are a substantial increase over the 12% estimate of Florencio and Herley (Microsoft Research) and the 20% estimate from Gaw and Felten’s user survey at Princeton.

The full blog post is a worthwhile read.

This reinforces my belief that increased consumer education on the dangers of reusing passwords between sites and banning passwords appearing in the rootkit.org top-500 and Gawker top-250 lists would do much more to improve security than setting arbitrary password content standards and forcing periodic password changes.

However, Matthew Slyman, another Cambridge University alumnus, makes an argument for an algorithm uses variable password expiration periods to encourage stronger passwords.

You can follow the ongoing HBGary soap opera on Ars Technica.