Category: HTML/CSS

I was setting up an HTML form today and I wanted to group some options together in a multi checkbox set, allowing a user to select multiple options in a category. I usually just give each checkbox a unique name and parse all of the individual values in PHP, but this has always struck me as an ugly way to handle this use case.

As I was looking up the syntax for an HTML checkbox, I found a lot of info that said I could simply name all of the checkboxes the same and it would group all of the values together like this:

<input type="checkbox" name="chk_group" value="value1" />Value 1<br />
<input type="checkbox" name="chk_group" value="value2" />Value 2<br />
<input type="checkbox" name="chk_group" value="value3" />Value 3<br />

But this doesn’t work. When you POST the values to PHP, you only receive the last item selected in the group. The annoying thing is that a lot of the examples online show this same syntax even though it’s clearly wrong. After digging a little deeper, I found this forum post with the correct syntax. Adding square braces to the checkbox name creates an array of the selected values in the group:

<input type="checkbox" name="chk_group[]" value="value1" />Value 1<br />
<input type="checkbox" name="chk_group[]" value="value2" />Value 2<br />
<input type="checkbox" name="chk_group[]" value="value3" />Value 3<br />

This can be retrieved in PHP with a simple loop:

<?php
if (isset($_POST['chk_group'])) {
    $optionArray = $_POST['chk_group'];
    for ($i=0; $i<count($optionArray); $i++) {
        echo $optionArray[$i]."<br />";
    }
}
?>

Simple! I thought I should post this correct solution in the hopes that it might help someone else wade through all of the wrong information out there.

SOLVED! Google web fonts not displaying on (some) macs

By Andy

On August 24, 2011

In HTML/CSS

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!

Why HTML5 is not going to kill Flash anytime soon.

By Andy

On June 22, 2010

In Flash, HTML/CSS, Uncategorized

html5_vs_flash Ever since Steve Jobs announced that Flash will NEVER be allowed on the iPhone or iPad, there has been a lot of talk about HTML5 – how it is going to kill Flash once and for all. Let’s just ignore the fact that Apple, Adobe, Microsoft, and Google all have a large financial stake in the outcome of this argument. What about the technical feasibility of replacing Flash with HTML5? Well, HTML5 has some pretty cool features, but it is not going to kill Flash anytime soon. Here’s why:

Reason #1: The browser support isn’t there yet.
There is a lot of talk about how “all the modern browsers already support HTML5.” Well, that may be true, if you ignore Internet Explorer in your list of modern browsers. Somewhere between 30% and 50% of people on the web use Internet Explorer. At least 8% of people are still using IE6, which is a decade old and doesn’t even fully support HTML4! And what about all of the people using outdated versions of Firefox? The modern browsers may already support HTML5, but modern browser market penetration is probably somewhere around 50% and it will be years before it reaches a level necessary for most people to adopt it as the standard. As a developer, I can tell you that most developers will be stuck programming in HTML4 for the next 5 years or more, because it’s hard to explain to clients why their mother can’t look at their fancy new website. Flash has a 98% market penetration. HTML5 won’t be able to compete with that for a long time.

Reason #2: There is still no video standard for HTML5.
This is a related issue to Reason #1. There are currently at least 3 video standards competing for dominance in HTML5. Most browsers support only one of the 3 formats. It’s a bit like the recent Blu-ray vs. HD DVD war. Eventually, one will be the winner, but in the meantime, no standard means hassles for developers. It is simply easier for developers (and clients) to build things to a standard that most people can view, so most of them will probably stick with Flash video for now (remember the 98% market penetration from reason #1).

Reason#3: No DRM on HTML5 video.
HTML can deliver video directly through your browser with no plug-in. That’s great. The other great thing about HTML5 video is that you can right-click the video and save it to your desktop. Well, it’s great for consumers, but the idea of putting video on the web with no DRM (Digital Rights Management) makes studio execs panic. There is NO WAY that movie and TV studios are going to put all of their content out there to be downloaded and stored on your hard drive. Many large video sites like hulu.com have already said that they will not be switching over to HTML5 until the DRM issue is resolved.

Reason #4: Developers can’t protect their intellectual property.
As a developer, I can tell you that programming games and rich web applications isn’t easy. It takes hundreds of hours to program a cool Flash game. Even if I could do it in HTML5 and Javascript, I’m not going to to do it. The reason is simple: HTML5 code is visible to anyone who visits my web page. If I’ve spent all that time creating a cool game, I don’t want to expose all of my code to everyone in the world. If I did that, there would be crappy clones of my game popping up all over the web within a week or two. Flash allows me to protect my intellectual property in a way that HTML5 doesn’t.

Reason #5: Coding for multiple browsers is easier in Flash.
Not only does Flash protect my code from prying eyes, it provides me with a single set of rules to follow for coding across multiple platforms (Windows, Mac) and multiple browsers (IE, Firefox, Safari, Chrome, etc). To create something cool in HTML5, I would need to use Javascript. The simple fact is: Javascript sucks. It behaves differently in different browsers and you spend more time tracking down weird, browser-specific bugs than you do actually creating awesome web apps. Flash just makes development easier (and ultimately cheaper for clients).

Reason #5: HTML5 simply can’t compete with Flash in providing a rich media experience.
HTML5 has some animation capabilities built in to it, but Flash is way ahead of it in this regard. Flash provides a Graphical interface that a designer can use to create incredible animations and graphics. HTML5 requires a programmer to create cool animations. Flash is more powerful and easier for people to work with. I’m not saying that HTML5 and Javascript won’t catch up to Flash, but it won’t happen for a long time.

Reason #6: HTML5 is slower than Flash.
Ever since Apple’s announcement, people have assumed that what Steve Jobs said was true – Flash is too slow for the iPhone. Well, a number of clever people have actually run speed comparisons between Flash and HTML and have found that HTML5 is generally SLOWER and MORE RESOURCE INTENSIVE than Flash. Ouch. That doesn’t sound like progress to me.

Reason #7: Nobody really cares.
Frankly, most people don’t care how they get their content, as long as they get it. Despite what Steve Jobs thinks, no one really cares what technology is used to allow them to watch videos on YouTube. Even the Apple fankids who are applauding the decision not to put Flash on the iPhone probably don’t really care – most of them had never heard of HTML5 before this announcement and most of them still don’t really know what Jobs is talking about . It’s all about delivering the content. If Apple can’t give people the content they want, then people will use a different technology.

Obviously, I make my living as a Flash developer, so you may be inclined to think that I’m biased towards Flash. That may be true, but I am really just a developer – I will use whatever tools are best for the job. Right now, Flash is the best tool for creating a rich web experience . It has the best combination of capabilities and market penetration. HTML5 simply can’t compete with it right now.

Need more info? Here are some links I’ve found that are great resources for HTML5 development:

A video discussing the HTML5 vs Flash debate from a developer’s perspective

A good explanation of HTML5 video and how to properly implement it for best cross-browser support

Latest news and articles about HTML5 video

CSS sticky footer without javascript

By Andy

On July 3, 2009

In HTML/CSS

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.

CSS sticky footer

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!

We'll give you something to cry about

Category: HTML/CSS

HTML Multi checkbox set – the correct way to group checkboxes

SOLVED! Google web fonts not displaying on (some) macs

Why HTML5 is not going to kill Flash anytime soon.

CSS sticky footer without javascript