Category Archives: HTML5


12

Responsive Media

by Hans Christian CSS, HTML5, Mobile, Research

There is a big discussion going on at the moment covering the actual point of how to deal with images and media et al. on mobile-phones and other devices as there are some things that don’t work as on a desktop computer:

  • Bandwidth
  • Screen size
  • Performance / Velocity

The question is how to deliver responsive images on a mobile website.

You maybe use something like img { max-width: 100%; height: auto; } in your responsive design to prevent images from being bigger then the screen of a mobile device.

In most of the cases this shrinks images in its displayed size, which is a processor intensive thing to do – especially when you are on a mobile device and don’t have endless processor capacity this hurts.
The shrinking itself does not change the file-size that has to be loaded; it remains the same as on a desktop for example. As bandwidth is the bottleneck these days if you are on a mobile device, this is the issue where people want to see some improvement.

What can we do about it?

There are a couple of proposals and known techniques on how to solve the problem:

1. Resize images with PHP

This is something you could only do if you know the screen-size before you load the images them self. So you have to inject HTML through JavaScript for example and change the sources for images accordingly.

The Adaptive Images framework a similar technique. Check out the source on GitHub.

2. Request different images using data-attributes

An article by Nicolas Gallagher covers this method using CSS to detect which source would be best to use.

The method could work like this: You have an image which has a really small file size and is served for every device at first (mobile first approche).

<img src="image.jpg" alt="" data-src-600px="image-600px.jpg" />

Now you are going to change the file if the screen is bigger by using the content-property of CSS and its attr() function.

@media (min-device-width:600px) {
    img[data-src-600px] {
        content: attr(data-src-600px, url);
    }
}

Please have a look at the article for detailed information.

An idea that goes beyond the replacement of images with the attr()-function is the usage of content: url(myimage.jpg) replaced;. This is something suggested by Tab Atkins Jr. on the W3C www-styles mailing list – called replaced content.
Something about replaced content appears in the CSS-spec but it does not look to be exactly what Tab is referring to.

3. Introduce new attributes to the <img>-tag

Anselm Hannemann shares the idea of introducing a media-attribute that has some sort of “sizing-parameter”. It is supposed to be combined with the media-src-attribute which also has the sizing-parameter.
The HTML could look something like this:

<img src="myimage_xs.jpg"
media-xs="(min-device-width:320px and max-device-width:640px)" media-src-xs="myimage_xs.jpg"
media-m="(min-device-width:640px and max-device-width:1024px)" media-src-m="myimage_m.jpg"
media-xl="(min-device-width:1024px)" media-src-xl="myimage_xsl.jpg">

As you can see the media-attributes contain media-queries which describe when to take a certain image-source.

4. Using JavaScript

There are some ideas on how to deal with this topic using JavaScript.

The FilamentGroup for example published its “Responsive Images”-project on GitHub. They are using “Mobile-First” to present a small-sized image on every device and replace this with JavaScript on window load.
You can find out more about how it works on their blog. They also published a demo.

Peter-Paul Koch presented a possible way on how to combine media queries with JavaScript. Which is not really new I think but a good summery.

Another approach could be a new attribute for the script-tag: Scott Jehl suggested to call it preparse. The script could then be used to replace sources in HTML fitting the current client-need.

5. A new image-format containing different sizes

People aso had the idea of creating an own image-format which contains for example four layers with different image sizes. The image then “decides” which format to take and serves this to the client without its three sibling-layers.

At the moment there is a format called MrSID developed by LizardTech which can have one or more compression rates.

Another approach is the JPEG 2000 file-format. It can carry out different optimization-levels for images. Read more about it on the Wikipedia-page I linked above.

Media? But this was only about images…

Yup, right! Images are just one aspect when it comes to responsive media.
Videos for example are another thing. YouTube offers different video-sizes for watching. You have to choose manually which one to use. A possibility to select this resource automatically, build into the browser would be awesome!

JPEG 2000 has a video-equivalent developed by the same group of people as the JPEG-format called Motion JPEG 2000. Find more information about this here.

Conclusion

As it turns out many developers are not aware of the problems that come up with a real responsive design – even HTML5-specification writer are calling it “a niche problem”. This is why it is hard to develop a specification for a native API as for example Anselm Hannemann suggests.

But maybe the decision which technique might be best for solving the problem of serving responsive media has to be finished first before anything is spec’d up.

Moar!

Some more resources where the topic is discussed:

Thanks!

Thanks goes out to Anselm, for reading what I wrote and helping me with some further information.


0

A Travel Through Time – and Back

by Hans Christian HTML5, Research
times-back

Somehow… <time> Disappeared

As you might have heard the <time>-element was removed from the HTML5 specification last saturday by Ian “Hixie” Hickson, the editor of the spec. Hixie decided to remove <time> and replace it by the more general <data>-element.

A question that came up: Why got<time> removed and why did nobody stop Hixie?

Well: There was a discussion on the bug-tracker about replacing <time> with <data>. But nothing about it on the mailing-list and stuff… and Hixie decided to drop <time> and replace it by the power he has as the editor.

Not only <time> was removed from the specification but also its attributes datetime and pubdate. pubdate was the only way to indicate when a blog post or web-page was published.

As I'm not into the processes at W3C and WHATWG I decided to dig a little bit into it and keep track of what was going on about that issue with <time>.

Awesome Effects!

I collected some useful information and posted the links on Google+. Also we talked about this issue on the (german) podcast Working Draft on monday. I was invited by Christian "Schepp" Schäfer to discuss about some stuff with himself and Marc.

Steve Faulkner was the first one (for what I noticed) that tweeted about that intensively and was really upset by the dropping. Furthermore it was his tweet that encouraged me to keep track of the whole story.

Steve explained on the the mailing-list of the W3C why he likes to revert the changes made by Hixie the day before. Others also liked the time-element and requested a revert.

There were some pretty good blog posts about that topic, as for instance

As it turns out <time> is wildly in use all over the web:

  • the WordPress twentyeleven-theme uses it
  • The Boston Globe makes use of it
  • I'm using it on this page
  • And many others too…

As so many people where effected by the change that was made to the spec and many people though it was a bad decision there was hope that this story was not over yet… And it wasn't.

Again Steve Faulkner tweeted:

"I feel confident that <time> will be back in the W3C HTML5 specification by the end of the week"

~ Steve Faulkner, 31. Oct 2011 via Twitter

This was a decent statement as you can say by today.
There were proposals on how to deal with <time> and how to improve it for the future and get it back into the spec. A leading role in this process is held by Tantek Çelik. Read his comment on Bruce Lawson's post. Also Stephanie Sullivan Rewis has some interesting thoughts.

And then - the Turningpoint

Currently the TPAC 2011 is happening which is a conference and meeting of the W3C and its members.
At (Please notice my use of <time> in this case. Nice, right… right?) people of the W3C HTML Working Group met and discussed about <time> and its removal. You could have followed the discussion on IRC on W3C's channel #html-wg. Here you can find the "minutes" (a transcription) of it. Tantek added this as a point for discussion to the Agenda.

As this all was said, there was a mail on the mailing-list by the Chairs of the HTML WG asking the editor of the spec (Hixie) "for a revert of this change to be completed no later than the end of day on Tuesday 8th of November". If Hixie will not change this until Tuesday the Chairs will ask the W3C staff "to make this change". What ever this means then… I have no idea.

Today Tantek began to define some new requirements for the <time>-element and its attribute datetime (especially the syntax of the mentioned attribute).

So what's the conclusion now?

All the things I mentioned above show how strong the community is and how many people try to get the best out of the tools we have.

Hixie's decision to remove the <time>-element in favor of the <data>-element was not found democratically by everyone contributing to the HTML5 spec but was a bossy behavior.

Personally I learnd a lot about the process within the W3C, the WHATWG, how the specification is build, and so on asf… This was pretty good and I feel good about how things work.

I hope there are more people who like keep a little bit more track of what is going on with all the new stuff and be part of decisions that are made.

Thank you for reading all the words I wrote.

Thank you Steve, Tantek, thank you Eric Eggers, Shelley Powers, thank you everyone who was able to do something about the odd removal of <time>. You guys rockkk!


4

How to Build an Accordion-Menu using CSS and a bit of jQuery

by Hans Christian HTML5

We’re doing a project these days where we use an accordion-menu to show some content.
I want to share with you how I did this using jQuery and CSS. This is pretty easy and I want to encourage you not to use any plugin or so but to write the code yourself and learn a bit more about how to use CSS and jQuery and save some microseconds on your loading type.

The HTML

This is kinda straightforward I think. We don’t need a wrapper for the accordion-menu. Check it:

<section id="experts" class="accordion-item">
  <h1><a href="#experts">Experts</a></h1>
  <div class="content"></div>
</section>

This is how every item for your accordion should look like.

The CSS-Part

Some basic CSS-rules for the header and the content of each item.

.accordion-item h1 a { display: block; font-size: 1.5em; text-align: center; }
.accordion-item .content { display: none; }

You may want to do at least a bit more on the styles but that’s up to everybody on its own.

We want to keep this accordion accessible for people who don’t use JavaScript, what is kinda unusual these days I think… but you never know!
That’s why we added an id to each accordion-item and link to this section in the headline through #experts for instance. We can now show the content of the requested id with CSS:

:target .content { display: block; }

So we’re all set up with the accordion. We can now add some effects with JavaScript.

Using jQuery

First, we will add a line that will show the content of the first element on load:

$('.accordion-item').eq(0).addClass('current').find('.content').show();

And than the we will listen to clicks on the headlines and do some actions afterwards. Read the comments in this snipped.

// Listen to click on headline-link
$('.accordion-item h1 a').click(function(e) {
  // prevent auto scrolling to id
  e.preventDefault();
 
  // Register the variables for better performance
  var $parent = $(this).closest('.accordion-item'),
      $content = $parent.find('.content');
 
  // If the clicked section is not the active one
  if (!$parent.hasClass('current')) {
 
    // SlideUp "old" and remove class
    $('.accordion-item.current .content').slideUp()
      .parent().removeClass('current');
 
    // Add class and slide down content
    $parent.addClass('current');
    $content.slideDown();
 
  // If the click was triggered on the currently active section
  // remove the class and slide up content
  } else {
    $parent.removeClass('current');
    $content.slideUp();
  }
});

And this is it I guess. Working pretty much in every available browser. The CSS :target pseudo-class is not available in every browser though, as it is a CSS3-pseudo-class. And now guess which browser this might be… Right Internet Explorer. It is supported with version 9 but not before.
You will find more information about :target in the spec. Check out the Can I Use table on CSS3-Selectors.

Download the files

I’ve made a demo of this on jsFiddle. Play around a little bit or download the files, if you want to.
Demo     Download


6

“Where Are My Rounded Corners?” – German Translation

by Hans Christian CSS3, Design, HTML5

Some weeks ago Paul Irish published his article about TAFEE (Tiered, Adaptive Front-end Experiences) and shares Paul Boag’s booklet called “Where are my rounded corners?” which tries to describe why it is better to design for the future and modern browsers and not spending too much time trying to get the website’s design working in older browsers (namely Internet Explorer 7 and 8).

The booklet was originally published in Paul Boag’s blog. Paul describes why he did this this:

One of the biggest areas of confusion among our clients is progressive enhancement. They wonder why the beautiful design they signed off doesn’t look the same in older browsers. To overcome this problem we are making two changes. First, we are trying wherever possible to show them designs in the browser rather than as static images. Second, I have put together a short document outlining why progressive enhancement is ultimately better for their site.

Translation

As we have the same issues with customers that do not understand why they get different experiences of their websites in different browsers, we translated this beautiful booklet to German and want to share it with anyone who needs it under Creative Comments Licence.

Thanks goes out to Paul Boag for creating this, Steffen and Daniel who helped me translating it, and /gebrüderheitz (especially Daniel again) for the Design of the German version.

If you find mistakes or have a suggestion for a better translation please share it in the comments.
If you are interested in translating it to another language, please let me know via the contact-form or an email.

Download

As I said, feel free to download the pdf-file and share it with your customers as well.
English Version    German Version    Danish Version

Update 03.02.2012: Niels Steinmeier has a Danish version of this booklet. I don’t understand a word but it may help the one or the other.


0

Offer Files as Download with a@download

by Hans Christian HTML5, Research
blog-a@download

So the spec introduces a new attribute on a-tags (so called “links” – this may be new to you ;-)) called download (short: a@download – this technique of connecting attributes with tags is written up and documented by Mathias Bynens).

When you link to a file like an image or a PDF-document it will be displayed within the browser normally. The download-attribute in links prevents this behavior and offers the file as a download in your browser.

Definition

The spec allows the attribute for having a value. This value can be a string which defines the name of the downloaded file. As a default the browser takes the file’s original name.

And this is what it could look like in HTML:

<a href="path/to/file/file.png" download="a-nice-image.png">Download this file</a>

The value of the download-attribute overwrites the filename with a-nice-image.png.

The Content-Disposition-header can overwrite the name for the file.

This really nice demo exports a written text and offers it as download (but be aware of browser-support – see below).

Browsersupport

The download-attribute is not supported very good at the moment of writing this article.
Chrome supports it since its version 14. Version 14 is only a view weeks away from the stable release.
Firefox 8alpha (Aurora-channel) does not support it as far as I experienced it. I did not find anything about any intensions when Mozilla will include it.
And the other ones? No support yet!

So, what’s the fallback?

There are other techniques to serve a file that will be offered as a downloads in the browser. For instance you can use an HTTP-Header that’s a mime-type that the browser does not know.

Here is an example with PHP:

header('Content-Type: application/force-download');
header('Content-Disposition: attachment; filename="some-file-name.ext"');

You should then open the download in a new window or tab, or in an iframe to prevent any stupid browser-behavior.

More about this issue here.


2

The Difference between Push and Pull

by Hans Christian HTML5, JavaScript
Push and Pull

You do know the nice message which is submitted to your smartphone when someone mentions you on Twitter?

iOS gets these messages via push. This means the server tells the app something like “Hey look, there’s something new on your Twitter-account”.
On Android this is done with push, too. It was introduced in version 2.1.0 in mid of July. Before this release they requested all Tweets via “pull”: The app asks the server “Yo server, somethin’ new here?”.

Draw-backs?

So where’s the difference besides the obvious?

  • with pull the app has to connect to the server in a certain time-interval
  • this means heigh power drain
  • it may take some time until you receive a message via pull*
  • push may hold an open connection to the server: more data is send

* Site note: I noticed that it also may take some time until a new message is delivered with push technology on iOS or Android (for Twitter-App). If anyone knows more on this issue please share your thoughts.

The way we do it today

If you’re coding an online app you have something where you’re displaying new messages or so. The known approach is to return asynchronously to the server via JavaScript and evaluate the answer. Something like this:

$.getJSON( 'messages.php' , function( data ) {
  // If there is a message
  if ( data.length &gt; 0 ) {
    $.each( data['msg'], function() {
      // Do some fancy stuff with messages…
    });
  }
});

This is “pull”. It is not enough to request the answer of this file once, because this would evaluate the data only once. This is why there has to be a kind of timed event which fires the request in an interval.

This is what it could like with an intervall of 1 minute:

! function pull_request() {
  $.getJSON( 'messages.php' , function( data ) {
    // If there is a message
    if ( data.length &gt; 0 ) {
      $.each( data['msg'], function() {
        // Do some fancy stuff with messages…
      });
    }
  });
 
  window.setTimeout( function() {
    pull_request();
  }, 1000 * 60 );
} ();

As you can see, there is an IIFE surrounding the code. I am doing this in order to call the timeout recursively. For more information please read Ben Almans article on this issue.

What else is possible

This will work totally fine. Let’s take a look at other possible ways.

The Wikipedia article about push sais:

Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server.

With HTML5 the WHATWG introduces The WebSocket API.

WebSocket API

The WebSocket API enables websites and apps to communicate with a server. A polyfill for browsers that do not support WebSocket and as a framework you should definitely check out Socket.IO.

There were some definitions of this API in the spec that had some security problems and so browser vendors implemented some stuff that is outdated by now. There is a kinda “last call” specification for this API which are already implemented in Chrome dev channel (version 14) and Firefox 7. The API is available with a current version of Webkit so it should be in Safari soon.

Server-Sent Events

Furthermore there is the Server-Sent Event which is dedicated to fulfill push notifications. The event is already supported in stable versions of Safari, Chrome, Firefox and Opera. See When Can I Use… for more information.

The Server-Sent Event is a DOM event and can be accessed via new EventSource( file ); in JavaScript, while file is a server-file which publishes the notification. With the onmessage-event it is possible to listen to the changes of notifications.

var source = new EventSource( 'messages.cgi' );
source.onmessage = function( e ) {
  // do something with the notification, e.g. log it in the console.
  console.log( e.data );
}

Conclusion

With the given technologies it is possible to send notifications via push to the client-site. There are polyfills for “older” browsers (like pulling data). It is possible to use these tools today.

If you have any experience with the topic of pushing data, please share your thoughts and ideas in the comments.
Thanks for reading though.

I am going to develop a web-app with a friend of mine. We are using node.js for the server part. I am pretty exited to deal with it. We will definitely need something like a push event. We’ll see what will be best.

Read more and follow-up info:

  • Follow Ian Hickson on Twitter or Google+. He is the editor of the spec for Server-sent Events and The WebSocket API.
  • You should checkout the Modernizr Polyfill Wiki to get some information on polyfills for older browsers with WebSockets aso.