HTML and CSS Reference
In-Depth Information
Debugging
As any developer will tell you, debugging code takes up easily half, often most, of the time spent working. Debugging is
the process of validating code and checking for errors and bugs. Depending on the complexity of the ad unit, it could be
a pretty lengthy process. Unit testing every function requires extreme patience as well as refactoring, which can be a very
time-consuming process. Luckily, developers today have many enhancements and tools that to prior developers were
just a dream. Using these tools you can debug anything in your markup, style, and script. You can manipulate elements
directly on the DOM and get your feedback in real time. Tools like Charles (for the Mac;
charlesproxy.com
) and Fiddler
(for Windows;
fiddler2.com/fiddler2
)
, monitor web traffic much as HttpFox does. These proxy tools are vital for
debugging desktop and mobile devices as well as testing web service calls. They can provide valuable insight into what
your browser's network traffic is performing from requests to responses—very helpful if you're making external HTTP
calls and need to validate the responses. It can help you understand if your errors are client-side or server-side. Yet for me,
probably the most important tool in modern browsers is the web inspector. As I mentioned in the previous section, Web
Inspectors provide a lot of testing and debugging tools for developers and they come with all modern browsers by default.
Among the common problems I've seen when developers are debugging code especially when coming from
the Flash/Actionscript world of using trace statements—are popping alerts for JavaScript testing. Popping an alert
box is performed by writing a command—
alert('hello world');
—in your script; this will cause the code to stop
executing. As you saw when reviewing
async
and
defer
attributes, the DOM parser will be blocked, which will keep
your code from executing until the user clears the alert window. So it's best not to throw alerts and pause the parser.
Rather, use the JavaScript console in modern browsers if you're looking for a similar experience to Actionscript's trace
statement. From there, you'll be able to print output logs to the console and view what's happening under the hood
of the browser, how its executing your ad code. Instead of alerts, use a
throw()
statement or even a log statement by
calling
console.log()
; for normal trace output statements,
console.warn()
; if you are looking to handle warning
signs, use
console.error()
when testing code for potential errors. With all of these debugging commands, you'll be
able to easily navigate your JavaScript code and determine where errors are occurring or optimization can happen.
When you use
console.log
,
console.warn
, and
console.error
, each command writes different colored code
in the browser's console viewer to differentiate them. This is very helpful because you could have many commands,
depending on your ad code's complexity. There are also many other developer tools out there, and every developer
has a special “go-to” tool. Some I've found helpful are Dom Monster (
mir.aculo.us/dom-monster
) and JsPerf (
jsperf.
com
). Dom Monster is great because it's a nice little bookmark for your browser, and JsPerf is great for writing test cases
against code snippets. My advice is to get your feet wet building with these tools till you find one that works for you.
■
For information on accessing developer tools in Chrome, visit
Note
Advertising Best Practices
Since “best practices” is a pretty clichéd term in every industry, forgive my using it if you have a gripe with it. Moreover,
at the moment no one can handle applying “best practices” to something that's not final. However, there are some
useful tips that will, I hope, keep you from getting into a bind. The IAB even states on its creative guidelines page:
Prior to the wide adoption of devices like the iPhone
™
and iPad
™
, Flash
™
formatted creative was
widely accepted and easily displayed across the industry. In today's market, adjustments have to be
made to accommodate ads across multiple display devices. HTML5 has provided one solution, but
is not yet widely adopted and requires different creative specifications than Flash formatted creative.
Requests were made to call out a separate category of creative specs to accommodate HTML5 ads,
but for this release of creative guidelines, it was decided to keep the specs “technology neutral.” An
addendum for HTML5 for display advertising best practices is currently being pursued.
