If You Want to Share Code, Please Add a License

Posted on by Rob Larsen

This has come up a few times recently (example), so I thought I’d point it out here for all the world to see.

If you’re sharing code on a blog, Github or anywhere else you think people might find it and want to use it, please license it in some way. If you don’t, it won’t be used the in the way you might want and expect.

Let me explain.

Many organizations are friendly to open source software. As a consultant and “agency dude”, I’ve seen far more companies that were happy to use open source software than companies who were completely freaked out by the prospect (although I have seen a few completely dysfunctional organizations that wanted to pay money for horrible solutions just because they had the fear.) This is a good thing because 10-15 years ago that wasn’t the case.

The thing is, and it seems some people don’t know this, unless you explicitly license your code, your software isn’t magically open source or free to use.

The lack of a copyright notice or license doesn’t mean you don’t have a copyright on it.

It is, in fact, the complete opposite.

In all countries where the Berne Convention standards apply, when you make software you automatically own all the rights to that software– even if your intent is for it to be free for everyone to use and you hate the very idea of software patents or copyright. Without a license allowing people to use your code within acceptable guidelines you are the only person that has a legal right to use it. While you probably won’t turn around and sue everybody that uses your code (because hey, you’re cool and you wanted to share it with everyone in the first place), there’s also nothing stopping you from changing your mind later and sending out nastygrams asking for big bucks from everyone who ever even sniffed at the code. Right or wrong, that would be your legal right.

And that’s why we need licenses. Any organization (or, really, individual developer) with any sense is going to steer clear of a situation where they might end up having to call their lawyers. Using software without explicit permission is exactly one of those situations.

So, if you’re doing anything that people might find interesting please think about how you’d like to see it used and add a license.

I use what’s commonly referred to as the MIT license because I can understand it and it allows people to do whatever they want with my code.

You might want to choose something else.

That’s cool, as long as you make a choice and let the rest of us know about it 🙂

H5BP Ant Build Script v1.0 Released

Posted on by Rob Larsen

After a year of living as its own repo, contributions from a bunch of people and a flurry of activity from yours truly over the past month*, I just released the 1.0 version of the H5BP Ant Build Script.

Download a zip or browse the code on github.

Moving to semantic versioning was a good idea by itself and it also served as a perfect opportunity to celebrate the features we’ve been able to add over the past year.

Check out these highlights from the changelog:

– Added support for SASS (*.scss) files (#71)
– Added optional jsdoc3 task (#70)
– Added option to compile LESS CSS (#56)
– Concatenate scripts in order they appear in the HTML (#6)
– Added requireJS support (#18)
– Added sample QUnit Task (#133)
– Added ability to opimize images in multiple directories
– Added advpng optimization (#84)
– Added optional image revving (#135, #3)
– Rewrite relative CSS asset urls when inlining @import calls (#2)
– Added HTML Validation (#27)
– Added new, configurable tokens for concatenation (#95)
– Added async and defer as separate options on the script. (#128)
– Added optional progressive jpeg conversion

I also touched up the documentation and generally made it feel more like a project.

Here’s the big contributor party. This is everyone who’s touched this project from the beginning (including its life as part of the core HTML5 Boilerplate project.)

All these people are awesome:

[master]> git shortlog -s -n
   115  Rob Larsen
    84  Paul Irish
    31  Divya Manian
    14  paulirish
    13  Shi Chuan
    11  darktable
    10  Matthew Donoughe
    10  Samus_
     8  Joe Morgan
     6  Andreas Marschke
     6  calvin
     5  Chris Rowe
     5  Ziggy
     4  Audioname
     4  Daniel Holth
     4  Guillaume Moulin
     3  Kim Blomqvist
     3  bholt
     3  drublic
     2  Andrew Le
     2  Beau Simensen
     2  Calvin Rien
     2  Dan Lopretto
     2  Daniel Filho
     2  John Bacon
     2  Kushal Pisavadia
     2  Maurice W
     2  Ramiro Rikkert
     2  See Guo Lin
     2  Steve Lindstrom
     2  Tarcio Saraiva
     2  alvincrespo
     2  gbakernet
     1  AD7six
     1  Aaron Kavlie
     1  Adrien Kohlbecker
     1  Alex Whitman
     1  Brandon Holtsclaw
     1  Bruno De Barros
     1  Chris Hager
     1  Chris Morrell
     1  Corey Ward
     1  Daniel Reiser
     1  Dave Kirk
     1  Dmitry Gladkov
     1  Egor Kotlyarov
     1  Greg Zoller
     1  Gregory Pakosz
     1  Hans
     1  Jeremey Hustman
     1  John Attebury
     1  Josh Farneman
     1  Kyle Robinson Young
     1  Martin Balfanz
     1  Nic Pottier
     1  Nicholas Camp
     1  Nicolas Gallagher
     1  Robert Doucette
     1  Rutger de Knijf
     1  Taylor Ralston
     1  Tharique Azeez
     1  Thomas Kahn
     1  crappish
     1  d8uv
     1  dplesca
     1  elexx
     1  localpcguy
     1  mikemorris
     1  mikkotikkanen
     1  owilliams
     1  philipvonbargen
     1  rdeknijf
     1  rwldrn
     1  toddhgardner
(END)

*yes, I have a funny way of celebrating having a life again.

How did the IE Conditional Classes Get on the HTML Element in HTML5 Boilerplate?

Posted on by Rob Larsen

Since it comes up from time to time on Github (See #1288 and #1187) and I was involved in part of the discussion I thought I’d try to clarify the timeline and reasoning for the placement of the IE conditional comments in the HTML5 Boilerplate project (and anywhere else that uses the HTML element for the conditional classes.)

For those of you unfamiliar with the pattern, it looks like this:

<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

These different versions of the <html> element are displayed in IE6, IE7, IE8 and modern browsers allowing you to target Internet Explorer conditionally based on a CSS class at the very top of the cascade.

Anyway, for such a small block of code it actually generates a lot of discussion in the repo and is the subject of at least one, long-standing issue.

Also, removing them is an open issue right now.

Anyway, since I was involved in some of the original discussion and still actively watch activity on the HTML5 Boilerplate repo and participate where it makes sense; I often find myself chiming in on issues discussing the conditional comments with a series of links trying to illustrate the long and tortuous journey they took to get to the state they’re currently in.

While those links contain all the information needed to follow the thread, it’s not all that easy to put the trail together without having lived through it.

To that end, here’s how the comments ended up where they are- presented in chronological order with just the most important details.

  1. On October 20 2008, Paul Irish kicked the whole thing off with the post “Conditional stylesheets vs CSS hacks? Answer: Neither!. In it’s original form the conditional comments wrapped the <body> element
  2. I ended up learning about the technique in December of 2009 when I interviewed at Molecular (where Paul worked at the time) and Nick Cooley mentioned it during the interview. “Cool” I thought. Since I didn’t actually read the post and just had the technique described to me, I ended up implementing it in a way that made sense to me during the redesign of my (other) site (which is once again on the block to be redesigned.) I placed the comments around the <html> element. I was already using the <body> element for classes, so I probably never even considered using the <body> element for that purpose.
    That version of the site launched March 1, 2010.
  3. On May 20, 2010 Markus Leptien posted IE 6 slowing down IE 8. In which he details the curious case of IE8 blocking downloads because of the presence of an IE6 specific conditional comment.
  4. Stoyan Stefanov took up the cause on May 23, 2010 with his post http://www.phpied.com/conditional-comments-block-downloads/ where he outlines the even curiouser case of IE blocking downloads even if the conditional comment isn’t for a CSS resource. This spelled trouble for the conditional comments on the body element.
  5. On May 24th, 2010 Markus Leptien posted a solution to the issue which required an empty conditional comment high up in the DOM.
  6. Paul added the empty conditional fix to HTML5 Boilerplate on June 3, 2010
  7. For whatever reason, I got hooked into the discussion and pointed out that “My variation of Paul’s pattern works out of the box. Instead of applying classes to the body, I apply them to the HTML element. No need for empty comments” The same day Paul updated his blog post with that news and the pattern settled on the HTML element
  8. On September 9, 2010 Divya Manian moved the comments to the HTML element in the HTML5 Boilerplate repo.

And that’s the origin story. It’s not exactly as exciting as how Bruce Wayne went from being a rich kid seeing the Mask of Zorro to being Gotham’s Dark Knight Detective, but at least now people be confused by how the placement came to be.

I’ll be Presenting At HTML5 Developer Conference in San Francisco

Posted on by Rob Larsen

I just got word that my presentation was accepted. I’ll be presenting alongside people who are really super smart. I’m hoping to not embarrass myself.

I promise I won’t pick a fight with Douglas Crockford just as a goof.

Here’s the pitch for my talk:

We’re awash in data. Making sense of that flood of information is impossible without the aid of visualizations to simplify the information, amplify the important points and educate at a glance. The open web platform has two main technologies for working with interactive visualizations: SVG and Canvas. This presentation will outline the optimal use cases for each, will talk about the current state of each technology and will show detailed examples of each in action.

In detail I’m going to cover the core differences between the technologies, the support landscape and then look a little bit at coding in each. Since this is a practical talk, I’ll likely cover some core canvas, D3, Raphael, and Stockcharts/Highcharts. I will probably show a CanvasJS slide since I’ve been working on it again and it’s actually going to be a thing at some point- even if that “thing” is just a novelty me, Bob and Marc worked on.

Reuse and Recycle: SVG

Posted on by Rob Larsen

SVG has had a long and strange journey to the world of ‘emerging technologies” SVG was actually defined in 1999, so it’s not exactly the new kid on the block. Still, it took a while to catch on, so in some ways it feels like the new kid on the block. Like Canvas, SVG allows developer sot create graphics in the browser using native web technologies. Unlike Canvas SVG is a vector based grammar and, since it’s defined as XML it also allows for access using common DOM manipulation tools. One of the most difficult issues when dealing with Canvas is the need to manually manage the state, properties and events of individual elements. Since SVG elements are simple DOM elements, properties are stored as part of the regular DOM and access to individual elements is available using traditional DOM access methods like document.geElementById and document.getElementsByTagName.

One driver of popularity for SVG has been the emergence the RaphaelJS library. Raphael provides a convenient API on top of the specification and provides some measure of support for legacy IE browsers by rendering the output of Rapehl instructions as Vector Markup Language (VML.)

The following example shows Raphael and SVG in action. Example output can be seen in the following figure.
Created with Raphaël 2.1.0

The following code sample illustrates using Raphael to draw 10 random circles on an SVG element, filling them with a random gradient fill. The code is quite simple, with a new paper variable containing the instance of Raphael in use and then straightforward methods circle() and attr() used to create circles and fill them with the fancy gradient fill.

<!DOCTYPE html>
<html>
<head>
  <meta charset=UTF-8">
  <title>SVG</title>
</head>
 <style type='text/css'>
    #svg {
    width:100%;
    height:600px;
}
  </style>
</head>
<body>
  <div id="svg"></div>
  <script src='https://cdnjs.cloudflare.com/ajax/libs/raphael/2.1.0/raphael-min.js'></script>
  <script src='demo.js'></script>

</body>
</html>

window.onload=function(){
var svg = document.getElementById("svg"),
    paper = Raphael( svg ),
    circle,
    width = svg.offsetWidth,
    height = svg.offsetHeight;

for (var i = 0; i < 10; i++) {
  circle = paper.circle(
    parseInt(Math.random() * width), 
    parseInt(Math.random() * height ), 
    parseInt(Math.random() * 200));
  circle.attr({
    "fill": "r" + hex() + "-" + hex(),
    "fill-opacity": "0.5",
    "stroke": "none"
  });
  circle.click(function() {
    console.log(this);
    this.animate({
      cx: parseInt(Math.random() * width),
      cy: parseInt(Math.random() * height),
      r: parseInt(Math.random() * 200)
    }, 1000, "bounce")
  });
}

function hex() {
  //http://paulirish.com/2009/random-hex-color-code-snippets/
  return '#' + Math.floor(Math.random() * 16777215).toString(16);
  }
}

Inspecting the output the underlying markup isn’t quite so succinct, although it should be readable if you’re familiar with XML syntax and can follow along with the code that generated the example. The following code sample shows a single circle marked up using SVG syntax.
The interesting pieces to note are the definition of the radialGradient in the defs element. defs are used for reusable content. You can see it referred to in the circle element’s fill url. 

<svg height="400" version="1.1" width="400" xmlns="http://www.w3.org/2000/svg" style="overflow: hidden; position: absolute; left: 0px; top: 0px;">
  <desc>Created with Raphaël 2.1.0</desc>
  <defs>
    <radialGradient id="0r_7d7f2f-_bbb372" fx="0.5" fy="0.5">
      <stop offset="0%" stop-color="#7d7f2f"/>
      <stop offset="100%" stop-color="#bbb372" stop-opacity="0.5"/>
    </radialGradient>
  </defs>
  <circle cx="170" cy="68" r="61" 
          fill="url(#0r_7d7f2f-_bbb372)" 
          stroke="none" 
          style="opacity: 1; fill-opacity: 1;" 
          opacity="1" fill-opacity="1"/>
</svg>