Behind the Scenes: HTML5 and CSS3
We would like to give you a quick overview about our first steps at AdOcean in evaluating possibilities for HTML5 ad delivery. It should not only be an update about ongoing works in the background related to mobile ads, but also an inspiration for you to share with us where you are heading at your company when working on your presence on mobile devices.
The approach of the post-Flash era
The online ad industry has relied on Flash for many years for rich media, but this seems to change as browsers implement more and more of the emerging HTML5 specification, some of them (esp. in mobile area) not supporting Flash at all. It is worth noting that when we talk about HTML5 ads, a huge amount of the eye-candy visuals is not really HTML5 but CSS3 magic, which got tied to HTML5 along the way. HTML5 brings many new elements to the HTML specification, of which it is probably the video element that draws the most attention from creative agency and advertiser side. However, most ads still rely on bitmap and/or vector graphics, and various effects applied to them like fading or some kind of motion. Thus CSS3 has just as much significance (if not more)when it comes to non-Flash ad serving. To cut it short, when we talk about HTML5 then CSS3 is also something that comes along with it, even if someone doesn't mention it explicitly.
As even Adobe has committed itself to HTML5 in case of mobile browsers and plans to deliver only security fixes to Flash on mobiles, we also decided to create the first HTML5 creative template for AdOcean to start testing how it all works out on mobile web pages.
Let's get something to test
While looking for HTML5/CSS3 ad examples, we have come across an experiment made by Sencha, where they aimed to prove that CSS3 is mature enough already for making almost exact copies of Flash ads. While it is a very nice presentation of CSS3 possibilities, it also made us wonder how do or how will creative designers and programmers build HTML5 ads. It seems that there at least two very prospective tools to make HTML5/CSS3 ads already: one from Sencha, called Sencha Animator, and the other one (probably it is no surprise) from Adobe itself, in the form of Adobe Edge.
When we set out to create an experimental AdOcean creative template for serving HTML5 banners, we had the following aims:
- an HTML5/CSS3 banner is simply a combination of HTML, JS and CSS code, but it would be nice if all these codes could be defined in a creative template in a clear and easy way, especially if creative programmers will also probably work with separate files and not a single one where everything is mish-mashed (which could lead to problems in some cases anyway)
- let's try to support importing ads from one of the above mentioned tools
- let's implement scaling, like we did it for Mobile responsive image template
The template we have now ended up with support for importing Sencha Animator ads, although needless to say, we are also considering direct support of Adobe Edge, where the situation is more complex due to its output format.
The HTML5 template
AdOcean's first HTML5 creative template is still work-in-progress, but it is also ready for some testing in a wider circle. The screenshot below shows the template parameter page for defining a creative (click the image for full size):
There are more parameters at this point than in most of the other creative templates, however, we tried to make it easy-to-use by dividing certain parameters into groups, like Main parameters or Scaling options, and also by adding context-sensitive help (in the form of blue bubbles at the end of rows).
The template has the following specification at the moment:
- the HTML5/CSS3 creative should be designed with a certain size in mind, e.g. 480x320 pixel
- it is possible to scale to full width of the browser window, this is now achieved with the transform.scale() function of CSS
- all Javascript logic should be in a separate .js file, and all styling should be in a separate .css file (our template changes the DOM when the ad is delivered and appends these separate files to the head)
- the creative is limited now to a single interaction: click/tap, to open the landing page, which is defined in the campaign or creative properties
- any image file should be referred to from the HTML code, if relative path is used
A little explanation might be needed for the last requirement. Let us take the following example: we have an HTML ad there is a brand logo displayed through it, e.g. mybrand.jpg. Now, it is possible to upload this image first and get back the absolute path to it, and use it then in the HTML code. However, it is always faster and easier to use relative paths to embedded content, like /assets/mybrand.jpg or simply mybrand.jpg, in the latter case assuming that the image file is in the same directory on the emitter as the HTML code itself.
Images with a relative path in HTML ads 'see' the hosting webpage as their hosting environment, not the AdOcean emitter. So if you use a path like /assets/mybrand.jpg in the HTML code then the delivered ad will try to load the image from your website (http://mywebsite.com/assets/mybrand.jpg), not the AdOcean emitter, where it is really hosted. As HTML5 ad creator tools also use relative paths and we wanted to have any creative definition task going on in the template parameters page only, we came up with the following solution.
Any relative images in the HTML code have to be uploaded to image slots, each having its own unique macro associated. The first image upload field has AOIMG1 as reference; the second one has AOIMG2 and so on. The naming convention here is the AOIMGx form, where x stands for the number of the file upload slot. These AOIMG macros have to be used for replacing the relative image paths in the HTML code. It ensures that images are 'found' when the ad is displayed on your website.
Step 1: look for an image with relative path
Step 2: upload the source image to one of the free image slots
Step 3: replace the relative path with the appropriately numbered AOIMG macro
Testing it all
The various desktop and mobile browsers support HTML5 and CSS3 at the moment to different extent. We have made a few initial tests to see where things work out and where do we need to wait for browser vendors to implement the new standards better.
| Browser/device | Resize (scale) | CSS3 Animation/Effects |
| Desktop FF10 | Yes | Partial(1) |
| Desktop IE9 | Yes | No |
| Desktop Opera 11.50 | Yes | No |
| Desktop Chrome 15 | Yes | Yes |
| Desktop Safari 5.1.2 | Yes | Yes |
| Native browser (Android 2.2 HTC Desire) | No, with delay only (2) | Yes |
| Native browser (Android 2.2 emulator) | No, with delay only (2) | Yes |
| Native browser (Android 2.3 emulator) | No, with delay only (2) | Yes |
| Native browser (Android 3.0 tablet emulator) | Yes | Yes |
| FF Mobile (Android 2.2 HTC Desire) | Yes | Partial(1) |
| Opera Mini 6.5.2 (Android 2.2 HTC Desire) | No | No |
| Opera Mobile 11.5.5 (Android 2.2 HTC Desire) | Yes | No |
| Safari Mobile (iPhone iOS 4.2) | Yes | Yes |
| Safari Mobile (iPhone iOS 4.3 emulator) | Yes | Yes |
| Safari Mobile (iPad iOS 4.3 emulator) | Yes | Yes |
(1) Partial means that motion of elements was not rendered at all, but text fading effects were working.
Generally, the CSS3-infused rich media works perfectly with WebKit in Apple products, may it be an iPhone 4 or the latest Safari desktop browser. Interestingly, we experienced scaling problems with the native browser of Android 2.2 and 2.3 devices (related to a documented bug (2), which has been seemingly fixed in version 3.0). Keep in mind that the more desktop browsers will support HTML5 and CSS3, the more possibilities there will be to deliver ads which work without relying on Adobe Flash plugin. It will be interesting to see how big the shift is going to be...
To see the template in action, please visit this page or scan the following QR with your mobile:
So what about HTML5 video?
HTML5 video is something that we would also like to put emphasis on in the future, as the online advertisers and agencies will be shifting video formats towards it. However, it also has to be realized that a universal, generic solution also requires stable standards, which is not the case with HTML5 at this moment (specification is supposed to be finalized in 2014). One thing that really makes life harder in this stage is the problem with codec support, various browsers support either .mp4 and/or .ogg files. It is also necessary for browsers to provide support for the video element completely, including mute or full screen attributes.
Although the HTML5 specification is only due in 2014 and browsers are still in the middle of CSS3 implementation as well, we would like to hear about how you see your future with HTML5. Any feedback on HTML5 and mobile ads is greatly appreciated by our colleagues in the HQ or at abroad Gemius subsidiaries. If you would like to test our HTML5 template in its current state, please contact Technical Support.
Author: Tamas Rakoczi
Posted: 20th February, 2012