HTML and CSS Reference
In-Depth Information
File Size
File size considerations are possibly the biggest shift when working with HTML based ad creative as opposed to Flash
SWF's. Flash was very good at packaging the creative assets all within a small SWF file container using a proprietary
compression format. This compression really squeezed the file size down significantly for ads with animation, fonts,
images—you name it. Because of this, the IAB and various publishers have adopted smaller k-weight footprints for
rich media ads, usually anywhere from 40kb up to 100kb if you're lucky. Because we're no longer contained in the
SWF wrapper, two things need to occur. One, we as developers and designers need to optimize much more out of
the programs we're using for our creative. This could be optimizing image compression out of Adobe's Photoshop or
even minifying the code base before uploading to our hosting. Second, the IAB and it's various publishers will need to
update the guidelines for file size. We as an industry can't progress our creative innovation when there is an unrealistic
expectation of what can be done within a certain file size limit. In the interim as this gets updated, designers and
developers can use appropriate optimization techniques such as the usage of sprite sheets, code minification and
compression, measuring file size via GZIP (wire weight), and leveraging CDN hosted JS libraries (All of which you'll
learn in more detail throughout the rest of this topic).
Asset Delivery
Ad development, much like web development, requires many different components to produce the final piece you see
in a browser. Be sure that when you are requesting creative files from an agency or client, you always ask for these:
images—PNG, JPG, GIF (animated and static)
layered source files (Photoshop documents)
HTML, CSS, and JavaScript files
audio and video files (if required)
fonts and/or (CSS web fonts)
storyboards (PDFs)
Whether you're on the publisher, agency, or ad-serving end, this will help you keep your sanity in trying to
wrangle all the different formats and files and attempting to make updates and revisions later in the process. Ensuring
that all of these files are accounted for during an initial asset intake process ensures that turnaround times and client
expectations won't get compromised due to missing files and/or unnecessary back-and-forth communication.
Element Names
Keeping naming conventions specific and fully worded helps reduce the risk that ad code will conflict with a
publisher's page code. Using elements without specific names could result in code execution conflict or possibly even
incorporating scripts and styles from the publisher's page in your ad content. For example, if the publisher's page has
a div called container and so does the ad code and you have JavaScript code executing on that DOM element, there
is a good chance that the ad code could conflict with the publisher's. The same thing could happen when styling is
applied. It's best to keep div tags and others very descriptive of the ad platform. Personally, I like to apply my own
prefix to the elements. For example, if I have an ad container, I'll look to see what ad server is serving the creative
and add the name to the respective elements. If DFP is serving the ad, it would be something like this: <div id=dfp_
adContainer></div> ; or if it's PointRoll, it would be <div id=pointroll_adContainer></div> . This way, there is a
good possibility that no other elements are on the page with that prefix. If you need to get even more granular, include
the size of the ad as well as the ad server's prefix name.
Search WWH ::

Custom Search