Category: Compatibility issues

Media queries: the abc of them

To target webkit (safari and chrome only) browsers:

@media screen and (-webkit-min-device-pixel-ratio:0) {

Just be careful as it is a hack!  -webkit-min-device-pixel-ratio was meant to tell you the pixel ratio of your screen, meant to discover if you were dealing with a retina display (:2). It just work because other browsers ignore it (for now), and it is true in most screens (because of the current lack of retina displays)

To target ipad / safari portrait / landscape mode:
@media only screen and (device-width: 768px) and (orientation:landscape){}

@media only screen and (device-width: 768px) and (orientation:portrait){}

Here are all the available options:
width: The viewport width.
height: The viewport height.
device-width: The rendering surface’s width (for our purposes, this is typically the screen width of a device).
device-height: The rendering surface’s height (for our purposes, this is typically the screen height of a device).
orientation: This capability checks whether a device is portrait or landscape in orientation.
aspect-ratio: The ratio of width to height based upon the viewport width and height.
A 16:9 widescreen display can be written as aspect-ratio: 16/9.
device-aspect-ratio: This capability is similar to aspect-ratio but is based upon the width and height of the device rendering surface, rather than viewport.
color: The number of bits per color component. For example, min-color: 16 will check that the device has 16-bit color.
color-index: The number of entries in the color lookup table of the device. Values must be numbers and cannot be negative.monochrome: This capability tests how many bits per pixel are in a monochrome frame buffer. The value would be a number (integer), for example monochrome: 2, and cannot be negative.
resolution: This capability can be used to test screen or print resolution; for example, min-resolution: 300dpi. It can also accept measurements in dots per centimetre; for example, min-resolution: 118dpcm.scan: This can be either progressive or interlace features largely particular to TVs. For example, a 720p HD TV (the p part of 720p indicates “progressive”) could be targeted with scan: progressive whilst a 1080i HD TV (the i part of 1080i indicates “interlaced”) could be targeted with scan: interlace.
grid: This capability indicates whether or not the device is grid or bitmap based.

All the above features, with the exception of scan and grid, can be prefixed with min or max to create ranges.

If you need to implement media queries in IE8- and browsers that don’t support it, you can do:
https://github.com/scottjehl/Respond

Media queries for all (screens), not only ipad:

@media screen and (min-width: 1000px) and (max-width: 1040px){

// Targeting widths between 1000px and 1040px

}

/* Generic media queries */

@media screen and ( max-width: 800px ) {

}
@media screen and ( min-width: 801px ) and ( max-width: 1024px ) {

}
@media screen and ( min-width: 1025px ) {

}

Media queries specific for certain mobile devices:

/** iphone **/
@media screen and (-webkit-max-device-pixel-ratio : 1.5) and (max-device-width: 480px){
}
/** iphone 4 **/
@media screen and (-webkit-min-device-pixel-ratio:2) {
}
/** ipad **/
@media screen and (min-device-width: 768px){
}

Target IE9 and IE10:

@media screen and (min-width:0) {
    body { background: yellow; }
}

HTML: coding email newsletters

Golden rules:
1) Make sure width and height is set in each td and img tags in the email: not on the table! but on each cell.
2) Every image is set to display:block. Also, if relevant, put an alt attribute as 40% of email readers won’t download the actual image. Also, whenever possible, user https:// for the links to avoid being flagged as spam.
3) Every link is set to have no border and no outline. target=”_blank” all of them. Also, whenever possible, user https:// for the links to avoid being flagged as spam.
4) Cell padding and cellspacing is removed from each table as much as possible:

5) The layout is broken up in a series of rows, and each row with complex images / data will also be a nested table 6) All styling is done inline. It is a pain, agree. Here’s a tool to make it easier: http://premailer.dialect.ca/ 7) Margin and padding are inconsistently applied across email clients: again, your best friend are tables and cells with widths and heights defined. 8) Background color for the entire email can be set if you put it as follows:

[other nested tables with your content here]

9) Whitespace does matter! If you have spaces or line spaces between rows and cells, they may be interpreted funky by some email clients, avoid them!

If you don’t want to “reinvent the wheel”, and spend lots of time and effort on the emails yourself, use already built and already tested templates:
http://mailchimp.com/resources/html-email-templates/
http://www.campaignmonitor.com/templates/

Troubleshooting:

Outlook 2007 / Outlook 2010: You see only background color where there is supposed to be content. Solution: remove bgcolor=”#[color]” property.

IOS: Avoid auto-formatting of dates and phones:

If your HTML looks like this:

will cease<br> operations <span class=’ios-avoid-format’>on June 1, 2012</span><span></span>.

The CSS that will make this ok in iphone / ipad is:

@media only screen and (device-width: 768px) and (orientation:portrait){
span.ios-avoid-format{
display:none;
}
span.ios-avoid-format + span:after{
content:”on June 1, 2012″;
}
}

Great resources for your email needs:

litmus.com — Essencial for testing

Mailchimp — Great and free for certain number of users on your list

http://premailer.dialect.ca/ — Inline your CSS styles, fast and easy

On Charsets and other strange black sciences

This is basically the software representation of a given map of language characters. The English language, not having lots of different letters, can be represented by 8 byte construct, which give you about 256 characters. Enough to cover all the letters and punctuation signs. Most browsers and computer systems would default to this if not specified.

In HTML4, it is specified as:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
In HTML5, the specification is:
<meta charset="utf-8">

IE7 needs to load the DOM elements first before you can run any script manipulating them on the section

So weird, but if you are to define a variable in IE 7 as follows:

var dobj = document.getElementById(’dataDiv’);

and you do so on the <head> </head> part of your page, it won’t work, unless you call the function that contains that line from the  <body onload=… so you are sure that the ‘dataDiv’ tag is already loaded on the DOM

This is because on IE 7, the body has to load that element first before it is available for javascript to manipulate it.

CSS: two elements that were suppose to be right next to each other vertically have a gap between them

Another thing that artificially creates an space between adjacent vertical   divs, at least in IE 7, is the <form blah blah ..> tag. I could not figure   out where the extra space was coming from, until I moved the <form>   starting tag somewhere else I could see that the problem was created by   that.