Internet Fame: on Being Pirated, Impersonated and Sighted

February 3rd, 2015

So today I discovered that the HTML videos that I made for a few years back are being pirated. You can find various torrents all over the internet!

I Ain't Even Mad

People are willing to break the law to hear me teach! I don’t know why I trust the words of a pirate, but the description of the first one I saw came across to me as high praise.

A nice training session for those who want to learn the dark arts of Proper website building without all the WYSIWYG crapware that’s flying about on the internet….Even the more experienced users will find this interesting….

I made these videos for Educator a long time ago. I figured they’d be mostly forgotten about by now, but I still get ‘thank you’ emails from people who have taken the course and somehow figured out my email address (with a little research it isn’t hard), so clearly people are still watching them. Now that I think of it, I also still get a paycheck from Educator every month, which indicates that at least some people are watching the non-pirated versions on

This isn’t the first flattering but slightly odd realization I’ve had regarding these videos. Have you seen my twitter account? Yep, that’s my name, and that’s a photo of me, but that’s not my account! It’s an impersonator! And it has more followers than my actual twitter account! What does that say about me? (Probably just that I don’t really use twitter.)

The experience that takes the cake, however, was my first celebrity sighting—where I myself was the celebrity! I was working the JPL Open House at the robotics tent when someone came up and said “I took your webmaking course!” I was so surprised I didn’t even know what to say or do. I think celebrities are supposed to want to avoid attention, right? I kind of felt like I was obligated to sneer at her and put on dark sunglasses, but I was so flattered that I wanted to hug her. I guess the right thing to do would have been to get a picture with her. Next time? Will there be a next time?

Gallop: My jQuery Carousel Plugin

December 18th, 2014

In the last four websites I’ve built, I’ve used four different jQuery carousel plugins. I’m not really a super fan of carousels, I think they’re kitschy and make for bad UX. They’re the twenty-ten’s version of a flash intro screen. But designers throw them in and clients like them, and I don’t always get to make all the decisions around here.

Since I’m pretty much an expert at it by now, let me tell you about the process of how to find a jQuery carousel that you hate. First, you hit up Google, and pin the command key down while clicking on links until your tabs look like the Nintendo version of the Sierra Nevada mountains in the top of your browser.

Lots of Tabs

Then you sift through all the  articles like “500 Great Responsive Carousels” and “25 Carousels that are the Last Carousel You’ll Ever Need” until you have a list of twenty or so GitHub pages. Then you start looking through the demos, most of which won’t work. Then you download the code and see if you can get it working. Most you won’t be able to, so you spend some time looking at the documentation and making adjustments and fixes until you get some of them to work. Then you exclude the ones that make the browser run slowly because they’re so bloated. Then you spend some time figuring out the API’s that the plugin vendors wrote to make it “easy” for you to change up the features. When they prove too much effort, you just rewrite the code yourself, slashing out wide swaths of code you probably don’t need until you’ve got a somewhat lean plugin. Then you spend forever working around the skins that they built in since your carousel needs to look different. In the end, you’ll end up with one plugin that kind of works, but is buggy or broken bloated or otherwise inadequate.

I finally got tired of this process, which is why I have contributed my own addition to the jQuery carousel mess. I call it Gallop, and it’s intentionally very simple, barebones, and featureless. We’re web developers. We know how to tweak some jQuery to get the features that we want working. We can adjust CSS to make things look right. We don’t need massive plugins with complicated mechanisms to control a million possible configurations. Maybe we just want some divs to slide across the screen, ok? Is that so hard?

No, it turns out it’s not so hard. Less than 100 lines of jQuery, a little more CSS. You just put an unordered list in a div, and it works. The code is incredibly easy to follow, and if you want to change around the features, you just directly edit the code! If you want an additional feature, you just add it right in!

Anyway, here’s the GitHub page. I even made a fun little demo for it as well. Hopefully this simplifies the jQuery plugin process for some people.

Firefox Developer Edition

November 10th, 2014

Firefox just came out with a developer edition of their browser.

You can install it parallel to your existing Firefox installation. Has a ton of cool features for developers built right in, and is kept up to date on the “aurora” channel so you can test with all the newest features currently in development months before they come out on the standard release channel.

More info here and here, and a video here.

Vendor Prefixes: Blink, and You’ll Miss Them

October 25th, 2013

Google has announced that they will be forking WebKit to create a new rendering engine for Chrome called Blink.[1][2] Google will be able to remove millions of lines of code from Blink that isn’t needed for Chrome, and will be able to work more aggressively to develop Chrome-specific features into Blink.

This won’t unsettle things too much—at least not right away. The latest builds of Canary are already using Blink, and there is no perceptible difference. The CSS -webkit- prefixes even still work. So how long will it be until we have to switch over to using a -blink- or -chrome- prefix for our rounded corners? The answer to that question is: “wrong!” There will be no -chrome- prefix, or any other vendor prefixes at all, moving forward. Instead, you’ll have to change a setting in your browser to enable experimental CSS features.

Vendor prefixes seemed like a good idea. And maybe they would have worked, if developers had used them as intended. Eric Meyer wrote the seminal article advocating vendor prefixes, Prefix or Posthack. He explained that we could use vendor prefixes to escape the conflicting standards of the bad old days, when the same code was rendered differently by different browsers. Due to Internet Explorers broken box model, width meant one thing in Trident (IE’s layout engine) and something entirely different in Gecko (FireFox’s layout engine). Furthermore, because these differences were alive and living on the internet, there was no way for either browser to fix (or compromise) its definition to unify the web without breaking existing pages. Internet Explorer eventually fixed it’s box model, but it has been an arduous, difficult journey, one that has not yet reached it’s destination. Despite years of very clever attempts to fix things with the creation of quirks mode, doctype switching, and for IE, conditional comments and the problematic compatibility view (which still persists in IE10!).

With vendor prefixes, none of that would happen, because new CSS features would go through a vetting period, during which the feature could only be accessed by prefixing a code to the property name. After a time of testing, and when the standard was defined more definitively, the browser could begin supporting the property without the prefix, and nobody would have incompatible CSS anymore!

This quickly created a situation where the simple task of rounding some corners turned into this mess:

-ms-border-radius: 10px;
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
-khtml-border-radius: 10px;
border-radius: 10px;

When it comes to background gradients, things are even worse:

background: -moz-linear-gradient(top,  rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(255,255,255,1)), color-stop(100%,rgba(255,255,255,0))); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* IE10+ */
background: linear-gradient(to bottom,  rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#00ffffff',GradientType=0 ); /* IE6-9 */

Not only does each browser get its own line, the WebKit browsers actually use two lines, due to a change in syntax. The messiness of this is annoying, but it isn’t actually that huge of a problem, in terms of web compatibility. In fact, it saved us from having to write crazy javascript to detect the browser and version number in order to give one syntax to < Webkit 4 browsers and another syntax to all others. The real problem is that this is how most developers began coding their sites:

-webkit-border-radius: 10px;
border-radius: 10px;

or even just:

-webkit-border-radius: 10px;

You can see how this sort of abuse caused problems. Developers got used to Chrome being on the bleeding edge of CSS3 features, and began coding specifically for it without taking the time to check whether other browsers had supported the features yet. Effectively, vendor prefixes had become browser detection all over again, and developers were using this browser detection to block functionality from all browsers except WebKit. As you can imagine, this annoyed other browser vendors, like Opera, who were working hard to keep their browser up to date with CSS3, but which was blocked from applying the styles due to lazy coding. Developers had turned -webkit- into the very -beta- prefix which Eric Meyers dismissed in his article.

The -beta- prefix was proposed by Peter-Paul Koch as a compromise to his original proposition to abolish vendor prefixes. Koch’s vision was prophetic. In March 2010 he wrote:

Eventually Opera will discover that plenty of sites use -webkit-transition, but not -o-transition. Will Opera start to support -webkit-transition, too?

Despite a widely circulated call for action to web developers to change their ways and prevent “judgement day,” two years after Koch’s prediction, Opera announced it would support -webkit- prefixes. Mozilla had been planning to do the same. Microsoft’s massive attempt to change the bad behavior of developers had failed, and they too would follow suit.

It looked like things were going to get really messy. Then suddenly, Opera announced that it was abandoning its rendering engine Presto, and would instead use WebKit. While many saw this as a sad day for the web, the silver lining was that judgement day had been pushed back a little. Furthermore, Opera is adopting Blink with Google, and Mozilla is creating yet another rendering engine called Servo. So we aren’t looking at a rendering engine monoculture or a return to the “bad old days.”

So with all these new rendering engines, what will happen to vendor prefixes? They’re all going to go and live with the <blink> tag and IE’s broken box model. Mozilla is heading in the same direction as Chrome: “avoiding vendor prefixes by either turning things off before shipping or shipping them un-prefixed if they’re stable enough.” This is where all the vendors are headed, and the W3C working group on CSS has already put together a policy that rang the death knell of vendor prefixes.

This article originally appeared on the blog. It was cross posted by permission the owner of Shoutleaf (me) and the author of the article (me).


April 28th, 2012

I think of a Chef as a sensitive guy
Cutting onions makes him happy, but it also makes him cry.