Roger Black’s Advice for Young Designers

“On the skillset side, what you’ve got to do as a young person entering the field, is really equip yourself with some basic development skills. You have to be able to understand HTML and CSS. You have to know what JavaScript can do and what it can’t do. You don’t necessarily have to write cool JavaScript transitions, or even in CSS, but you’ve got to know what you can do in each. And you’ve got to be able to design so that if you have a more adept coder working with you, they know you know what you’re talking about.”
– Roger Black

How to use @font-face to avoid faux-italic and bold browser styles

Did you know that if you declare a custom font using @font-face, the browser will try to fake the bold and italic styles if it can’t find them? This is a clever little feature that avoids a scenario where a themer specifies a font and is then confused that bold and italics don’t work, but it can be very confusing if you actually have a bold or italic version of the font. In this article, I’ll walk you through how to properly load your font files to avoid the browser’s faux-italic and faux-bold styles.

Keep reading…

How to Add Theme Settings for Drupal 7

You know that list of checkboxes on the theme settings page that let you turn on and off parts of the theme like the logo or slogan? Well, you can add your own options to that list really easily in Drupal 7. In D6, this was kind of a pain, because you had to write all sorts of functions to save and load your settings to the database and handle everything properly. In D7, that’s all done through the Form API, so the heavy lifting is done for you. All you need to do is tell it to add some form fields, and what the new setting is called!

You’ll need to create a theme-settings.php file in your theme, and add this code to it:

<?php
function themename_form_system_theme_settings_alter(&$form, &$form_state) {
  $form['theme_settings']['your_option'] = array(
    '#type' => 'checkbox',
    '#title' => t('Your Option'),
    '#default_value' => theme_get_setting('your_option'),
  );
}
  • ['theme_settings'] is the existing fieldset to add your option to. You can leave it off, but by pointing it to the theme_settings group, it’ll be added to the existing list of checkbox display options for your theme. Handy!
  • ['your_option'] is the name of your new option.
  • #type tells Drupal what kind of form element to create.
  • #title is the title (or in this case, label) text for the form element.
  • #default_value tells Drupal where to find the initial setting for the form element.

We set #default_value to theme_get_setting('your_option'), which tells Drupal to look for this setting in the database. But here’s the brilliant part — if it can’t find that setting in the database, it will check in your theme’s .info file! So add this line:

settings[your_option] = 1

Now your theme will use the default setting unless the admin overrides it on the theme settings page.

You’ll want to actually do something with this setting, so here’s the PHP call to load it.

theme_get_setting('your_option');

You can call this in from any of your .tpl.php files. For a simple checkbox option like this, you can build an if() statement around it, like so:

<?php if (theme_get_setting('your_option')): ?>
  <!-- Your code here! -->
<?php endif; ?>

In this example, we added a checkbox, but you can add just about any form elements you can think of, including radio buttons and text input fields. What sort of options will you add to your theme?

References

Note: This was originally posted on my work blog, and I’m re-posting it here for archival purposes.

New York Times Claims HTML5 is a “Pandora’s Box” of Privacy Risks

Alarmist rhetoric from news organizations about the web is nothing new, but today’s front-page headline on the New York Times still caught my eye: “Web Code Offers New Ways to See What Users do Online.” It’s about HTML5 privacy risks, and it’s a load of crap.

In the author’s rush to scare her readers, she picked the wrong target. The article claims HTML5 will make it easier for advertisers to gather information about you. Through context it’s clear that the cause of concern is the web storage specification (which isn’t actually part of HTML5, but we’ll let that slide). The only real-world example of a privacy risk presented is “evercookie,” a persistant tracking cookie that is very difficult to delete. Evercookie is a legitimate security concern, and if the article had focused on that it would have been fine, but by putting HTML5 in the crosshairs it completely misses the point.

Here’s what the article has to say about how HTML5 will allow advertisers to track you:

The technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.

Assuming the article is referring to the web storage specification, this is all true — but you can also do all of this today, using existing tools. This is not some insidious new security threat that HTML5 introduces.

Hakon Wium Lie, the CTO of Opera, attempts to tone things down by pointing out that HTML5 “gives trackers one more bucket to put tracking information into.” One more — as in, the trackers already have many buckets. However, his quote is immediately followed by Pam Dixon of the World Privacy Forum — an organization that, as far as I can tell, consists only of Pam Dixon. She is quoted as saying “HTML 5 opens Pandora’s box of tracking in the Internet,” which is a wonderful scare quote, and I’m surprised they didn’t use it in the headline.

Even worse is the quote they got from Ian Jacobs at the W3C, who says “This is not a secret cabal for global adoption of these core standards.” Ian, I can see where you were going with that quote, but do me a favor. When trying to tone down an attack piece, don’t ever use the words “secret cabal,” even to say that you’re not part of one.

The crown jewel of the article is the section discussing Samy Kamkar, who is breathlessly introduced as having “creating a virus called the ‘Samy Worm,’ which took down MySpace.com in 2005.” It goes on to explain that he recently created the evercookie, an extremely persistant cookie that is intended to be difficult to delete. On the evercookie site, Samy explains:

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they’ve removed standard cookies, Flash cookies, and others. evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.

Now, to be fair, the evercookie does take advantage of HTML5 techniques like Web Storage, but this is just one of many storage vectors it takes advantage of. It also uses an Internet Explorer storage feature, PNG files, and Javascript, but you don’t see the article fretting over any of those technologies.

Despite all evidence to the contrary, the article attempts to paint Samy as some sort of white hat hacker who’s just looking out for the common man by highlighting security risks. Let’s ignore the fact that his previous claim to fame was writing a virus that crashed a major website. He goes out of his way to point out that he could have sold the evercookie code to advertisers, but didn’t. Instead, he published the technique for free on his website! His argument is that this will provoke the browser vendors to create better privacy tools to combat his cookie.

Well, I’m sorry, but I don’t think Samy deserves a pat on the back for this. This is like saying “Hey, I designed this really neat gun that never runs out of bullets, but don’t worry! I didn’t sell it to our enemies, I just put the plans on my website for anyone to read. Oh, you guys should probably start designing some body armor.”

If you can get past the rhetoric in the article, it’s clear that the risk to your privacy is real, but it’s not from HTML5. It’s from guys like Samy Kamkar.

Note: This was originally posted on my work blog, and I’m re-posting it here for archival purposes.