Summary: Browser War panels have become predictable and non-informative. Instead they are there to entertain the audience but cause much more drama than good.

I go to a lot of conferences. I organised events, a conference and a few unconferences and I spoke at a lot of them. Lately I also stepped back a bit to coach people to speak instead of me going everywhere.

I think conferences should do a few things: educate, entertain, allow people to network and make speakers and experts available to attendees.

You don’t need to go to conferences to learn things – all the information is on the internet and signing up to a few good feeds, groups and lists will get you all the info you want.

What conferences do is bring the human factor into it. A good speaker can make a topic come to life and show you an angle you had not thought about and inspire you to play with it. A good workshop gives you guidance how to use a technology and gives you a way in without being overwhelmed by a big scary topic. A conference gives you time out from the day to day delivery and allows you to do things that are not yet on the radar of your company but might be soon.

And then there are “browser war panels”. The original premise of the browser war panels was that an audience could hear the latest and coolest about different browsers and ask questions. The first ones were held at Yahoo and had lead engineers from the different browsers to show how the different products work as that was dark magic back then.

HTML5 defines how a browser should deal with the content it gets – we have a lot more predictability already in the standard. A lot of great information on this topic is out on the web and the accelerated speed of delivery of browsers makes the appearance of platform engineers not happening much. There is no need to repeat the standards, instead the discussions are much more about what makes which browser stand out and in a lot of cases this means what the company wants to promote – not what developers want to use now and get stuck as it doesn’t work.

Browser panels these days get people from companies who are either product evangelists of the browsers or general tech evangelists, advocates, or – in the worst case – sales people. This could be good, they can point out features that are in the browsers people don’t know about and they can show some of the plans for the future of the browser. It can also be awful. As browsers are interesting to the media out of a sudden you see a lot of patterns being followed. Instead of giving information about the browsers, dealing with concerns of developers and implementers or showing changes panelists begin to fall into predefined roles and repeat the messages of the companies they represent.

It becomes predictable to see which company representative will value speed over everything else, which one will praise a great experience in the browser as part of a bigger OS experience, which one will talk about following standards and complain about sites blocking out browsers and which one will point out that the browser is the choice of the user and should keep them in control by being open about everything whilst following standards.

The bigger focus on browsers we have these days makes a panel much less of an educational part of the conference (many a time you will get “I have to go back to the engineering team for this”) but pushes it into the entertainment part of a conference. It is a veiled sales pitch.

Everybody loves a good drama. You could go as far as saying that we have a whole tech journalism market that lives on drama. It is fun to see people disagree on topics and make good arguments about one side or another.

A quite open, unscripted and unplanned format like a panel makes for great drama. It is easy to take potshots at each other and score browny points with the audience with pointing out flaws of the other browsers in a glib fashion. It also gives browny points with the audience to make sweeping statements or deliver soundbites.

Soundbites, being witty and fast are becoming the most important part. If you look at the Twitter stream of a browser panel you will hardly ever find a “oh feature $x will ship in browser $y – so cool” but you will get more “$x of browser $y just called $z out on the $a issue”.

Soundbites are also loved by the press. And as drama brings headlines many a time you will find a sarcastic remark or glib retort show up as “Company representative $x said $y about the competition”. A quick shot to get a giggle out of the audience can cause the communications team of a company to get a lot of unnecessary work. Is that worth it?

I’ve even been on panels where the organisers deliberately asked panelists to find topics to disagree on or seen panel moderators throw out one loaded question after another to entice people to disagree and get the drama going. We call this trolling or baiting, and not a way for conference participants to learn about what is going on in the browser world.

It is not hard to find what is going on in the browser world when you look at the open source engines. You hear much less about the closed ones and to me a panel that has no participant of Apple on it is not a “browser wars” panel as it lacks a massive player who should answer quite a few questions web developers have.

There are exceptions. I thoroughly enjoyed being on the panel at State of the Browser 2 in London and I think as there were no egos and no artificial drama we managed to answer quite a few questions from the audience. But on the whole, these are few and far between and many a “Browser Wars” panel is entertainment and cheap laughs or “wow, did he just say that” moments.

This, in the long run, is not fair to the audience who paid good money (and should get real comedians or entertainers if entertainment is the goal), it is not fair to the platform engineers (as they are misrepresented instead of allowing people to peek under the hood with them) and it does not get us anywhere in the real “browser wars”.

As developers you should not be tempted to build for one browser only and you should not have to build different versions for different browsers. Keeping it all about drama and who shouts the loudest and comes across as most witty doesn’t make that happen. It is a waste of time.

When writing documentation or doing examples you constantly run into the same issue: how do you display and demo the code at the same time? You don’t want to have a code display and live code as they will get out of sync (on the other hand I always found that when copying code into a document I also cleaned it up and optimised it).

The easiest way for this are all the “new” services like JSFiddle, JSBin, Dabblet, Tinker.io and others (there seems to be a new one every month now) and you can even embed them into other documents, but it means you need an iframe and load content from another service (which might go down or get forgotten in the future).

The other way of course is to use Ajax/JavaScript to load the code into the page. Back in 2008, I wrote the Ajax Code Display script for that (and subsequently I never used it much).

I was wondering how you can simply demo and show inline JavaScript in a document without needing any extra libraries. The simplest way seemed to read out the innerHTML of the SCRIPT element and write it out into a PRE using textContent (innerHTML would render HTML or greater signs in the script, which isn’t the idea).

However, you can do a simple demo and display of the same script much easier these days using CSS. Check out this demo page for an upcoming Smashingmag article:

If you do a view-source you find no other script in use, yet it displays in the page. What is this sourcery^*? Simple, and it was Mathias Bynens who got me onto it: just display script elements as block and add some generated content to show the “Source” text:

script {
  display: block;
  white-space: pre;
  text-shadow:none;
  background: #333;
  color: #fff;
  font-family: monaco, courier, monospace;
  padding: 10px;
}
script::before{
  content: 'Source:';
  color: #0f0;
}

Mathias has much more detailed explanations on why that works but I for one am once again amazed just how much easier things are these days with the awesome browsers that we have.

^* Sourcery = magical code that does (seemingly) unexpected things.

Conference organisers: I also made a shorter cheatsheet with all this info for you.

Hi, I am Chris,

I love public speaking – so much that I spent most of the last five years on the road (with an average of 37 conferences a year in over 30 countries).

I am also a very busy man (yes, my Twitter stream might make you think otherwise, but I am not kidding) and I am getting roughly 200-300 emails a day and about an offer to speak each day. This is not boasting, I am happy that people want me to speak, and I don’t want to disappoint anyone.

If you’d like me to speak at your event send me an email with the subject [Speaking opportunity]. Please include:

• The dates and location of your conference
• The nature of your conference (who do you target, how many people you expect, how many talks will be there)
• The nature of the talk (keynote, workshop, panel…)
• If there are any travel arrangements or not (more on that later)

Speaking Terms

I am a professional presenter with lots of experience. Therefore I want to make sure that there is no misconception about what I expect and deliver.

If I speak at your event I will:

• Deliver a fitting talk for the intended audience. I am happy to discuss content with you but I will not send slides for review and allow changes by conference organisers. I tend to deliver a unique talk every time I can and it will be an up-to-date talk. This can not be achieved if I need to send in the deck weeks in advance. Slides to me are wallpaper of a presentation and I treat them as such.
• Deliver the talk on time and stick to the defined format and duration. I need to know what time frame you expect and what format you want it to be in. I will show up at the times you need me to be there and set up on stage with enough time for AV people to wire up microphones and other equipment. I tend not to need any dry-run or setup, but I am happy to do so if that is your conference policy.
• Use my own computer to deliver my talk. Many times I will go beyond slide decks and show live code and examples. My setup is a Surface Pro or Macbook and I will bring my own dongle and remote control.
• Attend your event to mingle with attendees. I do speak because I want people to learn something. Therefore I will take part in your conference to be able to answer people’s questions before and after my presentation or workshop. I consider parachuting in and out of conferences and only mingling with other speakers a waste and unprofessional demeanor for a conference presenter. We’re not rockstars or actors who deliver a concert or play and leave. That said, I can’t always be there for the whole conference, especially for multi-day events. I’d appreciate a schedule where you really need me to be there.
• Promote my presence at your event. I will tweet and blog before, during and after the event about what I will do at your event and interesting things I encounter.
• Publish my slides and screen recording after my talk. If there is a good enough connection, this normally happens right after the presentation. Everything I create at your event will be licensed Creative Commons unless otherwise agreed.

I expect you to:

• Provide me with a prime speaking slot. I’ve proven to be a good keynote speaker and find interesting topics to open or close conferences. I also work well as a moderator or on-stage interviewer. I don’t feel I am used to the best of my abilities for your event when I speak to a half-empty room in a side track. I am happy to promote and remind people of side-track activities though.
• Deliver a professional stage setup. I bring my own laptop and connectors, but I expect at least a power plug and a microphone. I am very good with audio engineers (having been one myself) but I am not there to fix audio issues or set up projectors. I expect this to work and be available. I normally don’t need an internet connection, but would love to have one.
• Record and publish my talk. As each of my talks are unique there is no danger that people can attend one they already have seen on the web. Recordings are a great advertisement for your conference.
• If possible, I’d like you to cover my travel and hotel. I am on stage and need to be able to concentrate on that. I can not do so if I need to find lodgings and organise travel to your event in addition to presenting. I don’t expect first class or business class flights, but I do expect to arrive a day before the event and leave the day after with lodging organised in between. I do not want to book and pay myself and get reimbursed. International payments are a mess and I don’t have time to deal with paper work in between events seeing that I am presenting almost every two weeks. I am sorry if that sounds harsh, but I want to concentrate on my talks, not try to explain to the tax department what all these invoices are about.
• Keep me out of sponsorship discussions. I am at your event as Chris and to present. I will not “pay to play” and I won’t speak at sponsored speaking slots. I am happy to provide you with contacts of who to invite instead when we negotiated my participation. I am also happy to introduce you to company colleagues dealing with sponsorships, but this is not – at all – what I do. If you are looking for a corporate sponsoring to sell speaking slots, I am not the person you want.

All this is a lot of work, and beyond what is generally considered practice for presenters. Therefore I expect professional treatment by the conference organisers the same way I am professional about this.

Some of these are negotiable and depend on the nature of your event. For example I am fine to cover my own travel expenses for a single track, independent, not-for-profit event, but I don’t see a point in doing the same for a commercial multi-track conference with a high price tag on the ticket. If you make money, it is just fair to share the load. I go above and beyond my call of duty as a presenter and I’d like to see this being appreciated.

Deal breakers

I am an agreeable person when it comes to supporting events, but there are a few things I am not happy about:

• I will not deliver sponsored talks and I am not interested in being asked to speak so you can get my company to fund your event. I want my presence to be disconnected from any sponsorship. Paid keynotes are terrible for all involved, the 90s are over.
• I will not come to speak at an event that supports any kind of harassment or offers a platform to presenters who bully others
• I don’t pay to play. If I can’t justify my time and effort to my employer to come to your event then I can’t come. Unless I take holiday and then I expect to be fully reimbursed for my efforts
• I don’t support events that didn’t make a good enough effort to represent the diversity our market should have. I am happy to introduce conference organisers to people I support and know to be great presenters on my behalf

Web development is not what it used to be. It has undergone so many transformations and changes that it is pretty confusing to keep up with what is going on. My main problem right now is that as someone working for a player that provides the world with a browser and is involved in defining the future technologies of the open stack I wonder who our audience is.

There is no one “web developer”

I am a web developer. I build web products and I love how simple it is to create meaning with semantic HTML, interactivity with JS and make things beautiful and more intuitive with CSS. I come to this from a developer angle, as I am a terrible designer. This makes me an endangered species.

In the last few years web development has gotten a lot more players. Moving JS to the server side and the advent of Websockets, Node.js and technologies like Phonegap and Emscripten, and yes, even GWT allow a lot more people who never bothered with the web to build web apps. And this is damn good as different knowledge can lead to better and more scalable solutions. It also means we can deliver faster to a market that is hungry for more and more products. And it also forces us to re-think some of our ways.

I’ve talked to people who are amazing in HTML/CSS/JS and feel the need to learn at least one server-side language or at least get into patterns to understand what their colleagues in the web development team are talking about. It seems the shift from web sites to apps means that we need to shift much more to traditional app development than we are ready to admit yet.

Staying in our comfort zones

However, I don’t see much mingling going on. The design-y conferences of this world talk about “mobile first” and how responsiveness will always beat strict native apps and the tech-y conferences get very excited about replacing old-school web development with MVC frameworks in JavaScript and how to use JS to replace other server-side architectures. We’re stuck in a world of demo sites and showcases and “hello world” examples that can “scale to thousands of users per second” but never get the chance to.

I know, there are a few outstanding examples that are not like that and I generalise, but look around and you will see that I have a point. We get excited about the possibilities and revel in academic exercises rather than getting real issues fixed and showing how to deliver real solutions. This goes as far as discussing for days whether to use semicolons in JS or not.

Who is the audience?

But let’s go back to browsers and standards. I really am at a loss as to who we are talking to when it comes to those. Personally I see a lot of that in the feedback I get. Say I just gave a talk about HTML5 and what it does for us. Audio, Video, richer semantics, JavaScript APIs that allow us to draw and store data locally, all that. I normally end with something like GamePad API, Pointer lock or WebRTC to show what else is brewing. The feedback I get is incredibly polarised:

• Yeah, yeah, cool but why don’t you support the new experimental feature $x that browser $y has in the latest Nightly?
• That’s cool but I don’t like using your browser (my favourite, as it has nothing to do with the talk :) )
• This is all fine but none of my clients will ever need that
• Great, but I can not use this as all my clients use browser $shouldhavedied and will never upgrade

Now the luddite fraction of this has a point – a lot of what we show when we talk about “the bleeding edge” can only be used (for now) in Nightly releases of browsers or need certain flags to be turned on. In some cases you even needed a special build of a certain browser (like the GamePad API in Firefox or Adobe’s first CSS regions proposal). This means we do expect a lot of investment from our audience for something that might change or be discarded in the near future.

The “ZOMG YOU ARE SOOO BEHIND” fraction has a point, too – if they put their money where their mouth is and really use these new technologies in products rather than just getting excited about getting something new and shiny every week. Otherwise this is just borderline trolling and doesn’t help anybody.

Getting the bleeding edge into the mainstream

The question then is how could we ever get the new technologies we talk about used and implemented? There is no doubt that we need them to make the web the high fidelity app platform we got promised when some company arrogantly proclaimed Flash to be dead. But who will be the people to use them? In a lot of cases this only happens inside the companies that drive these technologies or by partners these companies pay to build showcases to prove that things could be amazing if we just started using new tech.

To me, this is not scalable and sad. We should be innovating for the people who build things now and not for a future that needs to come. This is less sexy and means a lot more work but it means we build with our audience rather than trying to lure them to change.

If you keep your eyes open then you see that actually a lot of what we consider amazing work is a very small percentage of the market. Tech press loves to hype them up and companies love to (pretend to) use bleeding edge technology to attract tech talent to work for them, but the larger part of the market wants one thing: getting the job done.

The majority of developers use libraries and frameworks

In the case of the web development this means one thing: libraries and polyfills. Yes, the things we considered a necessary evil to be able to build things fast and still support outdated browsers are now the thing people use to build web products. These are also the things they tell others to use – try to find a question on Stack Overflow that has no “use jQuery” as at least one of the answers. Try to find a CSS example that supports various prefixes rather than pulling a “this works only in webkit” or “use Less, no, use SASS, no use SMACSS...”.

Abstracting away the need for basic knowledge

Talking to colleagues and peers in other companies I hear a lot of moaning and complaining that it is impossible to hire real JavaScript developers as 90% of applicants come in and only know jQuery. They have no clue what an event handler is, how to navigate the DOM or create a simple XHR call without the library. Ridiculous? Not really – we are actually to blame.

The “in-crowd” scene has a fetish for abstraction. Instead of building applications and solutions we build more libraries, micro-libraries and polyfills to abstract the evil away from implementers and then we are surprised if implementers don’t know the basics any longer. Well, they used the precious time they had to learn what we build and started getting things done. And this learning time multiplies with the amount of things we release. The hour learning backbone, SASS, LESS, hammer.js or whatever is gone and should be used to build things with it now. All the more despicable when as the “cool kids” we just drop those libraries a few months later and build the next big thing.

Shouldn’t we innovate with existing libraries?

The question I am asking myself right now is this: when most of the market uses libraries to get their job done, why do we bother assuming that people would go back to writing “native” code for browsers – especially when we fail to produce standards that do not differ across browsers?

Wouldn’t the better way to get something done to build jQuery plugins that use the new APIs we want people to play with in an unobtrusive way and see real applications built with them? A great example are performance enhancements like requestAnimationFrame and pageVisibility. We can whine and complain that libraries are horrible and especially on phones drain the battery mercilessly or we could just start playing where our audience hangs out and improve where the errors happen rather than pointing them out.

Of course some things need us to find people to play with tech outside the libraries but a lot could be sneaked in without people knowing and then allow us to show real examples where a plugin that uses a new feature made an older implementation perform much better.

I’ve tried to do this with my talk at jQuery UK earlier this year. I showed the JavaScript equivalents of jQuery solutions and that browsers now have those and how following their ideas and principles could lead people to write better jQuery. I got good feedback so far. Maybe I am on to something.

Drop me an answer on Google+ or Facebook’s HTML5 group.

This cost me far too much of my time yesterday night: I had reconnected my Android Tablet (Galaxy 10.1) after running out of battery for quite a while and connected to my wireless and surfed the web – all fine – except for “certificate errors” on a few pages. This is nothing new, SSL is broken far too often sadly enough.

When connecting to the Market to download new apps or get my Google Mail or Reader items it always told me though that I was offline. Looking at Android forums I got a lot of wrong advice like “Going back to Best Buy”, “Deleting cache and force-stopping Market and rebooting the device” or “doing a factory reset”.

The fix is simple:

If your Android tablet throws certificate errors when surfing and can’t connect to the market, your time and date are wrong and set in the past. This breaks the SSL negotiation. Simply fix time and date and it works without you losing data.

This should be part of the error message when you get certificate errors.