After months of procrastination and delays, I’m proud to officially release Kenny Login – a fully responsive HTML5 theme for your WordPress Login page. Version 1.0.0 is available now as a free WordPress plugin. Simply install the plugin and activate it through your admin panel. Blam! Kenny Loggins all up in your login page! Click here to get the lowdown.
Log in to the Danger Zone!
If you are doing front-end web development, you likely use Firebug. It’s a Firefox browser extension that provides all the basic tools you need to debug a website. Development tools in all of the modern browsers are based on the gold standard set by Firebug.
One of the most common uses of Firebug is to make changes to your CSS in real time. You can experiment with different styles until your layout looks right, then simply cut and paste everything into your stylesheet.
This works great for desktop browsers, but mobile browsers don’t have development tools. If you want to debug your mobile layout, you need another browser extension that allows you to switch the user agent. There are a number of good ones out there. I’m currently using User Agent RG for Firefox. Once this extension is installed, you can change the user agent string by going to the “Tools” menu and choosing “User Agent.” Simply choose a mobile device and you can get an idea of what your site looks like on a mobile device.
It’s important to understand what the user agent switcher does (and doesn’t do). What it does is tell the browser the type of device that you are using to browse the web. The Firefox plugin basically lies and says “I am using an iPhone” (or whatever). If you have a mobile version of the website, that version will be displayed.
What it does NOT do is make Firefox act like Mobile Safari, or any other browser. If there are browser-specific layout issues, you will not be able to see them with the user agent switcher. Luckily, mobile device browsers are fairly standards-compliant, so very few CSS issues are browser-related. Browser-specific issues like HTML5 video issues (*cough* Mobile Safari *cough*) still need to be debugged with that browser.
The other thing that user agent switching doesn’t do is resize your site to mobile browser dimensions. To get an accurate sense of how your site looks on a phone or tablet, you will probably need set a body width in your CSS:
body {
width: 320px; /*older iphone width*/
}
This way, you can lock it to the dimensions of the device you want to test and tweak the CSS with Firebug to fix any layout problems.
This has been the quickest and easiest way I have found to fix mobile-specific layout issues. Good luck!
Google web fonts are great. If you don’t know about them, you really need to check them out. They enable you to embed non-standard fonts into your website …and you don’t have to worry about any font licensing issues. But, we recently ran into a problem at work with Google web fonts – they weren’t displaying correctly on some Macs and Apple products. The really frustrating thing is that they worked fine on most Macs, but on some machines they didn’t work at all, no matter which browser we used. The fonts worked correctly on the Google web fonts site, but not when we used the Google code samples on our own sites.
One of my coworkers dug into the issue and found an undocumented solution. Simply add the !important hack to the font-face declarations in your CSS wherever you specify a Google font. Problem solved! Here’s a quick example:
<head>
...some meta tags and junk here...
<link href="http://fonts.googleapis.com/css?family=Rokkitt" rel="stylesheet" type="text/css"></link>
<style="text/css">
...some styles...
h1 {
font-family: 'Rokkitt', serif !important;
}
...some more styles...
</style>
...more junk here maybe...
</head>
We never did figure out what is causing the issue, or why it only occurs on some Macs. Ultimately, though, we don’t care why it happens, as long as we can fix it. Anyway, since this bug is undocumented as far as I can tell, I thought I’d share this simple hack that fixes it. Thanks to my coworkers at Toolbox No.9 for solving the problem!
UPDATE: The code I have provided here has a bug in Internet Exploder. Until I get it updated, I suggest you get a working sample here. Thanks.
Occasionally, a website design requires a “sticky footer” – that’s a footer that sticks to the bottom of the browser window when the content is not long enough to fill the browser. If the content is longer than the browser height, it should push the footer down below the content. It’s an easy task with a table-based layout, but it can be surprisingly tricky to pull off with pure CSS layouts.
Just the other day, someone asked me how to do this and I couldn’t remember how it was done off the top of my head, so… voila! a blog post was born. I have created 2 samples of the CSS-based sticky footer that work correctly in all major browsers for footers with a fixed height. No javascript is needed to pull off this effect.
Example 1 shows the most basic scenario. Resize your browser and notice how the footer sticks to the bottom of the window until it hits the bottom of the content area. It is then forced below the content, exactly as it should be.
Example 2 is a slightly fancier version that shows you how to get a sticky footer on a centered layout. Again, the layout is CSS-based and has been tested in Firefox (2 & 3), Safari, Internet Explorer (6, 7 & 8), and Google Chrome.
You can download the source files here. If you’re a CSS ninja, there are enough comments in the files for you to figure it out. Otherwise, I’ll explain some of the details here:
First, open the basic example HTML and look at the top of the code. The first line of code establishes the HTML doctype. You MUST have a valid doctype for the sticky footer to work. I have only tested it with the transitional doctype used in the examples. It should work with other valid doctypes, but you should test it thoroughly if you need to use another doctype.
Next, look at the line that declares the “main_styles.css” stylesheet. This stylesheet contains all of the css for the page. The next 3 lines specify a second stylesheet that contains only CSS overrides for Internet Explorer 6 and 7. This is the cleanest and easiest way I have found to deal with IE problems and it doesn’t require any hacks in the main stylesheet.
The DIV structure is pretty self-explanatory, but note that the footer is not contained inside of the “wrapper” div. It must be outside of the wrapper for the sticky footer.
Next, open “main_styles.css” – the comments should explain everything you need to know to make the sticky footer work. Note that the wrapper div has a min-height declaration. This is why we need a second stylesheet – IE 6 and 7 do not observe min-height correctly. If you open the ie_styles.css” file, you will see that the only style in it sets the height of the wrapper div. IE 6 and 7 treat height as if it was min-height, forcing the footer below the content area. IE 8 appears to follow the standards when it comes to min-height, so no override is needed for it.
Hopefully, the source files will provide you with templates that you can use to start building pages with a sticky footer. Good Luck!
Powered by WordPress & Theme by Anders Norén