Use Typecast to design for the reader by putting type first. Try it now

As of January 1, 2018, we are no longer providing support for Typecast. Our apologies for the inconvenience. Thank you.

Design Q&A

Mark Boulton on HTML Ads

Wednesday 8th October 2014

Mark Boulton
In our September webinar, Monotype’s Design Director Mark Boulton showed us why HTML is the future of digital advertising. Afterwards, he and Jamie tackled some questions from the group. Here’s what they had to say.

Do you think the creation of HMTL ads can ever be a truly cost- and time-effective process?

This question was certainly at the front of our minds when we were working on our example ads. One of the challenges was that we were learning as we went. Also, we didn’t use an authoring environment, so we were writing a lot of the code. Frankly that was just quicker for us. I don’t think it’s ever going to be as cost effective as banging out something in Flash in 10 minutes flat with an image and some text. There are simply more moving parts in HTML. But I think it’ll get easier over time, and I think as this disruption to the industry settles down, platforms and tools of choice will emerge, and within those tools that’s where efficiencies will be gained. I think, and what I’m hopeful for is, that a lot of designers will just start writing HTML.

So I think efficiencies will come, but I don’t think it’ll be over night. It’s going to take some time for this to even out. And in fact, with the benefits that HTML bring, we probably shouldn’t even compare it to what Flash produced.

Do things like motion, animation, etc., push the file size of HTML ads over the limit? Because that’s one of the reasons why Flash is an effective choice.

CSS animation is very robust, very lightweight, and performs way better than Flash, both visually and in the hardware. The only barrier is the syntax is clunky so there may be a steep learning curve. With the right GUI, I feel CSS animation would stomp Flash animation.

How would HTML ads fallback for older browsers not supporting modern enhancements?

One of the core principles and benefits of HTML is progressive enhancement: this notion that you can design to the lowest specification possible and progressively enhance to more capable browsers and (in this instance) devices. Web fonts are really well supported right now in HTML, but some of the device APIs are not. And when those device capabilities are not supported, it’s up to us as designers and developers to make sure the ad won’t critically fail if something like geolocation isn’t supported. There should always be a fallback. There should always be that base level. But HTML gives us that as part of its core principles. Progressive enhancement is one of the many things that makes HTML so great.

Jetstream ad

In your Jetstream example, are you loading images of different size for mobile devices?

For all of our example ads on, we are loading highly optimized images based on the aspect ratio of the ad frame. The platform or screen doesn’t matter.

In responsive ads, how much detailed control does one have over the positioning of the image at each breakpoint?

It can be as detailed as you want to make it, but I would suggest getting comfortable with using percentages and just making edits when the content breaks (like in responsive web design). It’s a different model, but it means you don’t have to think about every size.

How would an ad like the Jetstream example be packaged? All CSS, HTML and JavaScript in one file? And what about dependencies such as jQuery and the images?

With Flash, you’ve got one http request that pulls in one file, and you’re done. In contrast, depending on how your HTML ad is packaged, you’re going to triple or quadruple the http requests, and all that adds to or affects the latency. So with the Jetstream ad we paid that some attention, but we didn’t mirror a real network environment. But we did look at things like jQuery because we thought if we linked to it, we could reduce the JavaScript in the actual ad. But then we’d have this external dependency, and this is where progressive enhancement comes into play. If jQuery isn’t available or it’s big (and even very condensed and minified jQuery is large compared to a 60KB ad) the tradeoff there is to go bespoke with JavaScript and the CSS. Images can not be included directly in the HTML unless you encode them in some way. Same with web fonts. All of that is just reduce the amount of requests and dependencies on external services.

But I think that can only get you so far. I talked about ads being like little apps or websites. And at some point, especially if you’re using dynamic or personalized content, you’re going to have to rely on data sources from elsewhere. I think limiting ourselves to a one-file deployment model would be limiting the future promise that these ads could actually bring to users.

To summarize, it’s something to pay very close attention to. And if you’re relying on external sources, you should have a close look at their reliability and dependability, cause if they’re not there, how would your ad degrade?

Can you show us what the HTML code for the ad looks like?

You can download the Jetstream example and a few others as zip files over on and explore all of the code.

If the user alters their browser font size will that affect the ad’s font size? Or does it act as an independent unit?

As it is loaded in an iframe, it will be unaffected by zooming. As for default font sizes: the vw and px units are not affected by the user’s presets.

What design tools are out there?

Designing an HTML ad really does require knowing some HTML. With that proviso, there are environments that help you get there more quickly. A couple I’m aware of that appear to be really good are Celtra’s Ad Creator and Flite’s Design Studio. Have a look at those because they seem to think in HTML terms. I’ve spent a tiny bit of time looking at Google’s ad design tool. It seems to be more geared towards the translation of a lot of the Flash principles, and a few 3D things in there.

The main qualities I’d look for any tool are support for web fonts or an interest in typography, and making sure that you have control over your type in an HTML environment, because that can be a lot more tricky than in Flash depending on what you’re trying to do. I’d look at the export quality of the code. I’d also look at the ability to import. From a workflow point of view, one of the features I know is a popular concept in the ad industry, and a good one actually, is the ability to import a PSD. Cause anything that can get you there more quickly and close the gap between doing things in static comps and building things in HTML is a good one. Then I’d suggest you spend some time exploring those exported files and learn how things work.

Also, you can use Typecast. Designing ads is not its primary purpose, but it’s very good at a number of things that are important to any online communication: for example building a type stack, choosing your fonts, and getting those typographic details just right. So I encourage you to spend some time in there. And have some fun with the breakpoints as well.

For more from Mark, pop on over to, where he’s fielded more of your questions. And remember to check out the full webinar.

Type on Screen

Get more web type tips, interviews and design gems by email

Hook me up!


blog comments powered by Disqus