Kenneth Auchenberg

I make stuff happen in the browser you didn't think was possible.

Introducing Helpmate.

| Comments

A few months back I was setting in Jacob Bøtter’s kitchen discusing what it would take to disrupt postal services and ultimately eradicate letters for good.

After a few beers we came up with something different. I recently moved to a new place here in Copenhagen, and been busy renovating the apartment. Jacob still has 20-30 things in his apartment that needed to be fixed, but he hadn’t had time to tell people to do it.

So how about an iPhone app, where you just could snap a picture of what’s needed to be done and it would be done?

We sketched out the concept, and created a little website with an introduction video. We are starting out in Copenhagen, and if enough people signup, we will make it happen.

We call the it Helpmate (in danish).

Visualize your JavaScript dependencies with dependo

| Comments

Update: grunt-dependencygraph has been replaced by dependo - a more modular version, wrapped up as a NPM-package with both an API, CLI and Grunt task.

It all started a few months back when I started our “AMDification project” at Podio, where we decided to introduce AMD in our codebase, in order to take advantage of tools like RequireJS, and r.js.

More importantly I also wanted to gain a better overview of the dependencies in our code, by being able to extract the module definitions and their dependencies in a systematic way. Using AMD has enabled this in a simple way, because much of the tooling already existed.

But for a long time I’ve been looking for a visualization tool to help me visualize the JavaScript dependencies - without any luck.

Okay, I found a few, but they use GraphViz, or similar, to generate huge images that is impossible to handle when you generate a graph of a larger code-base.

I want something better. Something similar to Google Maps, where you have a big graph that’s zoomable by mouse or gestures, combined with dragging, to enable panning when the graph is zoomed. I haven’t been able to find something like this, so I’ve taken the write it myself.

Let me introduce dependo. It’s a small visualization tool that draws an force directed graph of JavaScript dependencies that has been annotated with either CommonJS, or AMD. Behind the scene I’m using a wonderful library named node-madge, to extract the dependencies and combined with the power of D3.js I draw a beautiful zoomable directed graph.

It’s all wrapped up as a simple node-module, available on NPM, with both an API and CLI. I also written a grunt-task that can be found here grunt-dependo, so it’s convenient to hook into your grunt-build system. The output is a simple HTML-file, with everything embedded, so you can publish it directly to your build server, etc.

Enough talk. The best way to show something is by example, so here I generated a graph of the official RequireJS multipage example:

It’s still early days, but I think this tool will help developers getting a better overview of modules and their dependencies. I really hope you like this tool too.

Have an good idea, or wanna contribute? All feedback is highly appricated.

https://github.com/auchenberg/dependo

/K

Microsoft Campus Days 2013 talk

| Comments

Back in October last year, I spoke a Microsoft Campus Days 2012. A relatively small Microsoft conference in Copenhagen focused on the IT professional and developers.

I did a reality check of HTML5. How far we have gotten, and what problems we are facing with our web platform. I started out by asking how many people that were developers, and 99% of the attendes was developers. A good thing, but this was my first presentation without any code. So it was tough crowd, but I think people got my points, and the overall message.

The talk in danish, so if you understand my mother tongue, go ahead and watch my presentation (yes, sadly it’s Silverlight);

HTML5 - Where are we at?

| Comments

Last week I spoke at a Warm Crocodile Conference, a new by Microsoft in Copenhagen, and later the same evening at our CopenhagenJS meetup in Malmo, hosted by FooCafe.

My talk was about how far we are with our web platform - more specifically HTML5. I wanted to give a different talk then the usual “HTML5 buzz talk” that mostly has been about the fancy new features and possibilities we got with HTML5.

Instead I wanted to put HTML5 in perspective.

In my talk I talked about the evolution we have been though the past years, how the evolution has been driven by WHATWG, and W3C, and how we sometimes has ended up with weird evolution (as Christian Heilmann pointed out in this talk).

I gave an overview of the current browser landscape, how auto-updating has been introduced to the platform, and few examples on how far we are with actual browser support to highlight the shocking truth: We haven’t gotten that far the past many years, because older browsers are holding us back.

More specificly it’s older versions of Internet Explorer, especially IE8, the last upgrade-path for Windows XP users. In my talk I had the statement that IE8 is pollution, that holds us back from moving the platform forward. This thought was put in my head by Alex Russel, at last years Fronteers (2012) in Amsterdam, and has slowly grown on me.

This morning, my IE8 statement was picked up by one of the biggest IT media’s in Denmark, version2, who has written a wonderful article, with an even more brilliant photo of me (very ironic). Hopefully articles like this can kickstart the debate, so we, front-end developers, will unite and do something about IE8.

In addition I breifly touch the today’s browser tooling, and the lack of innovation in it, by showing how little we have innovated since the good days of IE5.5.

Lastly I covered the work that has been going on in the W3C Core Mobile Community Group, how it relates to Facebook, and what it means for the future.

Many of the subjects in this talk deserves a seperate blog posts, so instead of going into more detail, I’ve embedded the slides (yup, regular iframe), so go check them out, or find them on Github (HTML5 - Where are we at?)

/K

We need a open bug tracker for Internet Explorer

| Comments

The last weeks I’ve working on adding the last bits of IE10 support to Podio.

Today I had an issue with Drag & Drop using jQuery UI’s sortable. It was isolated to IE10, only when scrolling, so I started search to see if it was a bug within jQuery UI, jQuery or maybe even inside IE10.

In my search I first found a jQuery UI ticket, that lead me to a jQuery ticket “EVENT.PAGEX AND PAGEY HAVE INCORRECT VALUES IN IE10 ON WINDOWS 8 RTM”.

In this jQuery ticket, created 7 weeks ago, people are discussing the cause of this, and they confirm it’s a bug within Internet Explorer 10. The RTM version.

This jQuery ticket, didn’t lead me to a issue reported in the Internet Explorer bug tracker, instead it has this final comment:

“I heard back from Microsoft, they have a patch that will go out a few days after the official public release that will fix this issue. There’s no reliable marker that jQuery can use to tell fixed vs unfixed implementations, so your best bet is to tough it out until then.”

This is EXACTLY the reason why we NEED an open bug tracker for Internet Explorer. As a frontend-developer, need to know about these issues, because they affect how and what I’m building.

I want to know the open issues in any browser. What progress they are making, and most importantly when the fixes goes out. I can follow the status of bugs reported in Chrome, Firefox, Gecko, Webkit, etc, but where is the openness from Microsoft?

I don’t want to end up in a jQuery bug tracker to find out about bugs in Internet Explorer. They belong to it’s own open bug tracker.

I know there is a bug tracker for Internet Explorer (somewhere at connect.microsoft.com), but it’s really hard for me as a developer to follow what’s going in in IE, especially compared to the other browsers out there.

Microsoft, if you want us frontend developers support and build applications for your platform (IE), you need to bring us closer to your browser.

Openness is the necessary step forward.

Slides from “We do our own stunts” at LBI Denmark

| Comments

LBi Denmark asked me to stop by their internal event called “We do our own stunts”, to talk a bit about Podio.

In the context of doing stunts I thought the evolution of the Podio front-end stack would be a great fit. At Podio we have been through a big technical transition. We switched out our complete frontend stack from PHP to Ruby, while we continued to itirate and release new features in our product.

This was a bold decision and a atypical project, you rarely see in a startup. We didn’t have 6 months to set aside for refactoring. Instead choose to tacle this from a different perspective: We chose to look at this as a perfect opportunity to review all the features in the product. With this opportunity in our hands, the flow as actually straight forward. Everytime we added or improved a feature, we would implemented it in our new code-base, and make the transition completely transparant for our users.

Our goals with this project was to ensure a solid techinical platform that would enable us to keep our team productive, while growing. Be on the technical fore-front and have a great foundation to deliver the best experience to our users.

This was our “air-bourne stunt”. One hell of a trans-atlantic flight.

Read more about the project in the slides, Podio Frontend Stack Evolution

Word wrapping/hyphenation using CSS

| Comments

A few days back I spent most of my afternoon looking into how I could achieve proper word wrapping within elements with a dynamic width.

At Podio, we have a fluid layout, with a dynamic width, to deliver a responsive user experience. This means no element is having a fixed width, instead width’s are defined as percentages. This causes some headaches, now and then. Word wrapping caused a major one.

Initially I thought: It’s a no-brainer, just add word-wrap: break-word to the element, and it should do the wrapping.

It’s not.

When you have an element with a dynamic width word-wrap: break-word, isn’t having any effect. Today’s browsers don’t use the calculated width to enforce the wrapping. Instead they seem to ignore the declaration.

Wonders of a dynamic width.

In this example I used a generic layout for a two column layout, using table-cell and floats.

As you can see in this example, the long word isn’t wrapped into multiple lines, it breaks the layout. So how do we make it look more like this?

So what are the options?

In my research I found a lot of proposals on how to fix this issue. Most of them was a suggestion to add a fixed width to the element. Sometimes you need the dynamic width, like when you use the media-block from OOCSS, so what’s the alternative?

<WBR> and &#8203; tags

The past years I’ve been using <WBR> and &#8203; tags to insert optional line breaks into long paragrahs of text. This solution became quite made popular after Quirksmode, made documented it.

This technique is is widely used around the web, including places like Facebook. And there seem to be wbr-encode implementation for all major languages functions, but they all have one common problem. As soon you are outputting markup, and want to break up long words within tags it starts to get messy. To overcome this, it ends up in a lot of regex nightmare, and ultimately, a slow HTML parser, to ensure proper breaking.

This slows down rendering dramatically.

What about CSS?

Wouldn’t it be better, if the browser could do the work?

In my search for a working CSS declaration, I found word-wrap, which isnt working with a dynamic width, so I continued and found a new CSS3 declaration word-break, which is described as: “This property specifies line break opportunities within words.”

Great, so let’s try it out in a WebKIt-based browser:

Bamn, we got it. word-break: break-all; is the way to go for WebKit..

But then I fired up IE8 and Firefox, and realized that it didn’t work, so I continued my search…

It seems like the word-break declaration is prefixed in Internet Explorer 8 standards mode, so you need to add a prefix:

 -ms-word-break: break-all;
     word-break: break-all;

But what about Firefox? The Mozilla guys has chosen not to implement word-break support into Gecko. Instead they focused on supporting something new and exciting, the CSS3 Hyphenation specification.

CSS3 Hyphenation

Hyphenation is the better word-break. It’s locale aware, and inserts the hyphen character at the correct place, when breaking the words.

The support of CSS3 Hyphenation has started in Firefox 6 for the english languages, and several other langugages was added in Firefox 8.

It’s already supported in WebKit, currently prefixed, which means Safari 5.1+ and iOS 4.2.

CSS3 Hyphenation isn’t supported in Chrome, since Chrome doesn’t ship with any hypenation dictionaries, but since Chrome supports word-break: break-all; we are good.

To support hyphenation in Safari, Firefox (and future Chrome versions), you will need to do:

-webkit-hyphens: auto;
   -moz-hyphens: auto;
        hyphens: auto;

Webkit and mystic “word-break: break-word”

When using the word-break: break-all; property, is has the sideeffect, that words are being broken up at weird positions, because the break-all, means all words needs to be broken up.

An example of this looks like this:

To fix this, I discovered, that you can use word-break: break-word; which seems to be an undocumented and non-standard property value in WebKit. This makes the word wrapping behave like word-wrap: break-word, but works with dynamic widths.

As you can see in the above example, the word wrapping looks much better using word-break: break-word;. This leaves us behind with IE, which still would wrap the words at weird positions.

Luckely CSS Hyphenation is supported in IE10.

The solution

So the cross browser solution for doing word wrapping using CSS only is a combiation of word-break, word-break: break-word; and hyphens:

 -ms-word-break: break-all;
     word-break: break-all;

     // Non standard for webkit
     word-break: break-word;

-webkit-hyphens: auto;
   -moz-hyphens: auto;
        hyphens: auto;

This is working in Internet Explorer 8+, Firefox 6+, iOS 4.2, Safari 5.1+ and Chrome 13+.

The end result is simpler markup, and faster rendering, since we don’t need encode our strings with <WBR> and &#8203;.

Goodbye <WBR>, I don’t need you anymore.

Updates

I updated the article to include a section about word-break: break-word in WebKit. Added proper references to word-break: break-all;, and highlighted that CSS3 Hyphenation isn’t supported in Chrome. Thanks goes to Mads Kristensen and Baldur Bjarnason

Slides from my HTML5 & browser extensions presentation at ProData Consult

| Comments

Thursday last week (27th january 2010) I hosted a “evening-event” at ProData Consult for their consultants, where I spoke about HTML5 & Browser extensions. My HTML5 talk was a short recap of the recent changes in the specification, the W3C logo, and a showcase of the semantic changes, new tags and attributes and the HTML5-related JavaScript API’s.

The presentation was a bit of an experiment, because I was the first time I coded my presentation in HTML, JavaScript and CSS instead of using the regular tools such as PowerPoint or Keynote.

To “code” my presentation I used a small sinatra-based ruby app called ShowOff, which is using markdown for its templating.

The advantage of coding my slides is really obvious in my presentation where I show how the new form controls is being rendered, how HTML5 validation works, theres even an embedded google maps, canvas demo, pushHistory etc.

Normally I embed the presentation into the blog-post, using an embedded SlideShare presentation that is using flash, which allows resizing. But because I this time hardcoded the layout in HTML/CSS, then I’m not able to embed a resized version of my slides.

To see my slides (which is hosted on Heroku), just click the thumbnail below:

Diving into photography.

| Comments

Lately I’ve been quite hooked on getting a DSLR, because I wanted to explore the world of photography from another angle than just looking at beautiful pictures.

To begin with I started looking at high-end camera’s (top-model or no-model mentality), but after a lot of research I ended up buying a Canon 550d, which is also known as T2I or KISS X4. It’s very similar to Canon 60D and Canon 7D, but the main difference is the physical body, which is in plastic and is lacking some quite nifty navigation buttons compared to 7D/60D.

So why did I buy the 550d?

Of couse, if I had unlimited resoruces I would had bough the Canon 7D, simply because it’s “just nicer”, but I came to the conclusion, that this is my first DSLR, and therefore I could live with the lack of weather sealed body, and the nifty navigation buttons, simply because I first need to learn the very basics of photography.

So I decided to go for the Canon 550d body, but which lens should I buy? Should I go for the kit?

After some more research in various places I came to the conclusion that my first lens should be a prime in about 50mm. But since my 550d has a smaller APS-C sensor, it also has a crop-factor of 1.6, which means a 50mm lens would become 85mm on the 550d.

Therefore I ended up buying a Canon EF 28mm 1/8 USM lens, which is going to be equal 45mm on the 550d, got 1/8 aperture, and is using the EF-mount, which means I also can be used on the Canon pro-cameras (if I should end there some day).

The lens was a bit expensive 450$, but got some pretty good reviews, and the sample photos I found in the 28mm group in Flickr is simply stunning.

In addition to the 550d and 28mm lens, I also bought a filter, lens hood and a battery grip, so totally I ended up with

  • Canon 550D body
  • Canon EF 28mm 1/8 USM lens
  • Canon Lens Hood EW-63 II
  • Phottix Battery Grip for 550d
  • Hoya 58mm Pro-1D UV Filter

I’m still waiting for the lens, battery grip and filter to arrive, so hopefully when all the parts has arrived I’m going to be thrilled about photography ;)

New version of CSS Reloader for Chrome is out

| Comments

It has been a long time since I did changes to my CSS Reloader browser extension. This evening I had some time, and pushed a updated version of CSS Reloader for Chrome out in the public.

The new version contains a revised code-base, which is way more well structured and cleaner, and I also added som new features:

  • Much requested options-page has been added - allows you to change the keyboard shortcut.
  • CSS Reloader got a nice new logo (credits goes to Everaldo Coelho for the lovely icon.)

Technically  I was quite fun to add the options-page, because the settings is persisted in LocalStorage, which is only available for the background-pages in  the extension, and not the content-script that is injected into every tab. To expose the settings for the content-script I have taken advantage of the message passing implementation in Chrome, that allows the extension-parts to communicate using events.

Get the updated version of CSS Reloader for Chrome, or check the source-code out, to see the funky-ness