Improvements for the HTML5 Logo

If you followed my series on how to create an animated HTLM5 logo for a WordPress blog you may encountered some issues and things that can be optimized. This post will address some more advanced concepts like window resize handler, responsiveness and iteration monitoring.

Window Resize

The first and easy to notice problem is that the canvas is initialized only once. This means the logo’s width, height and position are calculated at the page load and remain fixed afterwards. However, the user can and will resize, minimize and manipulate the site for various reasons with the following result:

window_resize_stickman_o
The above picture shows that the canvas will stay on a fixed position whereas the site layout has changed. This result can be generated by loading the page in a shrinked window and maximize it afterwards. To avoid this we have to listen for resize events and react as shown in the following listing:

Small Screens – Responsiveness

Our stylesheet will change its set of rules based on different devices, leading to different page layouts. The underlying technique for this are media queries which is a core concept in responsive design.

“A media query consists of a media type and at least one expression that limits the style sheets’ scope by using media features, such as width, height, and color. Media queries, added in CSS3, let the presentation of content be tailored to a specific range of output devices without having to change the content itself.” Source: Mozilla Developer

media_query_o

Our canvas stickman logo was the same for all devices and screen resolutions, sizes etc. with the following effect:

logo_small_screen

The new gained responsiveness of our logo consists of three main parts:

  1. “Query” screen information
  2. Position the logo relative to the heading
  3. Use the transformation matrix instead of modifying the code

The most interesting part is that we shrink our logo when a certain screen width is reached. We save the transformation matrix before we do this operation and restore it after alle painting operations are completed. In order to know when all paint operations are completed we have to modify the animator. The new animator class is started with a callback which is executed when all animations are done.

More on transformations can be found e.g. on the Mozilla Dev Page.

Iteration Counter

The used requestAnimationFrame API has one big problem – it is smart which means whenever the user changes the tab, the next frame is not drawn, since it would waste CPU cycles. However, the first draft of the animator class used a duration for the animation which is counted down even if the frames are not drawn. To overcome this conflict an easy optimization is to add an iteration counter to the animator.

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload the CAPTCHA.