EvoBloggito

Keeping Safari (and Chrome) Hacks Out of Your Stylesheets

Author: Ray Gulick; Published: Jan 13, 2010; Category: CSS, Design/Development, PHP for Designers; Tags: CSS, Design/Development, PHP for Designers; 21 Comments

Although I design and develop on a Mac Powerbook, I mostly ignore Safari for two reasons:

1. Safari is about as standards compliant as browsers get, so it rarely needs any special attention.
2. Safari is used on fewer than 4% of all computers (and it seems to have peaked).

I use Firefox almost exclusively (although I’m now experimenting with Chrome for Mac), because it’s very standards compliant, and it gives me about 99% of the same results as a PC version of Firefox. Using FF in my development process means I have the biggest browser covered (that’s right, FF has over 46% of the market, with IE6-IE8 combining for just over 37%). I use crossbrowsertesting.com to hunt for problems in IE. Ideally, I want my work to look the same in all browsers (but I’ll settle for “close” in IE6).

That said, I try to keep in mind an old saying in the web design business: The most important browser to develop for is the browser on your client’s screen. One of my clients is an ad agency, and they are completely tied to Safari (I’m pretty sure they’ve heard of Firefox, but…). So, looking good in Safari is a priority on their projects. Rarely is there a need for a hack, but occasionally it happens.

There seems to be only one reliable CSS-only way to target Safari (incidentally, it also targets Chrome, which has almost 3x as many users), outlined way back in 2007 by Dustin Brewer. You can put this in your style sheet to enclose Safari-targeted rules:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}

But then you have a hack in your style sheet. I find it’s easier to maintain (and find) hacks by putting them into a different file, and your basic style sheet is more likely to validate. I experimented with using the above selector in the header to point to a different stylesheet, but had some issues (don’t remember now what they were). Finally, I settled on putting the following in the header, following the basic style sheet link:

<style type="text/css" media="@media screen and
     (-webkit-min-device-pixel-ratio:0)">
     <––
     <?php include("includes/safariCSS.php"); ?>
     ––>
</style>

This displays the contents of an include file, displaying CSS rules in the header as an "internal style sheet." The contents of the php include file consists of CSS rules, but is not a CSS document. Internal style sheets in the header are usually to be avoided due to maintenance and consistency issues, but by using an include, the Safari CSS for all pages is editable in one file.

By the way, the CSS rules from the include appear in the header for all browsers, but the “@media…” statement means all but Safari and Chrome ignore the styles. Given that I’ve done websites with some extremely complex CSS and only needed 2-3 rules targeting Safari, I don’t think this approach risks adding much overhead.

View a Demo | Download Demo Files

Server Side Scripting Reminder: Because the include is PHP, which renders on the server, the files will not work locally on your computer. To see the results of your experiments, upload the files to a server that supports PHP.

Creating a Faux Double Background with Absolute and Relative Position

Author: Ray Gulick; Published: Dec 21, 2009; Category: CSS, Design/Development; Tags: CSS, Design/Development; 6 Comments

Recently, I had a need for two background images on a page I was asked to create to display a client’s online Christmas card. The background required a blend, easily made with a vertical gradient image. On top of that, another background image was to appear partially hidden behind a horizontally centered div that held a Flash movie. Further, the second background image had to adjust position as the browser window was made narrower or wider.

First, I Googled "two background images CSS." The solutions I found were complicated, or the background images didn’t move, or making them work with all browsers (I’m looking at you, IE6 and IE7) required some hacks. I’m not completely above using hacks, but I’d rather avoid them if possible.

Then I remembered that absolute and relative positioning create some interesting effects in layering elements. By specifying the second "background" image with absolute position, and applying a percentage on the right, I was able to make the image slide across the screen as the browser window was made narrower or wider. Applying relative position to subsequent elements allows them to appear "on top" of the image. See the demo here.

For the demo, the original client info has been replaced with Evo info (to protect the innocent, and because this is my blog post, so there!). Also, the content div does not include a Flash movie, and the div is transparent so the partially hidden image can be seen in full.

Here is the basic page structure as rendered by the CSS, numbered in the order in which the elements appear on the page:

Following is the CSS (classes important for the faux background effect are bolded):

* { margin:0; padding:0; }

body { font-family:helvetica,arial,sans-serif; background:#ccc url(images/bkgrd.jpg) 0 0 repeat-x; text-align:center; color:#777; }

.background2 { position:absolute; top:0; right:65%; }

.logo { width:740px; text-align:left; margin:0 auto; position:relative; }

.content { width:740px; height:370px; margin:0 auto; position:relative; background:#555; filter:alpha(opacity=60); -moz-opacity:.6; opacity:.6; }

.content p { color:#fff; padding:80px 80px 0 80px; line-height:150%; }

.links { width:740px;  text-align:left; margin:0 auto; position:relative; }

.links p.left { float:left; display:inline; font-size:11px; letter-spacing:.1em; padding:18px 0; }

.links p.right { float:right; display:inline; font-size:11px; letter-spacing:.1em; padding:18px 0; }

a { text-decoration:none; border:none; }

a:link, a:visited { color:#777; }

a:hover { color:#000; }

.content a:link, .content a:visited { color:#ccc; }

.content a:hover { color:#000; }

Download the files»

Web Designer, Web Developer: What’s the Difference?

Author: Ray Gulick; Published: Jun 18, 2009; Category: CSS, Design/Development, Usability; Tags: CSS, Design/Development; No Comments

The terms "web designer" and "web developer" can mean just about anything, depending on who’s using them and why. I’m going to make a case for definitions that indicate two different skill sets, with each offering different services (perhaps with some minor overlap on occasion). Hopefully, there will eventually be widespread agreement about the differences and areas of overlap in the designations. In the meantime, there’s a comment form at the end of this post that begs for your disagreement with (or support for) my opinions about these terms.

Web Designer

Web designers are first, and foremost, designers. They might be able to tinker with javascript to make an existing jQuery plugin look or behave the way they want, and they might be able to copy and paste and rework some minor php, but they’re unable to write their own functions. And databases? Fugeddaboudit!

However, web designers are experts at CSS, Photoshop, and XHTML. Given half a chance, they can bore you to death with discussions about how to clear floats or when (or if) it’s appropriate to use tables. They understand web typography, color, spacing of elements, navigation, directing eye-path, enhancing user experience and accessibility, and have at least a working knowledge of information architecture.

Assuming they’re good at what they do, when they complete a website, it looks good, it’s easy to navigate, the information is readable, and the site’s look and feel supports and enhances the content. Web designers are sometimes referred to as "front-end developers," but in my mind this term indicates some expertise in javascript.

Web Developer

Web developers offer significant programming services and database development in whichever flavors they have chosen to master. At a personal level, they may or may not also be web designers, but usually not. Few people are competent at both design and programming (I don’t know a single expert programmer I would hire as a designer).

I’ve also found that the term "programmer" means different things to different people ("designer" is subject to interpretation also: everyone who owns a copy of Dreamweaver or InDesign calls themselves a designer). Some people who press buttons in .NET call themselves programmers, even though they are unable to write even the simplest functions. As a result, when they’re part of a web team, the rest of the team adapts to the needs of the software, instead of having the programmer adapt to achieve the desired result.

At a company level, a web development company may be comprised of people who, individually, could not offer both design and programming at professional levels of competence. I consider myself a web designer. My company is a web development company because my business partner has very strong complementary skill sets in programming and database development. We’ve always joked that, while we can accomplish a lot together, individually we’re kind of pathetic. At least I think she was joking…

The Optimal Line Length Principle Applied to Web Design

Author: Ray Gulick; Published: Jun 16, 2009; Category: CSS, Design/Development; Tags: CSS, Design/Development; 6 Comments

The other day I pointed out some of the differences between web design and print design. It started me thinking about some of the things I learned as a print designer that are also applicable to web design. One of the most useful is the Principle of Optimal Line Length. It states that, for any given font-size of a multiple-line block of type (like a paragraph), there is a range of line lengths and line-heights that most people consider easily readable.

Those 3 attributes—font-size, line-height, line length—are inter-related.* Change one, and you may need to change at least one of the others for most people to consider the text readable. In simple terms it means that, the wider the line length, the greater the line-height must be. Or, the bigger the font, the wider the line length. Or, the greater the line-height, the bigger the font.

Below is an illustration meant to demonstrate the relationships between the 3 attributes. In the top section are 2 blocks of text, each with 13-pixel font-size and 16-pixel line-height. Too my eye (and this is why it’s called a principle, not a rule that has formulas and ratios), the wider lines look too tight and dense. However, with the same font-size and line-height in a much shorter line length, I think it looks very readable.

Below that is a section that includes the same font-sizes (13 pixels) with a line-height of 22 pixels. Further below that section are font samples that also have a line-height of 22 pixels, but a font-size of 18 pixels.

So how does this apply specifically to web design? Because of my awareness of the principle, I always consider the line length as well as the font-size when specifying line-height. Also, I never create "fluid" layouts that expand the width of an area that contains text, because sooner or later, the expanded or contracted line length will make the text unreadable (in my and many other people’s opinions). I love IE7′s (never thought I’d be say I love anything about IE) and Firefox’s "scale-up" feature, because when a viewer wants to make the font bigger, it makes everything bigger (line-height and line length), preserving the optimal line length relationships.

Because it’s a principle rather than a rule, designers have some latitude in which to exercise their judgment. As a web designer concerned with readability, I look for the "sweet spot," in which font-size, line-height, and line length allow people to read multiple-line text blocks comfortably and easily.

*Only 2 of the 3 are actually "attributes" in CSS, and I’ve used the CSS hyphenation for them, which may not be "correct" according to Webster’s Dictionary or your high school English teacher.

Free XHTML/CSS Template for Use with Photoshop 4-Column Grids

Author: Ray Gulick; Published: Jun 1, 2009; Category: CSS, Design/Development; Tags: CSS, Download, Template, XHTML; No Comments

A couple of days ago, we made some 4-column grid Photoshop templates available. By popular demand (OK, 2 people asked; but we’ve had hundreds of downloads) we’re furnishing a basic, barebones XHTML/CSS template to be used with the Photoshop grids. The template and style sheet match up with the Photoshop file "1024browserbase_960.psd." To use this XHTML/CSS for the other Photoshop grid templates available, adjust column widths and margins in the style sheet as appropriate, using the information on the Photoshop templates as a guide.

To point out the obvious (if you’ve looked at the template), the style sheet contains minimal styling, and cannot be considered a completed or comprehensive style sheet: it contains just enough styling to make the example elements behave, and it makes no attempt to be pretty. It supports the basic 4-column grid structure, but is only a starting point for your own website based on the Photoshop grid templates. It’s not meant to be a template per se, but a basic "framework" you can use as a starter. The major page areas that are defined are the header, navigation, content (with maincontent and sidebar) and footer. Depending on your design, the homepage XHTML/CSS may be significantly more complex than the "inside page" example provided.

Use and modification of these templates requires a basic understanding of XHTML/CSS and Photoshop. We would love to have you point us to websites you create using these templates, or hear your feedback here on our blog. This template has been tested in Mac and Windows Firefox 3.0, Safari 3.2.3, IE6, and IE7. As with the Photoshop grids, the template is available under a Creative Commons license, to be used and abused in anyway you see fit. The documents validate as XHTML 1.0 Strict and CSS level 2.1.

Download XHTML/CSS 4-Column Template»