Archive for the ‘FireFox’ Category

HTML5 Video Roundup

By Paul Bagosy - April 26th, 2011

I’ve just jumped feet-first into HTML5, and I must say, it’s pretty awesome. I’m actually learning a lot about HTML4 as I go, due to the great writing by Mark Pilgrim (I’ve read the printed version).

My first HTML5 challenge was video, and a challenge it was. For as browser- and code-friendly as HTML5 is, getting all of the pieces to fall into place was still a daunting task. Thankfully, the internet provided all the answers that I needed. The problem, however, was asking the right questions. There was no one answer that I could find, so I’m writing it. This isn’t new information, it’s an assembly of all the pieces I needed to get video working correctly on my site.

Obviously, there are a number of browsers out there vying for market share, and to distinguish themselves from one another, they have collectively made the decision to not support a single standard of, well, anything. Video is no exception. The unfortunate truth is that you’re going to need four different video formats if you want to ensure that everyone is going to see your video. The good news is that HTML5 makes that a snap!

1 – HTML5 markup
Mark Pilgrim handles the gritty details of what video formats to choose and why (including how to encode your video), but after that, you need markup:

<video controls width="500" height="300" poster="poster.jpg">
<source src="video.mp4" type="video/mp4" />
<source src="video.ogv" type="video/ogg" />
<source src="video.webm" type="video/webm" />
</video>

This will display whichever version the browser can handle, with video controls, using the specified image as the first screen. Between MPG4, Theora/Vorbis and WebM, that takes care of playing your video on every browser capable of supporting HTML5, which at this point, is most of the market. Something else to note here is that iOS 3 apparently only reads the first <source /> tag, so you need to make sure that your MPG4 video source is first on the list (as in the example). This problem was fixed in iOS 4, but if it were as easy as a new version, you’d never again have heard “IE6″ after October 2006.

2 – Flash, for older browsers (and by “old” I mean “Internet Explorer”)
Next up, you’ll want your Flash. There are a number of ways to handle Flash, so I’m not going to get into them here. Whatever you were using to display Flash before will continue to work. You want to place it right before the </video> tag. If the browser doesn’t support HTML5, it will ignore the <video> tag and execute your Flash. Problem solved!

3 – A few stragglers
We’re three quarters of the way there. Just two more things to note:

A) MIME types! These are really really important. Make sure the MIME type you’re declaring in your <source /> tag is actually what you’re serving. If you’re hosting your videos on S3, make sure you set your MIME types for each file to what they should be. S3 defaults to application/octet, which will cause Firefox to stare blankly at you while you wonder why there’s a hole where your video should be. Other browsers fail a bit more gracefully.

B) The poster attribute. Again, iOS 3 is a troublemaker. It’s not that it ignores the poster attribute altogether (which would actually be nice) – no, it dumps it over the controls and wreaks havoc on the ability to play the video. After wading through a lot of conversations where people wondered if there was a solution, a coworker and I finally hit on a solution that works. I hate error trapping for one browser, but if you know you’re going to have people using it, then it’s a necessity.

Basically, we check for iOS 3, and create the video tag with JavaScript:

var osString = navigator.appVersion;
if (osString.indexOf("OS 3_") != -1 && osString.indexOf("like Mac") != -1) {
// create video tag for iOS 3
document.write('<video controls="true" width="500" height="300" id="video_player">');
}else{
// create video tag for the rest of civilization
document.write('<video controls="true" width="500" height="300" poster="/alumni/giving/images/The_Campaign_Final-poster.jpg" id="video_player">');
}

And that’s all there is too it. Hope this saves you some time.

Go-Live: Indian Valley Dental

By Paul Bagosy - November 25th, 2009

I’ve decided to start cataloging the sites that I’ve done recently, big or small. So, here we go:

Indian Valley Dental

indianvalley1 Go Live: Indian Valley Dental

Indian Valley Dental

What the client wanted:
This was a redesign of an existing CMS site that had a lot of Flash-based elements, including the navigation.

What I delivered:
The design kept the header flash from the old site, and I brought over the little Flash page title flourish.

I reworked the existing CMS to provide data is much more search-engine friendly and a lot more streamlined. The header navigation uses a CSS hover effect with a jQuery dropdown. The bottom navigation uses a quick server-side element to generate a style that underlines the page that you’re currently on, and the Contact Us page uses jQuery form validation and an AJAX spam-catcher.

The site is identical in IE 6, 7 and 8, Firefox 3, Chrome 3, Safari 4PB and Opera 10 (aside from a few form elements that resist styling).

Simple from the ground up, but that’s the way I like them.

Browser Checking: Blood on the Information Superhighway

By Paul Bagosy - September 28th, 2009

Yes, I know I don’t update here as often as I should, but hey, I do this, I just don’t frequently write about it.

So, let’s say you’ve coded a beautiful site, and you’re really proud of it, and you check it in IE6 and it looks like someone wrapped the entire thing in marquee and blink tags and then had their dog recode it for you. The natural inclination is to scream and toss your monitor out the window, and then hire Tom Clancy to write you into a Rainbow Six novel where you take out Microsoft Headquarters. While that would be an exciting read, what’s really going to solve your problem is to simply write a new CSS file to compensate for IE6 not being a real browser and a large (but slowly shrinking) segment of the browsing population not understanding that.

So, here’s how you handle adding a new CSS file in the most painless way possible:

You’ll already have your css declaration, which should look like this:

  <link rel="stylesheet" type="text/css" media="screen" href="/css/style.css" />

So, all you do is create your new CSS file, name it something like ie6.css, and throw that in there too.

  <link rel="stylesheet" type="text/css" media="screen" href="/css/ie6.css" />

But you don’t want Firefox (or Opera, or Safari, or even IE7) to see this web-based atrocity, so we’ve got to tell them to just move along, nothing to see here, folks:

  <!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="/css/style.css" /><![endif]-->

That’s right, that’s all there is to it! Now, only IE6 will see it that CSS file.

BUT WAIT THERE’S MORE! This little trick is actually a bit more powerful.

You can wrap whole sections of code in this block:

<!--[if...]>

...

<[endif]-->

And, it’s not just for IE6. You can check for any IE version or even a range of versions with this syntax:

if IE 5.5 Single version specific
if gt IE 5.5 all versions greater than the specified version
if gte IE 6 all version greater than or equal to the specified version
if lt IE 7 all versions lower than
if lte IE 6 all versions lower than or equal to the specified version

So, if your problem exists in IE6 and IE7, but not IE 8, you’d just add

  <!--[if lte IE 7]><link rel="stylesheet" type="text/css" media="screen" href="/css/style.css" /><![endif]-->

to capture anything equal to or lower than IE7.

Now, a quick note on crafting your CSS files. In my IE .css files, I just take the line that’s not working in IE, copy it to my IE6 css, and beat it until it complies. The problem with this method is that you’ve now got two lines crashing into each other, fighting a bloody struggle for dominance (and submission!). How, you ask, do you get the desired line to be the one that works? Give it an inflated sense of importance.

Say you’ve got this line:

 .page_content { background:#0CF; padding:10px 15px 10px 297px; }

but IE6 doesn’t understand pixels (or turquose), so you need to change it to:

 .page_content { background:#FC0; padding:11px 16px 12px 15px; }

the way to make sure that the line from your IE css is to add !important to the end of every statement, before the semicolon:

 .page_content { background:#FC0 !important; padding:11px 16px 12px 15px !important; }

That will guarantee that those declarations are the ones that are recognized when there’s the possibility for confusion.

It’s not enough! I need more! IE checking doesn’t seem to satisfy.

Do you need more advanced browser checking? Are you encountering a 1-pixel variance in Chrome? Do you want to have your website make fun of backwards Safari users? Well, simply checking for IE6 isn’t going to help you. You need more power (ah! ah! ah!):

<?
	if(preg_match("|Opera/([0-9].[0-9]{1,2})|", $useragent, $matched)){
		$browser_version = $matched[1];
		$browser = "Opera";
	}elseif(preg_match("|MSIE ([0-9].[0-9]{1,2})|", $useragent, $matched)){
		$browser_version = $matched[1];
		$browser = "IE";
	}elseif(preg_match("|Firefox/([0-9\.]+)|", $useragent, $matched)){
		$browser_version = $matched[1];
		$browser = "Firefox";
	}elseif(preg_match("|Chrome/([0-9\.]+)|", $useragent, $matched)){
		$browser_version = $matched[1];
		$browser = "Chrome";
	}elseif(preg_match("|Safari/([0-9\.]+)|", $useragent, $matched)){
		$browser_version = $matched[1];
		$browser = "Safari";
	}else{
		$browser_version = 0;
		$browser = "Other";
	}
?>

The output of this will get you down to the very version number, so if you’ve got some philosophical disagreement with anyone running Firefox 3.0.12, you can pick that version out specifically (but why? WHY?!).

It’s a good idea to leave this whole code chunk intact an in order, because Opera can masquerade as IE if you’re just checking for IE, and Chrome will pretend it’s Safari if you’re just checking for Safari.

-pb

Javascript and Firefox

By Paul Bagosy - November 21st, 2008

Remember, folks, if you’re looking to affect an element’s height or width with JavaScript, you have to add “px” to the end if you want it to work in Firefox.

Firefox 2.0 Madness with floats

By Paul Bagosy - October 28th, 2008

After bashing my head against a wall for a while trying to figure out why one page in a site was dropping my floated sidebar div to the bottom of the page, I came across this:

http://www.davidbisset.com/2007/12/20/drop-down-list-breaks-float-layout-in-firefox/

Say you have two divs – both have floats so that they can end up being two columns on your site. But sometimes when you add a dropdown menu (<select> tag) to one div) it will break the layout… usually meaning that the other div will be pushed down. And this usually happens only in Firefox. IE sees it just fine.

The solution to this?  Instead of the nice linear coding that you’re used to where the sidebar, to the right of the main area, comes after the main area code, it needs to be before the main area code.

Because apparently, in FireFox 2 seems to have a problem with floated divs, option tags, and SIMPLE COMMON SENSE.

Improve the web with Nofollow Reciprocity.