HTML and CSS Reference
As mentioned briefly above, busting out of an iFrame is something that may need to happen to ensure an ad
provides a rich experience across a network's or publisher's page. However, rendering the ad onto the publisher's
document could produce namespace conflicts and reference variables. For example, if the ad has an element called
photo-gallery and so does the web page, any manipulations done to that element could pass to the ad experience
or even break the page contents. This wasn't an issue back in the Flash (SWF) days of ad creatives as the SWF element
was inherently sandboxed from the publisher's page. There has to be a better way to serve rich experiences with
HTML that can be sandboxed from the publisher's content, right?
If you think that wrapping the ad content in an iFrame will solve all this mess, you'd be absolutely correct.
However, an iFrame limits the richness of the experience, as it confines the ad to a specific area on the page; also, it's
a bit of a memory hog for pages, as it creates a new instance of the document, one that may not be wanted or needed.
(Think of what happens if multiple iFrames are on the page or even nested within each other.)
Traditionally, using a publisher side script, the ad can check to see whether this script is in place and bust out of
the publisher's designated iFrame. This is absolutely necessary, as most rich ad experiences require expanding and
closing functionality. However, once the ad is busted out and written to the main document of the publisher's page,
arise—indeed, they most certainly will.
Building on the knowledge that iFrames can sandbox you from publisher content, how can a common API, one
that allows this iFrame to expand and contract as well as gather valuable metrics into the ad experience, be provided?
Well the IAB and various working group members are working on an initiative called Safe iFrames, which is intended
to be a protocol between the publisher and ad and be a common API that allows “rich” ads to be sandboxed inside of
iFrames and still access specific expanding and contracting commands, among others. The publisher will effectively
add some code to the iFrame to allow the ad to call pub-side functions for expand and collapse. While the approach
needs standardization and adoption to be a scalable method, it holds some promise for dealing with page content
and ad confliction. (I've mocked up a simple example to show that you can expand or collapse the actual iFrame at
jsbin.com/omodus/5 .) Keep in mind that this would involve special code on the publisher's end; it would control the
functionality and animation of the iFrame on the page, not the third-party ad server tag.
■ there is even the possibility of publishers' using the Mraid api to serve ad tags through. Look for more
information on the Mraid spec in Chapter 9.
Many more features of HTML5 as it relates to advertising are discussed later in the topic. HTML5 is about
updating and pushing the Web as a whole forward; advertising is a key part of that process. Anything that is updated
in the browser will have an impact on advertising.
Advertising with CSS3
As you've just learned with HTML5, many enhancements to the overall structure of the page have been added,
deleted, or modified. Along with the markup structure, of course, goes style. CSS has long been the backbone
for styling within the browser, and as modern browsers adopt CSS3 features, a lot of manufacturers, including
Google, Apple, and Mozilla, are leveraging the latest CSS3 additions to handle web animations and presentations
as never before. Because CSS3 is such a powerful design toolset, designers can now leverage it for creating rich,
print-worthy graphics directly within the browser. They no longer need to rely on Flash or use images to create the
design they're after.