The TH Design Blog!

Just one of those things intrepid designers come across unexpectedly and have to spend several hours trying to resolve. A new site design used a large background image for the homepage and variation of it for the inside pages. Everything was looking great on my mac and pc in IE, FF, Chrome, and Safari. Then I opened the site on my iPad 2 and had one of those moments. The site looked screwy, and it took a minute to figure out what was going wrong. It was the background images – they were being “shrunk”. An image that was 1800px wide by 1200px tall (only the central part of which would be visible through a smaller viewport like an iPad or laptop) was appearing on the page in it’s entirety, appearing to be about 500px wide and correspondingly short.

I had never run into this problem before – I’ve used large background tiles extensively and they all appeared just fine in the iPad. Even beginning to try to troubleshoot was a challenge as there’s not a lot of material out there on the web yet as compared to, say, Internet Explorer Bugs. I did all the usual things: checked my CSS and HTML at W3C—no help. Reviewed material on using background tiles—no help. There was nothing unusual about what I was doing that I could discern.

Next step was to post the problem on a couple of forums—two didn’t respond at all and the third responded but had no answer.

The third phase was to search in Google using one variation after another of the search phrase, trying to get some relevant results. And finally, after posing the tenth or eleventh variation of the question I hit paydirt.

These articles saved the day:
http://www.teknocat.org/blog/web-dev…-scaling-quirk

which linked to:

http://www.defusion.org.uk/archives/…iphone-safari/

The problem? The size of the background tiles. Basically the width times the height (1800 x 1200) could not exceed 2,000,000. If it did, Safari would shrink it (which is what it was doing). My home page tile was 2,160,000 and the inside tile even larger. Apparently it doesn’t matter what the combination of height & width are, as long as they don’t, when multiplied together, exceed 2,000,000. (The writers of the articles listed above discovered this quirk when working on iPhone designs and discovered it occurred on iPads as well.)

Back to Photoshop, various adjustments to deal with rough edges, tiles reduced and all was well.

You learn something new everyday!

One variation that I like re: navigation bar styling is to put bullets, “•” (or &8226;) between entries, a la: Home • Page 1 • Page 2 • Page 3

Easy to do when you can directly control the HTML, but making that work in WordPress was a puzzle. I didn’t want to simply label the Home entry as “Home •” because I apply color changes to page names on hovers and I don’t want the bullet to change color along with the page title. So they have to be entered separately.

Fortunately some good folks in the WordPress.org forums explained that you can use the Custom Links fields in the menu builder for this purpose. You enter a “#” in the URL field and “•” in the label field and then drag the custom link over between entries in the menu building pane, then rinse and repeat for however many bullets you need. The downside is that the bullet acts like a live link when you hover directly over it, i.e. it changes the cursor and shows an anchor link to nowhere. Some folks in the forums recommended deleting the # once the custom field has been moved over though there is the risk that future WP updates might render that a problem. 3.3 doesn’t seem to object, however so I’m going to remove the #’s.

The site using the bullets needed some additional adjusting, though. When I removed the # the bullet stopped being subject to the navbar links css styles and they would wobble when hovered over. Looking at the page through Firebug, custom links with # are designated as

<a href="#">•</a>

while the custom link with the # removed becomes

<a>•</a>

So I added an additional style for “#navbar a”, which resolved the wobble. (The new #navbar a style is just a repeat of the #navbar a:link style.)

You can use the Custom fields for creating placeholder labels too. For example, when a section is going to have drop-downs or flyouts but the label doesn’t really represent a page with content then you want the label to appear but not act like a link. Once again, you enter a # in the Url field, add your label to the label field, move it into the menu and remove the # from the Url field.

NOTE: In the case of placeholder labels, it turns out that if they don’t have the anchor link functioning, the associated dropdowns/flyouts won’t work on iPads or other devices that don’t recognize hover states. So don’t remove the #’s in those cases.