Articles for December 2010

HTML5 is a necessary evolution to make the web better. Before the HTML5 specs were created we used (and still use) a hacked together bunch of systems meant for describing and linking documents to create applications. We use generic elements to simulate rich interaction modules used in desktop development and we make assumptions as to what the user agent (browser) can do for the end user.

The good thing about this mess is that it taught us over the last few years to be paranoid in our development approach – we realised that in order to deliver working, accessible, maintainable and scalable systems we have to be professional and intelligent in our decisions and especially in our planning and architecting.

The trouble is that with the excitement around the cool new HTML5 things to play with a lot of these principles get lost and discarded as outdated. They aren’t – part of the mess that the web is in is that in 1999 a lot of people discarded everything else and instead worked only on the new hotness that was Internet Explorer 6 and DHTML. Let’s not repeat that mistake.

The two faces of HTML5 enthusiasm

Right now there are two things to get really excited about in HTML5: the richer, more meaningful semantics of new elements and the APIs that give us deep access into the workings of the browser and the operating system. The former allows us to build much richer interfaces and the latter allows us to build much more complex applications.

All of this comes with the awesome of view source (or check in development tools) for debugging. You can advocate HTML5 by writing clean and useful markup. You can kill it by treating the markup as a second class citizen which is only there to serve the script.

The markup enthusiasts are very happy about HTML5 and make it easy for people to upgrade – lots of cool new blog templates and boilerplate HTML templates are being built and polyfills created to allow using the new features and not leave behind outdated browsers.

On the app development side of things it looks much different and that is just sad. My only possible explanation is that people who come from desktop environments now tackle the HTML5 APIs without ever having to care about markup. The pragmatism of HTML5 allows a much more forgiving syntax than XHTML but it shouldn’t mean that we can just re-apply all the bad mistakes that held us back when it comes to maintenance for years.

During my career as a web developer I realised a few things make a lot of sense when building web apps:

• If there is an element for a certain task – use that one. It is very likely that the element comes with accessibility and interaction features for free that you would otherwise have to simulate.
• Separate CSS, JavaScript and HTML – which means it is easy to refactor your code without having to change all of them. It also means you can work in parallel with others instead of breaking each other’s code
• Never rely on markup or content – as sooner or later some editing tool will come into place that messes with everything you created

This means a lot of things:

• For starters it means that inline styles are simply evil as they override any settings you have in your style sheets. Only use them when this is exactly what you need to do or when you calculate them dynamically.
• The same applies to inline scripting. If you have an onclick="foo()" somewhere in your HTML and foo() changes to bar() you have to rename it in every HTML document (of course nowadays it is one template, but it still means hunting down a reference you might miss)
• If instead of using a native HTML element for a certain job you use SPANs and DIVs you’ll have to add classes to make them look and work – and simulate the keyboard accessibility, too.
• You can’t rely on the text value of any element. A <button>edit</button> using the “edit” as the trigger for certain functionality would have to have the JS localised, too when you create the German <button>bearbeiten</button>.

Bla bla bla… C’mon Chris, it isn’t that bad!

The above best practices have been mentioned for years and a lot of people get sick of seeing them repeated. After all, this is intelligent development and standard practice in backend technologies. I came across a lot of “creative” uses lately though when doing a view-source on HTML5 demos – specifically the ones in the HTML5 advent calendar. And here is my yield of what people do.

Simulating a navigation list

One of the first things I encountered was a painting tool that had a gallery of created graphics as a background. Now, to me this would be a simple list:

<ul>
  <li>
    <a href="{link}">
      <img src="{src}" alt="{title}">
    </a>
  </li>
  [...]
</ul>

The markup I found though was this:

<div id="sky">
  <div class="skyTile" style="{calculated styles};display:block">
    <img class="skyThumb" src="{src}" style="{generated styles}">
    <img src="images/thumb_dropShadow.png" 
         class="skyThumbShadow" 
         style="{generated styles}">
  </div>
  [...]
</div>

This, of course is generated by the backend. My first gripe is the dropshadow image, after all this is an HTML5 showcase – just use CSS3. We also have the three instances of generated styles and double classes. Granted, an extra class gives you a handle to all images instead of tiles, so why not. But as there is no real link around the image, the click handler has to read the url from somewhere. There is a lot of unnecessary back and forth between DOM and scripting here which does slow down the whole demo. Seeing that this is also the main navigation from the entry page to the editor this could be a list inside a nav element. A list groups these items together, a bunch of DIVs doesn’t (screen readers for example tell you how many items there are in a list).

Another list I found was supposed to be links to refresh the app and have a hierarchy but instead was a flat list with classes to define hierarchy and group:

<ul id="mitems">
  <li class="hedtop">Simple</li>
  <li class="mol">{name}</li>
  [... repeated ...]
  <li class="hed">{parent name}</li>
  <li class="mol">{name}</li>
  [... repeated ...]
</ul>

This could be OK, granted you also shift keyboard focus, but why not:

<nav>
<ul id="mitems">
  <li>{parent name}
    <ul>
      <li><a href="{url}">{name}</a></li>
      [... repeated ...]
    </ul>
  </li>
  [... repeated ...]
</ul>
</nav>

This would give you styling hooks and functionality for free. Links and buttons are great to trigger functionality – but it seems that is too easy.

Click (probably) here for functionality

If I build a button for an application to trigger a certain functionality this is the markup:

<button type="button" class="edit">Edit</button>

Buttons are what trigger functionality – both a backend script or a JavaScript. They are keyboard accessible, have a disabled state and sensible out-of-the-box styling that nowadays can be completely overwritten. The class can be the definition of what the button should do – instead of the text which will change. You could use an ID but a class allows to repeat buttons (for example on the top and the bottom of a results list).

The buttons I found though were slightly different:

<div id="homeButtonPanel">
  <div class="homeButton" id="drawHomeButton" 
       style="display: block;">
    <p>Start Drawing</p>
  </div>
  <div class="homeButton" id="viewHomeButton" 
       style="display: block;">
    <p>View the Mural</p>
  </div>
</div>
 
<div id="controlPanel" style="display: block;">
<div class="titleButton"><p>{title}</p></div>
  <div class="mainMenu">
    <div class="mainButton mainSelected" id="drawButton">
      <p>Draw</p>
      <div id="inkDisplay">
        <div id="inkMeter" style="width: 94px;">
        </div>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="behaviorsButton"
           style="display: block; opacity: 1;">
        <p>Gesture<br>Behaviors</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="artworkButton" 
           style="display: block; opacity: 1;">
        <p>Artwork</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="resetButton" 
           style="display: block; opacity: 1;">
        <p>Reset</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="undoButton" 
           style="display: block; opacity: 1;">
        <p>Undo</p>
      </div>
    </div>
    <div class="menuContainer">
      <div class="menuButton drawMenuButton" id="saveButton" 
           style="display: block; opacity: 1;">
        <p>Save</p>
      </div>
    </div>
  </div>
  <div class="mainMenu">
    <div class="mainButton" id="viewButton"><p>View</p></div>
  </div>
  <div class="mainMenu">
    <div class="secondaryButton" id="helpButton"><p>Help</p></div>
  </div>
  <div class="mainMenu">
    <div class="mainShare shareButtonSmall" id="mainTwitterButton">
      <img alt="twitter" src="images/twitter_icon.png" 
           style="opacity: 0.6;">
    </div>
    <div class="mainShare shareButtonLarge" id="mainFacebookButton">
      <img alt="facebook" src="images/facebook_icon.png">
    </div>
    <div class="mainShare shareButtonSmall" id="mainEmailButton">
      <img alt="email" src="images/email_icon.png" style="opacity: 0.6;">
    </div>
  </div>
</div>

So instead of using a nested list with classes for each button and the hierarchy in the nesting we have a lot of classes and a hand-rolled DIV construct. Instead of making buttons really disabled we rely on opacity and there is quite a mix of inline images and background images (if all were background images, they could be one sprite!). Keyboard navigation will have to be written for this and if you were to add a button you’d have to come up with another ID.

HTML5 actually has a construct for this. There is a menu element with command child elements. These are in use in Chrome’s side bar for example and should be what we use. If you want to make it work for everyone, a nested list with button elements is what to go for.

The overly complex DIV construct is quite used though – this was another example:

<div class="uiScreen" id="startScreen">
  <div class="panelBackground" id="mainResumeButton" style="display: none;">
    <div class="largeUIButton" id="resumeButton">Resume Game</div>
  </div>
  <div class="panelBackground" id="mainStartButton">
    <div class="largeUIButton" id="startButton">Start Game</div>
  </div>		
  <div class="panelBackground" id="mainHelpButton">
    <div class="largeUIButton" id="helpButton">Help</div>
  </div>
  <div class="panelBackground" id="mainHighscoreButton">
    <div class="largeUIButton" id="highscoreButton">High Scores</div>
  </div>
</div>

When in doubt – add an ID and class to everything.

Other buttons I encountered were actually links pointing to javascript:// using an inline style to indicate hierarchy:

<ul class="navlist">
  <li><a id="play" href="javascript://" 
         style="display: inline;">Play</a></li>    
  <li><a id="pause" href="javascript://">Pause</a></li>
  <li style="padding-left: 2px;">Effects:</li>
  <li><a id="bw" href="javascript://">Bw</a></li>
  <li><a id="outline" href="javascript://">Outline</a></li>
  <li><a id="color" href="javascript://">Color</a></li>
  <li><a id="invert" href="javascript://">Invert</a></li>
  <li><a id="matrix" href="javascript://">Matrix</a></li>
  <li><a id="old" href="javascript://">Old</a></li>
</ul>

Talking of inline – here’s a great example of a tool generating a lot of code that could be replaced by a single event handler and event delegation:

<div id="tools">
  <span onmouseout="buttonOut(1)" onmouseover="buttonOver(1)"
        onclick="buttonClicked(1)" id="button1" class="button">
    <img alt="" src="image/button/1.png">
  </span>
  <span onmouseout="buttonOut(2)" onmouseover="buttonOver(2)"
        onclick="buttonClicked(2)" id="button2" class="button">
        <img alt="" src="image/button/2.png">
  </span>
 
  [...repeated 20 times...]
 
<div id="toolsSeparator">&nbsp;</div>
  <a title="" id="toolbarButtonSave" class="toolbarButton"
     href="javascript:saveCanvas()">
    <img alt="" src="image/save.png">
  </a>
  <a title="New" id="toolbarButtonNew" class="toolbarButton"
     href="javascript:newCanvas()">
    <img alt="New" src="image/new.png"></a>
  <!--[if !IE]><![IGNORE[--><!--[IGNORE[]]-->
  <a id="toolbarButtonMenu" class="toolbarButton"
     onmouseout="closeMenuDelay()" onmouseover="showMenuHover()"
     href="javascript:showMenu()">
    <img alt="&gt;" src="image/menu.png">
  </a>
  <div onmouseout="closeMenuDelay()" onmouseover="overMenu()" id="menu">
    <a class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvas()">
      save normal
    </a>
    <a class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvasHi()">
      save high quality
      <span class="footnote">&nbsp; (rename to *.png)</span>
    </a>
    <a onmouseout="closeMenuDelay()" onmouseover="overMenu()"
       href="javascript:showAbout()">
      about...
    </a>
    <a class="lastMenu" target="_top" onmouseout="closeMenuDelay()"
       onmouseover="overMenu()" 
       href="{url}">
      <span class="footnote">
        <em>elsewhere:&nbsp;</em>
      </span>
      <em>a sound memory game</em>
    </a>
  </div>
  <!--<![endif]-->
</div>

Notice that if the images for the button couldn’t be loaded for one reason or another (or you can’t see them at all) this application is very confusing indeed – no alternative text for the images and no text content to fall back to. I am also very much sure that the in and out handlers trigger visual effects CSS could handle better.

Reasons and effects

I know there are probably good reasons for all of this, and I am sure I will also do things wrongly when I am rushed or want to get things out quickly. What we have to understand though is that right now we have a responsibility to show the best of breed demos we can.

We cannot preach the open web and technologies and view-source over closed systems and at the same time forget the things we learnt in the last decade. Some of these things I found look like code Frontpage or Dreamweaver could have produced in the 90ies and resulted in a lot of badly performing, hard to maintain products that either still annoy people who have to use them or get replaced every 2 years.

We have a mandate to educate the new developers coming to the web. Unlearning something is much harder than learning it – so let’s not start with bloat and quick fixes that work but forget to advocate clean code and thinking about the impact your product has on the end users (thinking accessibility) and the poor sods that will have to maintain your product when you are gone. We are not here to advocate effects and products, we are here to promote the tools that allow anyone to easily build something cool that is also easy to understand.

HTML5 is about evolving the web as a platform – we also need to evolve with it and take more responsibility. We have app and we have markup enthusiasts. Let’s make them work together to build things that are great functionality and clean semantics.

This is a cross-post from the mobile team to invite web developers interested in mobile or add-ons to participate in the Mobile Add-ons Cup.

The Firefox Mobile Add-ons Cup has arrived!

Develop a mobile add-on for Firefox and showcase your innovation to millions of mobile users. We’re looking for compatible and innovative add-ons to extend Firefox on the Android and Maemo mobile platforms.

We’re looking for the best example in each of the categories below:

* Sports/Games
* Commerce/ Shopping
* Geolocation
* Productivity
* Sharing/Social
* Novelty/Innovation

We invite developers of all experience levels to participate in creating awesome add-ons for Firefox mobile. You’ll be rewarded with fantastic prizes and tons of exposure between now and January 7, 2011 when the contest wraps. Enter now and start creating your add-on today!

But Wait, There’s More!
We’ve got a serious panel of judges that include industry experts and mobile visionaries that will be judging the submissions and awarding a winner in each category. The prize for each category winner receives:

* $1000 in cash
* Android or Maemo phone of your choice
* Placement on the Firefox for mobile Start Page
* Showcased in a Featured Add-ons video distributed across Mozilla channels
* Blog post and Rock your Firefox spotlight

Of the 6 finalists, judges will also choose a Best in Show grand prize winner who will receive the above prizes, plus a full conference pass to Mobile World Congress 2011, plus 4 nights accommodation in Barcelona!

Early Bird Challenge
The Firefox Mobile Add-on Cup is packed full of exposure and prizes for add-on developers, but we have one more. If your add-on is submitted by December 17, we’ll send you a limited edition Firefox 4 Beta shirt!

Check the Cup site for more information, rules and resources to help you get started. Good luck!

Recent discoveries found that the protocol that Websocket works with is vulnerable to attacks. Adam Barth demonstrated some serious attacks against the protocol that could be used by an attacker to poison caches that sit in between the browser and the Internet.

This is a serious threat to the Internet and Websocket and not a browser specific issue. The protocol vulnerabilities also affect Java and Flash solutions. In a web environment that could for example mean that a widely used JavaScript file – like Google analytics – could be replaced on a cache you go through with a malware file. Google would not be to blame and it would be hard for you to trace where the file is from as it will not be on your server. To avoid a lot of malware showing up without being easily traceable we need to fix the protocol.

No Websocket support in Firefox 4 and Opera until the security issues are fixed

That’s why we’ve decided to disable support for WebSocket in Firefox 4, starting with beta 8 due to a protocol-level security issue. Beta 7 of Firefox has support for the -76 version of the protocol, the same version that’s included with Chrome and Safari. Beta 8 of Firefox 4 will remove that support. Anne van Kesteren of Opera also announced that Opera are dropping Websocket support. We are confident that other browser developers will follow.

What does this mean for developers?

Right now, your Websocket solutions will not work in Firefox 4 final. Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release. The code will remain in the tree to help development, but will only be activated when a developer sets a hidden preference in Firefox (the same applies to Opera).

If your code does proper object detection nothing should go wrong – when a user doesn’t have Websocket enabled the window.WebSocket property will not be available.

Working on a fix

Mozilla is still excited about what WebSocket offers and we’re working hard with the IETF on a new WebSocket protocol.

Right now we are pushing the boundaries of what browsers can do for their users – this is what HTML5 is about.

Whenever you push the boundaries of any technology you will run into issues. The great thing about our situation right now is that we can react quickly and swiftly to any issues arising and fix them before our end users are the ones who suffer. Making the whole world upgrade and patch a final browser is almost impossible which is why it makes sense to test and patch in betas and nightlies.

As you might know there are an incredible amount of advent calendar blogs out at the moment each delivering one cool article for each day of December until Christmas.

Today (6/12/11) two calendar blogs delivered an article of mine talking about the benefits of using local storage in browsers and how to implement it.

You can find the English version on the 24ways.org calendar and a German translation at the Webkrauts calendar.

In essence, the article explains why it is a good idea to use local storage, explains how to use it, how to work around the issue that local storage can only store strings and gives example code on how to speed up web service use by caching information client-side much like you would do it on a server.

Have a read and go speed up your own solutions by using what browsers provide you these days.

This is a cross-post from Dan Horner of our Add-ons team, who would like to invite any web developers interested in Add-ons and browser extensions in general to Add-on Con.

Hi All – wanted to use my first post on the Mozilla Developer Network blog to remind you all about Add-on Con which is taking place next Wednesday and Thursday (December 8th and 9th) at the Computer History Museum in Mountain View.

Add-on Con, as it’s name might suggest is dedicated to Add-ons, and is the only conference focused on Browser’s API’s. As one of the sponsors, we will be hosting Training Sessions on the 8th of December. Learn about Add-ons SDK and how to build restartless add-ons with Myk Melez. Jorge Villalobos will present a session on how to update Add-ons so that they’re ready for Firefox 4, and Mark Finkle will fill you in on everything you need to know about creating and porting Add-ons for Firefox onto mobile devices.

During the conference on the 9th of December, we will see Keynotes from multiple industry analysts as well as Justin Scott, who will present key learnings from across Mozilla’s Add-On ecosystem. There will be a presentation by Dave Townsend, Jennifer Boriss and Justin Scott, on Firefox 4 & Add-ons from a UX and technical perspective including the new Add-ons Manager. Justin will also present a session giving tips on how to make Add-ons that will delight users.

Finally our own Jay Sullivan, VP of Products will be on the closing keynote panel discussing the future of the browser.

It’s not too late to register for the conference and attend our training sessions!

Building Together Event with Mozilla

We are also having a social event on Wednesday, 8th of December from 5pm to 9pm, where you can let your hair down, and share your development experiences and ask questions with other likeminded developers and the team from Mozilla. The theme for the social event this year is around “building together” which represents our determination to help developers to continue to build Add-ons, brands, userbases, and presence on mobile platforms.

Join us for some food, drinks, activities and socializing, please RSVP here: http://www.meetup.com/addons/calendar/15494798/

Hope to see you all there!

Dan Horner
Product Marketing Manager, Add-Ons