Tag: safari

Using CSS zoom and CSS Transforms For a Better “Increase Text Size” Button

Posted on by Rob Larsen

So… the site I’m working on has one of those “increase text size” controls. On this project it’s turned out to be one of those features that shows up in comps and somehow falls through the cracks until later on in the project cycle. Situation normal, really, as it isn’t a big feature. It’s just one of those things that needs to be buttoned up before the site can go live.

Anyway, I was thinking about how to do implement it the other day. I haven’t done one of these in a long time and the only other time I did one it involved crafting separate, albeit small, style sheets for the larger text sizes. I didn’t want to go that way again. Basically, I just didn’t want to write new style sheets- even small ones.

What’s a fella to do?

zoom

So, thinking about it a little bit, I seized upon using the non-standard CSS zoom property. Supported in Internet Explorer (zoom:1 is often used for a hasLayout toggle) and Webkit browsers, it would represent a simple (1 line!) CSS solution to this problem. It’s also one that I like better aesthetically as the site looks the same, just bigger. I figure there’s a reason all browsers have moved to this behavior when hitting ctrl+.

The problem was figuring out an equivalent for FireFox and Opera which don’t support zoom

Enter CSS 2D Transform

A little searching and experimenting later I came up with the idea of using CSS Transforms and the scale value to approximate zoom in browsers that lack support.

Let’s see how I did it.

As you go through the following keep in mind this hasn’t actually gone through testing yet so something weird could yet shake out. I just wrote this code yesterday, so you guys can be my sanity check.

Also, is anyone else doing this?

Continue reading “Using CSS zoom and CSS Transforms For a Better “Increase Text Size” Button” →

Required Reading: Yahoo Research on Mobile Cache Size

Posted on by Rob Larsen

With more and more people embracing the idea of producing HTML5 mobile web apps, research like this is becoming vital. There are a lot of gotchas in this article, especially if you’ve been ignoring this space.

You should read the whole article, but I just want to point out a pair of findings before I send you on your way. One has been a known issue for a while (it’s a ySlow rule, after all,) but it’s still worth pointing out. The other… wow… my emphasis.

Results varied wildly across the three most recent versions of iOS. Astonishingly, Mobile Safari on iOS 3.1.3 did not cache components of any size, despite having an apparently unlimited page cache size. This is troubling since it means iOS 3.1.3 users are likely getting a suboptimal browsing experience, especially if they aren’t using wifi. The unlimited page cache size does little good here, since it only comes into play for back/forward navigations. This behavior is a significant change from what others observed in previous iOS releases and I can’t imagine any good reason for it, so I suspect this may be a bug.

Mobile Safari on iOS 3.2 (which is only available on the iPad) does not exhibit this bug. Its 25.6KB component limit and ~281.6KB total cache limit are better than nothing, but they still seem paltry compared to the other devices tested. Uniquely among iOS devices, the iPad appears to limit the size of pages in the page cache to 25.6KB, the same as its component size limit.

Read the rest of the article:

Mobile Browser Cache Limits: Android, iOS, and webOS

My Personal View of Browser Market Share is Pretty Sweet- Firefox Rules, Chrome is Massive, IE6 is Nearly Dead

Posted on by Rob Larsen

Here are the numbers for DrunkenFist.com in the year 2009. There were 614,333 visits to that domain last year and the top browsers broke down like this:

Browser # of Visits % of Visits
Firefox 342429 55%
Internet Explorer 162977 26%
Chrome 35801 5.8%
Safari 33545 5.4%
Opera 22826 3.7%

Continue reading “My Personal View of Browser Market Share is Pretty Sweet- Firefox Rules, Chrome is Massive, IE6 is Nearly Dead” →

Want to Test Your Site Without a Mouse For Accessibility’s Sake? These Keyboard Shortcuts Will Help

Posted on by Rob Larsen

Once thing that’s vital to testing the accessibility of a web app or site is running through it without using a mouse. If you can successfully work a site or app without touching the mouse, you’ve gone a long way towards ensuring that your site is available to a wide range of people and devices.

One thing that’s difficult about that process is most of us rely far too much on the mouse when browsing. Which is where these lists of keyboard shortcuts for Firefox, and Internet Explorer come in handy.
Continue reading “Want to Test Your Site Without a Mouse For Accessibility’s Sake? These Keyboard Shortcuts Will Help” →

getElementsByTagName Namespace Prefix Strangeness in Safari/Chrome/WebKit

Posted on by Rob Larsen

Is It Me or the Browser?

I had a Safari bug on a project I’m rushing to get out the door. We’re using a Flickr feed to populate a div with link+thumbnail to some flickr images. In Firefox/Internet Explorer I simply did the following to build the links:

flickr : function(obj) {

//get the full list of items
	var items = obj.getElementsByTagName("item");

//make sure it's not empty
	if (items.length > 0 ) {

//start the HTML block
		var blob = "<div id='flickrFeed'>";

//loop through the items (we only want 5) and build some links)
		for (var i = 0; i< 5 ; i++) {

//get the link 
			var flink = items[i].getElementsByTagName("link")[0].childNodes[0].nodeValue; 

//get the thumbnail
			var flurl = items[i].getElementsByTagName("media:thumbnail")[0].getAttribute("url");

//smash them into the string
			blob+="<a href='"+flink+"'><img height='75' width='75' src='"+flurl+"' /></a>";

		};

//close the div
		blob+="</div>";

//pop it onto the shelf, for later use
		$("hyperspace").innerHTML+=blob;

	} else {

//if there's somethign wrong with the feed, go to default contentk
		social.fallBack.flickr(); 

	}

}

Continue reading “getElementsByTagName Namespace Prefix Strangeness in Safari/Chrome/WebKit” →