HTML and CSS Reference
my favorite CSS developing tools is bearcss.com , which allows uploading of your raw HTML markup and builds a
boilerplate CSS template for you to style on. It's a huge time-saver, as you don't need to rewrite a bunch of element
declarations after building the markup.
As the CSS level 3 spec gets adopted in union with HTML5, each browser manufacturer is using its own prefixes to
distinguish what is emerging from what is standard inside the browser's rendering engine. Thus, using emerging CSS
features, you'll need to include prefixes for Webkit, Mozilla, Microsoft, and Opera—assuming, that is, that you'll be
targeting all browsers in your next HTML5 campaign (that's usually the case). A few examples of vendor prefixes are,
respectively, -webkit , -moz , -ms , and -o ; using these prefixes as you build with the emerging CSS spec will ensure
you've got the latest bleeding-edge CSS3 feature set within your respective browser environments.
■ as the spec is adopted across browsers, the need for these prefixes will diminish, the result being that
developers will have to go back into the code base to remove them so that nothing breaks down the line once support
drops for the prefixed version of the code.
As we all know, ads usually have a much shorter life cycle than traditional web content, but it's very important to
keep vendor prefixes in mind as you deploy content. Failing to do so will be a real pain if you want to build something
now that's sustainable for the future. Think of anything with a vendor prefix as a sneak peak at what's to come although
the feature you're using could be removed in later versions of the browser. A really good tool to use as you develop
with this budding standard is prefixer.com . Prefixer allows you to develop with CSS. With one click of a button,
it translates all the necessary vendor prefixes for you automatically—another huge time-saver! For the latest CSS3 spec,
visit the W3C current drafts at w3.org/Style/CSS .
A very important function of CSS, one that's been around since version 2 but gets lumped into CSS3, is the ability to
leverage media queries. A media query allows you to do just as what the term states: query the device or screen for
the media it supports. Useful media examples include device width, device height, pixel density, and orientation.
These features are tremendously important in mobile development and are the foundation of responsive web design.
By making use of them, developers can create a CSS document that dynamically adjusts web content to the device
accessing it. A few really great responsive web design frameworks are Foundation ( foundation.zurb.com ) , 320 and
Up ( stuffandnonsense.co.uk/projects/320andup ), and the Golden Grid System ( goldengridsystem.com ) . These
tools provide a blueprint for developing a single unified experience across screen.
This approach is great in the web development world, but note that when building ads with this format in mind,
it's almost certain that k-weight will increase, as you're taking into consideration more than one screen—and that
means more CSS declarations. Before development, I'd recommend reaching out to your publishers to determine
whether they want a responsive ad layout or new tags generated for all screen variations. In reality it comes down to
what the publisher wants. Often it'll be more ad inventory to sell, so they'll fire more than one impression if the user
reorients their device or scales their browser on a responsive layout. The ad inventory will change rather than adapt,
which will result in what seems like more ad inventory for the publisher and will require an ad server to generate
separate tags for each size; the publisher or first-party ad server will need to adjust accordingly. A good practice is to
strip out the CSS content into its necessary parts and load external style sheets specific to the device by using media
queries. This way you don't bring in unwanted CSS code for a user viewing on a mobile device that doesn't meet
the media query rules applied—or even worse, a device with very limited bandwidth. Using our earlier example,
Listing 3-2 leverages media queries for a tablet device and a television and takes its orientation into consideration.