Beginning HTML and CSS is O-U-T

Posted on by Rob Larsen

I’ve mentioned it on Google+ and Twitter. I should probably mention it here: Beginning HTML and CSS is out. It came out yesterday.

Here’s proof:

20130311_162525

The book looks great. I’m really happy with it.

Are there things I wish I could redo? Sure. Of course. But overall, based on what I had to work with in terms of existing material, time and other obligations, I don’t think I could improve on what’s on the shelves in any significant way.

I’m very proud of the introduction to jQuery chapter. It was written towards the end of the book and was one of the things I was most interested in writing when I started the project. I think the combination of my own interest in the subject and the fact that I had a solid foundation of cranking out 2-4 pages a day for months at a time made for some really good writing. Easy writing to do, but still pretty good.

If you’re a novice web programmer or an experienced programmer who has never used HTML,CSS and JavaScript to build a web front end, I really think this book will be an invaluable guide to get you up and running.

The Next One

Both books I’ve written (and the other book I was writing that got shelved) have had other authors involved. With Professional jQuery I came in, late in the project, with the goal of finishing it off. I spent the whole time on that book reacting to what was there. I think I did some good work there, but it’s not the book I would write if the project were 100% mine. I would have approached it differently from the first chapter. And even putting structure aside, the chapters that I normally would be most interested in writing (the chapters introducing the jQuery API) were already done when I started in on the book. It was a great experience, just not an optimal one.

This book had existing material as well, so I was once again reacting to the structure and content that was already there. The good thing about this experience is that I was able to use what I wanted and had carte blanche to tear things apart if I felt like it would make a better book.

So, with all that in mind, the next book I write is going to be mine from the ground up. That’s really important to me. While I’ll always listen to opportunities in this space, and I try not to say “never” (although… I’d really to say that I’m never using ExtJS again and know that it will be the gospel truth;) I really don’t want to go through this process again unless the book is wholly mine. Too much is invested in this kind of work to not be able to steer the content to the greatest possible degree. Obviously, writing books is collaborative and I’m not just being polite when I thank all the people involved (notably Carol Long, Katherine Burt and Dan Maharry here) there’s still a level of control I’ve yet to achieve having never truly been the sole author of one of these things.

I’d like to do that.

I’d also like it to be shorter. I’d love to write a thinner volume since it’s difficult to maintain book writing pace over a long period of time. 2-300 pages sounds pretty good to me right now.

Not that I know what it would be.

(Rob runs off to think about the next thing)

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.