Supporting high-res devices

I’m participating in Aquent’s Summer of Learning, taught by Jim Webb. The latest class, Looking Sharp on High-Res Displays, was a winner.

What I learned

Basically, you don’t have to worry about anything but images for high res: fonts, CSS elements, and layout all work without any changes.

  • For high res background images, you want two images: one will be the size of your display area (e.g., 175px high and 100px wide for a display area of 175px by 100px); the second will be twice the pixel height and width of your display area, e.g., 350px by 200px. Best practice: add @2x to the end of the file name for the second image, e.g., my_image.png and my_image@2x.png. Then add some media savvy CSS (see my class notes) to serve up the right image to the right device.
  • For foreground images, you can take one of two routes:
    1. Provide one high-res image for all displays. (The image should be twice the pixel height and width of your display area but you should specify that it’s the height and width of the area, e.g., an image that’s 350px by 200px should have a style=”height: 175px; width: 100px;”.) You may be able to compensate for the added dimensions by using a lower quality compression setting.
    2. Create a a normal image and a high res image and use JavaScript, e.g., retina.js, to serve up the right image to the right device.

Continue reading

Weighing the value of semantic markup

I’ve been working to sharpen and add to my skill set and am participating in Aquent’s Summer of Learning, which focuses on HTML5.

The book used for self-study is HTML5 & CSS3 Visual QuickStartGuide by Elizabeth Castro and Bruce Hyslop. It really has me thinking about semantic markup, that is, using HTML elements, attributes, and values and ARIA roles to describe the meaning of the content. HTML5 introduces new container elements like header, footer, nav, article, and section that give information about the content based on the element name. ARIA roles (e.g., navigation, main, complementary) provide similar information targeted to assistive technologies like screen readers. Microformats such as hCalendar tell user agents that the strings within the HTML tags represent specific information such as a calendar event.

Of course, site users don’t typically view a page’s source to see the markup. Not one in a thousand will know if you followed best practices and used the element i to place italics around a book title, the element em to indicate that a word or phrase is being emphasized, and the address element for the author’s contact information — all these will appear as italics unless you tweak the CSS to give them a different appearance. Users won’t know if you wrap the publication date in the new time element using the pubdate and datetime attributes. (Browsers are supposed to display text based on datetime‘s value but support for this is lacking.)

So, what’s the payoff?

Continue reading