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.
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.
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.
No longer maintained
Version 3.1 – Update 25.11.2012
Add current 16x16px favicon.
Version 3.0 – Update 25.05.2012
And again Daniel updated the template with some great things.
It now features the “new” HTML5 Boilerplate icons, you get a better overview of what icons are present and how the output of images is.
Apart from that Daniel made a bug-fix for the 144×144px touch icon where the PNG wasn’t saved by default.
Version 2.0 – Update 21.03.2012
Daniel has updated the favicon template with a 144×144px touch icon. This icon is needed for the high-resolution iPad Retina displays which are built into the latest version of the iPad. A version of this is also included in HTML5 Boilerplate by default. Please read this issue for more information and remember Mathias’ article, which he updated recently.
Thanks goes out to Daniel.
I’m using HTML5 Boilerplate (H5BP) for nearly all of my projects at the moment. Why? Mh, I think mostly because it provides best practice for so many things concerning front-end development. With H5BP I learned how to use favicons (or touch icons) in different variations for smartphones and stuff properly.
Friend and boss Daniel designed a nice PSD template to create the various icons you need. It has four different sizes and includes slices and meta-information for everything. You just need to include your favicon, “Save for Web” and you’re done.
He gives it away for free. So feel free to download and share. It would be pretty nice if you check out his Twitter-stream and follow him.
Preview Download PSD
Please be aware that you also should add an
apple-touch-icon.png. You could do this by copying
apple-touch-icon-57x57-precomposed.png and rename this. Thanks Sven for the heads up.
A Note on .ico
Since you should always use a .ico file for the favicon in order to get it working in Internet Explorer I would advice you to open favicon.png in Photoshop and use the ICOFormat plugin to generate the .ico file.
Jon R. Humphrey made a layered favicon template and shared it on GitHub. Please check it out, it might be more helpful than this template from time to time.
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.
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
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).
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-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.