Focus and Select: a cross-browser bed time story

Here’s an annoying little DOM’ism that stumped me last week (don’t worry, there’s a happy ending if you keep reading).  In Popcorn Maker’s UI I wanted to fix a few places where we have textboxes that contain data from json manifests.  When you click on such a pre-populated textbox, it’s nice if the contents of the textbox are selected.  And when you click again, it’s nice if the selection is removed and you instead position the cursor.

These are nice enough that one would sort of expect them to just work, and as such, that the DOM would actually allow you to do it.  Well, it’s easy to do on Firefox: just add a focus event to your input element, and call element.select().  Done.

Now test in WebKit and it doesn’t work. Sniff around the web a bit and you’ll uncover a nasty 4-digit WebKit bug from 2008 that causes mouseup to undo your selection.

“That’s fine,” you say to yourself, “just stop the mouseup event from doing its thing and clearing the selection.” This is what everything on the web I could find said to do. The trouble is, I want to not only select the contents of the textbox on first click, but I want the opposite on subsequent clicks.

In the end, cross-browser compatible code means unnecessarily elaborate code, but here we are. I’ll leave this for the next person who hits my same edge case–aka the default way a textbox should function. Here’s a little jsfiddle demo of it running, and here’s the code:

var selectaBox = (function(){

  function __highlight( e ){
    var input = e.target;
    input.select();
    input.removeEventListener( "focus", __highlight, false );
  }

  function __ignoreMouseUp( e ){
    e.preventDefault();
    var input = e.target;
    input.removeEventListener( "mouseup", __ignoreMouseUp, false );
  }

 function __addListeners( input ){
    input.addEventListener( "focus", __highlight, false );
    input.addEventListener( "mouseup", __ignoreMouseUp, false );
 }

 return function(){
   var input = document.createElement( "input" );
   input.type = "text";
   input.addEventListener(
     "blur",
     function( e ){
       __addListeners( e.target );
     },
     false
   );

   __addListeners( input );

   return input;
 };

}());

var s = selectaBox();
s.value = "This is some text."
document.body.appendChild(s);
Posted in CDOT, Mozilla, Seneca, Teaching Open Source, Web Made Movies | Leave a comment

End of Semester

Like many of my colleagues working in education, for whom the next few weeks are busy with grading students’ assignments or exams, I’m currently marking projects from my Mozilla Development course at Seneca.  I’ve been rereading student blogs and looking back at bugs, and started to see some common things emerging.  I wanted to share some of them.

The majority of my students worked on bugs in Firefox, specifically Gecko bugs related to the media element, DOM events, fullscreen, and pointer lock.  Because they were clustered together in similar areas of the code, they were able to help each other quite a bit, and talk with one another about struggles they were having, and celebrate when things got landed.  In general they each worked on 4-8 bugs, usually getting half of them landed by the end of the course, and therefore shipping in some future version of Firefox.  They ranged from Good-First-Bug type issues right up to full spec implementations, like Pointer Lock.

In no particular order, here are some of the observations I’m seeing again and again in their blogs:

  • Writing code to fix a bug is one thing, but getting the tests written, and passing on all platforms, is often much, much harder
  • You can’t measure a fix in lines of code (loc).  Often a tiny fix can take dozens of hours to do, since you first have to diagnose the problem, figure out where things are going wrong, and plan how to solve it.
  • It’s important to learn how and when to ask for help.  Trying to go it alone will end in tears and wasted time.  A well timed, intelligent question can short circuit your development time significantly
  • Similar to the above, it’s easy to not ask for help because you think people will look at you like an idiot for asking such a simple question.  In reality that never happens, and people are very helpful.
  • It’s not uncommon for a patch to go through a dozen (or two dozen!) versions on its way to shipping in Firefox: fixing a bug is only part of the process.  Reviews take time, testing takes time, landings (and backouts!) take time.
  • Working on large, complicated code like Mozilla helps keep you humble and aware that you don’t know everything
  • Keeping a patch up-to-date with trunk, as it goes through reviews, can be frustrating.  Code that used to work, stops working; things you relied on change, or vanish.  You have to build in time for this in your development plan.
  • Getting things fixed and landed is really about being patient and not giving in too quickly.
  • Fixing bugs in Firefox gives confidence to go work on any other code bases
  • Until you’ve done this work, you have no idea how easy it is to say, “Why doesn’t Firefox just fix X?” and how hard it is to actually do in practice.

The other thing I’m reading again and again is that people feel a sense of pride, accomplishment, and increased confidence for having worked on Firefox.  Those are exactly the kind of outcomes I want in this class, and with this experience.  It’s not possible for me to guarantee it, so when it does happen, it’s rewarding to witness.

I’m indebted to many people in the Mozilla community who helped my students find bugs, did reviews and offered feedback on patches, helped late at night on irc, and generally were there to help my students succeed.  There are too many names to list, but I want to centre out Olli Pettay, Chris Pearce, and Jared Wein, who really went above and beyond.

This is my 7th year taking undergraduate students into the Mozilla community and having them work on real bugs.  It continues to inspire and excite me.  I would also say that things have only gotten better within in the community in that time period, in terms of Mozilla’s willingness and preparedness when it comes to welcoming new (student) developers.

I’m looking forward to doing it all over again in September.

Posted in CDOT, MoFoDev, Mozilla, Mozilla Education, Seneca, Teaching Open Source | 11 Comments

Sadness for North Korea

For reasons I don’t fully understand, I’ve spent a fair amount of my reading time over the past month educating myself on North Korea.  During the past few years I’ve become aware of my ignorance about the issues surrounding the country and its people, and I don’t think I’m alone.  It’s been something I wanted to fix.  Above all, I’ve been interested to understand how a situation like North Korea could come about at all.  It seems unfathomable that a people could become enslaved and exploited by its own leaders, leaders who simultaneously install themselves as gods and destroy their “worshipers.”  And yet because it has happened, and happened so successfully, I feel that I need to understand it in order that I might guard against it in my own civilization, community, and life.

To that end I started reading.  My first two books were both about North Korea’s infamous concentration camps.  Blaine Harden’s “Escape from Camp 14” is a shocking retelling of Shin Dong-hyuk’s birth, life, and ultimate escape from one of the more brutal camps.  I had finished the Hunger Games trilogy some weeks previous, and tweeted that this book, the “4th in the Hunger Game series,” is by far the most brutal.  What upsets so many parents and school teachers in the Hunger Games novels, the way its sadistic narrative so easily and compellingly flows, is similarly present in Harden’s book; the only difference is that this isn’t fiction.  Here we encounter a child born to parents with no time or energy to love him, who view him as competition for food, who he can no more trust than hoped to be trusted by, with punishment, relentless indoctrination, hard labour, murder, death, and impossible living conditions taking the place of childhood, education, life, and hope.

From Harden’s book I went to “The Aquariums of Pyongyang,” which is Kang Chol-hwan’s account of life in another of the camps.  What compelled me to read another account was that, unlike Shin who had been born into slavery, this account was about an affluent family who found themselves on the wrong side of the government’s suspicions.  The two men couldn’t have been more unlike in their station and backgrounds, and yet their fates were similar.  Laying the two accounts beside one another, and listening to the echoes of the horrors experienced by each man, it was shocking and terrifying.  Instead of some historical document with enough distance in time to erase the hardest lines of the picture, these men talked about the same period in which I grew up.  While I was a child here in the west, these men and their families were suffering unspeakably.  We aren’t only talking about something that happened, but something that’s happening still today.  I am deeply saddened at the thought of so many hundreds of thousands still held in these camps.

Finally I had to know more about what made this all possible, and I turned to Bradley K. Martin’s “Under the Loving Care of the Fatherly Leader: North Korea and the Kim Dynasty.”  This is a massive book, but very engaging.  I am still in the midst of it, and would highly recommend it to anyone willing to spend some time really digging into the history of North Korea’s leadership and culture.  His research and journalistic style make this both informative and engaging.

I’m not going to write about North Korea, since I don’t know enough to provide good information.  But I wanted to recommend these books for anyone who is interested in learning more about the country, its people, its past, and its future.  It’s important that we in the west do more than simply laugh at parodies of the Kims, become distracted with talk of failed rockets, or make fun of the acts of the leaders; behind them, well hidden from view, are a people under terrible oppression who deserve much more.

Posted in Reading | 1 Comment

On the long game: a 20 year web page

I read a great tweet today, which prompted me to write about an idea I’ve had for a while:

It was by Gary Bernhardt, and the fact that I feel the need to post a picture of it, in addition to linking, is a great segue into my thought.

I’ve been trying to imagine what a contest to create a web page (app, ???) that will still work in 20 years might look like.  We have no shortage of contests to build things which use cutting edge APIs or to abuse and test the limits of existing implementations.

But what would it mean to write something that has to work for the next 20 years?  I’m picking the number 20 out of the air, swap in whatever number means “longer than the next 3 years” to you.  At first you might think that the best bet is to do something safe, wherein you rely on the bare minimum of what the web can do now, with the expressed hope that it won’t change.  That’s fine, but it’s not what a contest would hope to achieve.

No, a contest to build 20-year web pages/apps/??? would aim at producing something which did do things, and did them well not only today, but tomorrow, and the day after that, without having to be constantly maintained.

Further, participants in such a contest would have to think not only about technology, but also content, since anything that you are making for the next 20 years has to continue to be relevant during that same period.  It becomes a contest about judgement, history, and trajectory.  Even how we might judge it would be interesting, since, in the end, only time will tell.

So we’re talking about some hard problems to solve: make something that can last, technically, contextually, aesthetically, functionally (I’m sure you’ll instantly spot more -ally’s I’ve forgotten) for 20 years.  Could you do it?  Could anyone?  It’s also interesting to consider if it’s possible for such an exercise to not affect the development of the web itself, especially if such a contest were successful and the pages became a set of test cases for browser vendors.  I find the million “what ifs” of this problem fascinating.

I’d be interested to see it happen, and what people would do to approach the problem.  It’s a very different problem from the ones we typically worry about right now when we make things for the web; and yet maybe it shouldn’t be.

What do you think?  What are the problems, and solutions?

Posted in CDOT, Mozilla, Mozilla Education, Seneca | 11 Comments

You can

Dad, I don’t think I want to learn this song for piano this week.

How come?

Well, it’s scary.  Look at the picture.  Look at the words.

Why don’t you change it?

I can do that?  I’m allowed?

Get your pencil crayons out and change it

So I can change the picture and the words?

You can.

Dad! Look at this awesome song about Sam the Clown!

Posted in Home School | Leave a comment

Two notes on books

1. eBook

For my birthday my wife bought me a Kindle.  Since then I’ve had a chance to read a number of books using it, and I wanted to say something about my transformation from anti- to pro-eBook.  The first thing to say is that I received a Kindle vs. a tablet.  I got what Jesse Brown has recently called “dedicated hardware” and not a multi-use device.  I spend my days working on all kinds of computers and in all kinds of computer programming languages.  When I read I don’t want to be there anymore.  It’s why I don’t read anything longer than a blog post on a computer screen.  I need to be present with the text, without risking that I might slip off the edge and fall into my editor, browser, or mail.

In this regard, my Kindle is wonderful.  It actually can surf the web (I ran Processing.js code on it!), but in such a clunky way that I’m hardly tempted to do so.  What it does really well is let me flip pages through a book.  And so do all the hundreds of books in our house.  So why bother with an electronic book?

A few things convinced me.  First, I have too many books, and because I like to read, I acquire them too quickly.  In short, I don’t want to store them anymore.  Some books I read more than once, and these I can see having in physical form.  For the rest, I’m enjoying not having to find a shelf for them.

Second, I’m tired of traveling and holding large books.  On a recent vacation, I took a bunch of books, some of them from the library.  It took room in our luggage, was something I had to worry about losing or wrecking, and since a few of them were large hard-cover books (library binding), they were unwieldy to hold.

The third thing that convinced me is that many of the books I want to read are free (I read lots of literature or otherwise public domain texts) and out of print.  This weekend, for example, I read Aristotle’s Ethics and Dicken’s Bleak House.  In both cases I went from, “I really wish I could read such-and-such,” to having it available on my Kindle.  In both cases the books were free.  When I’m buying a physical copy of either book, I care about the state of the binding, the typography, etc.  In eBook form, these things vanish.  A $40 edition provides me with no more pleasure.

I’m enjoying the ability to instantly access free books, and while I will buy lots of books as well, this alone will pay for the device in short order.

2. A Bag of Books

For my birthday my friend, Luke, gave me a bag of books.  A bag.  Where some friends would hand you a slim volume wrapped and with a dedication, Luke handed me a shopping bag full of 11 books.  “You mentioned that you were looking for things to read, so I thought I’d get you started.”  Because I love lists, and would enjoy stumbling on something like this myself, I wanted to present the list of books he gave me.  Imagine if you could ask a great reader what they’d recommend you read over the coming months.  This is that list:

  • “The Sunlight Dialogues” by John Gardner
  • “The Club Dumas” by Arturo Pérez-Reverte
  • “Captain Alatriste” by Arturo Pérez-Reverte
  • “The Fencing Master” by Arturo Pérez-Reverte
  • “The Pyramid” by William Golding
  • “The Spire” by William Golding
  • “Briefing for a Descent into Hell” by Dorris Lessing
  • “Ficciones” by Jorge Luis Borges
  • “The Unbearable Lightness of Being” by Milan Kundera
  • “Blindness” by José Saramago
  • “Staring at the Sun” by Julian Barnes
Posted in Reading | 2 Comments

Elsewhere and Otherwise

One of the great difficulties I have in teaching is in trying to help my students understand the importance of narrative and personal reflection in their work.  I routinely see people doing amazing things, but being unable or unaware of the significance of what is happening.  Because it is happening to them at all they assume it to be ordinary.

I remember very clearly a moment in my 18th century literature seminar in grad school.  One of my fellow students was giving a paper on the importance of gardens in a text, speaking about an exotic plant identified by the author.  Our professor–a tweed jacketed, umbrella toting Englishman–interrupted: “What makes you think it ‘exotic’?  These grow all over England!  The author is writing about a common, not exotic plant!”

When you write, write about what is common, and more, what is common to you.  Don’t imagine that your own story is uninteresting for simply being your own.  Because the common, and in particular, your common experience is what produces the exotic for another, take the time necessary to examine your own surroundings, movements, interactions, relationships, and experiences.  To do so is to become aware of, and so accept your own individuality.

Posted in CDOT, Idea Factory, Seneca | Leave a comment

Required Reading

I refuse to assign text books for my courses, which is likely something I should discuss at some point–the cost, the unethical practices of the industry producing them, the issues of copyright, but most importantly, the fact that they can’t possibly keep up with how fast and frequently I need to alter my heading as I go.

There is one topic that I’d love to see all my students come in knowing, however: the proper use of Unix command line tools for text manipulation.  Today I stumbled on a great little guide, and I’d recommend you read it, then read it again.  I couldn’t function without this knowledge, and believe me when I tell you that without it, you’re not as powerful as you might, and should be.

Posted in CDOT, Home School, Mozilla Education, Seneca, Teaching Open Source | Comments closed

Next-Next Generation Web Making

This year one of the main focuses of the Mozilla Foundation is to enable web makers through the creation of software, tools, education, and community.  I’m helping lead the software teams that are building things like Popcorn, Popcorn Maker, Badges, Gladius, etc.  Mark’s done some good writing and talking about what web making means, as we work toward a point where it’s possible to say “everyone is a webmaker.”

Often when people talk about making things with the web, what they really mean is making web-things.  When I first learned HTML in the mid-1990s, I struggled to find good learning materials.  A friend explained that I was doing it wrong and that the web’s favourite subject was itself: “If you want to learn about how to use the web, look on the web.”

A lot has changed since then, and the web is no longer just a place for geeks.  As a result, web making is no longer just about making web pages–or shouldn’t be.  It’s easy to talk like this absent of real-world examples, which is why I was thrilled this week to find an example of the next-next generation of web making.

Here is an “app” created by Jessica Rosenkrantz and n-e-r-v-o-u-s.com that allows people to design, create, and order custom jewelry, which is then created using a 3D printer.  Watch the video they made, too.  It is made using Processing.js and WebGL.  Here’s some of what I think is important about a tool like this:

  • It’s built on the web and enabling web technologies.  I don’t have to install anything in order to start designing, which means I’m much more likely to do so as an amateur–I would never consider designing a ring or bracelet otherwise, I can promise you.
  • The changes I make are real-time, which allows play and experimentation to stand-in for deep knowledge of the process.  I don’t have to imagine what changing the roundness or thickness might look like–it’s right there in my browser as I do it.
  • I can learn as I go, since it’s not costing me anything (time or materials) to twist and contort the shapes.  The web is malleable in ways physical materials are not, and provides me with a wonderful environment to play and learn.
  • The algorithms used to guide the changes in shape, thickness, roundness, etc. free me from having to worry about making mistakes.  I’m able to play at the level of the overall form instead of having to worry about the individual lines and cells.  This is freeing when I want to work at a higher level of abstraction, and think in terms of the artifact instead of its constituent parts.
  • I can save, load, and share what I create.  It’s not just code that’s “forkable” anymore.  Being able to start where someone else left off, use a template for the beginnings of a design, or create a variation on a standard are important modes of creative work, especially as we learn.
  • I can have my design created using a 3D printer in nylon or silver.  I’m able to realize my design as a physical object.

Together that’s something like:

web technology + real-time + design + play + algorithms + sharing = making

This equation is key to moving the web forward as a platform for creation, and is worth keeping in mind.

Another thing I like here is the frictionless existence of design and commerce.  I didn’t have to buy this app to use it, and using it will be all many people will want–it’s very addictive.  However, one can also click a button and purchase what they’ve made, having it shipped to their home.  I can make something and show you, or buy it, and I don’t have to choose before I begin whether or not I’ll do either.

I love seeing people take our stuff (Processing.js, WebGL) and build cool things with it, and it motivates me to create even more powerful and flexible enabling technology.  Luckily we’re doing just that this year.

Thanks to n-e-r-v-o-u-s.com for showing us all how it’s done.

Posted in CDOT, MoFoDev, Mozilla, Mozilla Education, Processing.js, Seneca | Comments closed

International Women’s Day 2012

I was in a series of meetings today, led by my colleague Dawn Mercer, and paused to reflect on how important she is to the work I do at Seneca’s Centre for Development of Open Technology, and how big an influence she has had in the open source research we do internationally.

I remember first being introduced to Dawn about 8 years ago by a former chair of the department, Val Freeman.  Val pulled me aside one day to talk about some extra projects I was trying to get started with students.  She encouraged me to try and connect with Dawn in order to explore turning these into proper research projects.

Dawn has been a part of my Seneca life every since.  She and I have worked on countless grants since then, all of them designed to help students and faculty participate in cutting edge open source work.  I can’t tell you how many hundreds of hours she’s spent researching, writing, and administering grants in support of this work.  She’s made it her mission to attend trade shows, conferences, and meetings with the singular goal of furthering our work.  Whenever we’ve needed to find a way to hire a student for an interesting project, get equipment, or travel to the farthest reaches of the globe, she’s always found a way to make it happen.

I couldn’t do any of the work I love without her, and I’m not alone.  She has a passion for the research students we bring in to work in our lab, and over the years has formed many deep friendships with them.  Dawn’s been our champion for nearly a decade, and I’m thrilled to call her a friend and colleague.

On this International Woman’s Day, I want to recognize Dawn Mercer for her dedication and passionate support of CDOT and Seneca’s open source researchers and developers.  We are what we are in large part because of you, Dawn.

Posted in CDOT, Seneca, Teaching Open Source | Comments closed