BlogmyQuery – BMQ

E-commerce runs on secrets. Those secrets let you update your blog, shop at Amazon and share code on GitHub. Computer security is all about keeping your secrets known only to you and the people you choose to share them with.

We’ve been sharing secrets for centuries, but the Internet runs on a special kind of secret sharing called public-key cryptography. Most secret messages depend on a shared secret—a key or password that everyone agrees on ahead of time. Public-key cryptography shares secret messages without a shared secret key and makes technologies like SSL possible.

Cryptography is a scary word: it conjures thoughts of complex equations and floating-point arithmetic. Cryptography does have a lot of math, but it’s more about keeping and sharing secrets.

A Simple Secret

Telling my best friends a secret is easy: I find a private place and whisper it in their ears. As long as no one is listening in, I’m totally secure. But the Internet is full of eavesdroppers, so we need codes.

We’ve all been inventing codes since we were children. I created this simple number code (actually a cipher) when I was 5:

a=1, b=2, c=3, d=4, e=5…

It fooled my friends, but not my parents. Simple substitution ciphers are based on a lack of knowledge. If you know how they work, then you can decode every message. The experts call this “security through obscurity.� Letter and number substitutions don’t work on the Internet, because anyone can look them up on Wikipedia. For computer security, we need codes that are still secure even if the bad guys, or your parents, know how they work.

The most secure code is still easy to use: a “one-time pad.� One-time pads have been used for centuries, so they don’t even need computers. They played a big part in World War II, when each pad of paper with the key numbers was used only once.

Let’s say I wanted to send you this secret message:

I love secrets

First, I’d turn the message into numbers using my simple cipher from when I was 5. (I’ve heard rumors that other people had this idea first, but I don’t believe it.)

Then I’d mash my keyboard to generate a random key string for my one-time pad.

Now I can add the two strings together. If my number is greater than 26, I would just wrap it around to the beginning. So, i(9) + e(5) = n(14), and o(15) + t(20) = i(35 - 16 = 9). The result is an encrypted string:

Decrypting the string to get the secret back is easy. We just subtract the one-time pad: n(14) - e(5) = i(9). Follow that pattern through the entire message, and you can securely share a secret. You don’t even need a computer: just work it out with a pen and paper.

This function is called a symmetric-key algorithm, or a shared-key algorithm, since it uses the same key to encrypt and decrypt the message. Modern systems can safely use the pad more than once, but the basic idea is the same.

The one-time pad is totally secure because the bad guys don’t know how we got the encoded letter. The n could be i + e, j + d or any other combination. We can use our shared secret (the one-time pad) once to share another secret.

But there’s a fatal flaw. We need to share the one-time pad ahead of time before we can start sharing secrets. That’s a chicken-and-egg problem because we can’t share the pad without worrying that someone will snoop. If the bad guys get the one-time pad, then they would be able to read everything.

One-time pads help me share secrets with my best friends, but I can’t use them with strangers such as Amazon or Facebook. I need a way to share something publicly that doesn’t compromise my one-time pad. I need a public key.

The Public-Key Backpack

Public-key encryption focuses on a single problem: how do I prove that I know something without saying what it is? An easy concept to help us understand this is a backpack full of weights.

I want to prove that I know which weights are in my pack, but I don’t want to tell you what they are. Instead of showing you all of the weights separately, I’ll just tell you the total. Now you can weigh the pack and see if I’m right without ever opening it.

If the pack weighs 20 kilos, then you wouldn’t know if it has one 20-kilo weight, twenty 1-kilo weights or something in between. With a large number, you can be pretty confident that I know what’s in the pack if I know the total; you don’t have to see inside. The weight of the backpack is the public part, and the individual weights are the private part.

This basic backpack enables us to share a secret without really sharing it. If we each have a backpack, then we can both share secrets.

The backpack works well enough for smaller numbers, but it isn’t useful in the real world. Backpack algorithms were a mere curiosity for decades. Then RSA changed everything.

RSA

RSA was the first public-key encryption system that worked in the real world. Invented more than 30 years ago, it coincided with the introduction of the more powerful computers that were needed to run the big numbers. RSA is still the most popular public-key encryption system in the world.

The basic premise of RSA is that factoring large numbers is difficult. Let’s choose two prime numbers: 61 and 53. I’m using the numbers from Wikipedia’s article on “RSA� in case you want more details.

Multiply these two numbers and you get 3233:

61 × 53 = 3233

The security of RSA comes from the difficulty of getting back to 61 and 53 if you only know 3233. There’s no good way to get the factors of 3233 (i.e. the numbers that multiply to make the result) without just looking for all of them. To think of this another way, the weight of our backpack is 3233 kilos, and inside are 61 weights weighing 53 kilos each. If you make the resulting number large enough, then finding the numbers that produced it would be very difficult.

Public And Private Keys

Unlike the one-time pad, RSA uses the public key to encrypt information and the private key to decrypt it. This works because of the special relationship between the public and private keys when they were generated, which allows you to encrypt with one and decrypt with the other.

You can share the public key with anyone and never reveal the private key. If you want to send me a secret message, just ask for my public key and use it to encrypt the message. You can then send it to anyone you want, and you’ll know that I’m the only one who can decrypt the message and read it.

I could send you a message in the same way. I would ask for your public key, encrypt the message using it and then send it to you to decrypt. The popular program Pretty Good Privacy (PGP) worked like that. We’re secure as long as we both keep our private keys private.

Exchanging keys is made even easier by special key servers that allow you to search for people and find their public keys.

Public-key encryption also works in reverse to provide digital signatures. Let’s say I want to write a message and prove that I wrote it. I just encrypt it with my private key and post it. Then anyone who wants to check can decrypt it with my public key. If the decryption works, then it means I have the private key and I wrote the message.

RSA is relatively simple: take two numbers (the private key), apply some math, and get a third number (the public key). You can write out all of the math in a few lines, and yet RSA changed the world. Business doesn’t work on the Internet without public-key encryption.

RSA And HTTPS

We use public-key encryption every day with HTTPS. When you access Facebook, Twitter or Amazon with HTTPS, you’re using a simple encryption mechanism like the one-time pad, but you’re creating the pad with public-key encryption. Without HTTPS, anyone else at Starbucks could read your credit-card number, Facebook password or private email while sipping a latte.

Amazon has a certificate from a company named VeriSign. The certificate certifies that Amazon is Amazon, and it contains its public key. Your browser creates a special key just for that session and encrypts it using Amazon’s public key. Then it sends it over the Internet, knowing that only Amazon can decrypt the session key. Once you’ve exchanged that secret key, you can use it as the one-time pad to protect your password and credit-card number.

You could keep using public-key encryption for the whole session, but because of all the math, it’s much slower than the one-time pad.

RSA And GitHub

Another place many of us use RSA is GitHub. Every time you push a change to GitHub or pull from a master branch, GitHub has to make sure you have permission to make the change. It gets its security through a secure command shell using RSA.

Remember when you set up your GitHub account and followed some commands to generate keys?

You used the SSH-Keygen tool to generate a new RSA private/public key pair. Then you went to your GitHub account page and entered your public key.

Now, when GitHub needs to authenticate you, it asks your computer to sign something with your private key and return the signed data. With your public key, GitHub can confirm that the signature is authentic and could only have been produced by someone who has the corresponding private key—even though GitHub itself doesn’t have that private key.

That’s better than a simple password because nobody can snoop it. And if GitHub ever gets hacked, your private key won’t be in danger because only you have it.

Sharing Passwords

When WordPress.org was “hacked�, it wasn’t really hacked. WordPress plugin developers, like everyone else, have accounts on other websites. They also reuse their passwords. When hackers cracked those other websites, they used the stolen passwords to log into WordPress.org and make malicious changes to plugins.

Most people use the same user name and password on multiple websites. That makes your website only as secure as everyone else’s. Public-key encryption changes that. Because you never have to share your private key, it doesn’t matter if other websites get hacked. If an attacker breaks into GitHub and gets your public key, they can’t use it to impersonate you or log in as you on other websites. Only someone with your private key can do that, which is why your private key remains safe on your computer. Using public-key cryptography makes GitHub much more secure.

GitHub Gets Hacked

GitHub was hacked recently, but not because the encryption failed. Real-world security breaches are caused by problems in implementation, not in math.

In this case, the hacker was able to exploit a hole and add his public key to the Ruby on Rails repository. Once the key was added, GitHub used it to verify the hacker’s identity and granted him access. We’re lucky this hacker was friendly and told GitHub about the issue.

Once the problem was fixed, you could keep using your private key because GitHub never had it to lose; it stayed on your machine. Public keys saved GitHub from serious problems.

The weakest link in GitHub’s security was in the mechanism that allowed clever users to add public keys to other projects without being authorized. The math was perfect, but the implementation wasn’t.

Public Keys In The Wild

Knowing the fundamentals is essential (you might say the key) to writing secure applications. The math is complex, but the basics are simple:

• There are two main types of encryption: shared-key encryption, such as a one-time pad, and public-key encryption, which uses public and private keys.
• Shared-key encryption is faster, but sharing the keys is difficult.
• RSA is the most popular public-key encryption algorithm, but a few others are in general use, as well as some cool experimental systems.
• Public-key cryptography works best in combination with other technologies.
• Don’t ever share your private key with anyone.

When it comes time to implement public-key cryptography in your application, don’t. RSA and other algorithms are already implemented in all major languages. These libraries include extra security features such as padding and salts, and they have a lot of testing behind them.

Most security flaws come from poor implementations and misunderstanding about the libraries. You don’t have to write your own cryptography libraries, but you do have to know the fundamentals so that you can use the ones that are out there.

Illustrations in this article were provided by Robb Perry.

(al) (km)

---

© Zack Grossbart for Smashing Magazine, 2012.

In my nearly two decades as an information architect, I’ve seen my clients flush away millions upon millions of dollars on worthless, pointless, “fix it once and for all� website redesigns. All types of organizations are guilty: large government agencies, Fortune 500s, not-for-profits and (especially) institutions of higher education.

Worst of all, these offending organizations are prone to repeating the redesign process every few years like spendthrift amnesiacs. Remember what Einstein said about insanity? (It’s this, if you don’t know.) It’s as if they enjoy the sensation of failing spectacularly, publicly and expensively. Sadly, redesigns rarely solve actual problems faced by end users.

I’m frustrated because it really doesn’t have to be this way. Let’s look at why redesigns happen, and some straightforward and inexpensive ways we might avoid them.

The Diagnostic Void

Your users complain about your website’s confounding navigation, stale content, poor usability and other user experience failures. You bring up their gripes with the website’s owners. They listen and decide to take action. Their hearts are in the right place. But the wheels quickly come off.

Most website owners don’t know how to diagnose the problems of a large complex website. It’s just not something they were ever taught to do. So, they’re put in the unfortunate, uncomfortable position of operating like country doctors who’ve suddenly been tasked to save their patients from a virulent new pandemic. It is their responsibility, but they’re simply unprepared.

Sadly, many website owners fill this diagnostic void — or, more typically, allow it to be filled — with whatever solution sounds best. Naturally, many less-than-ethical vendors are glad to dress up their offerings as solutions to anyone with a problem — and a budget. The tools themselves (search engines, CMS’, social apps) are wonderful, but they’re still just tools — very expensive ones, at that — and not solutions to the very specific problems that an organization faces. Without proper diagnostics to guide the configuration of tools, any resulting improvements to the user experience will be almost accidental.

Sometimes design agencies are brought in to fill the diagnostic void. And while not all agencies are evil, a great many follow a business model that depends on getting their teams to bill as many hours as they can and as soon as possible. Diagnostics can slow the work down (which is why clients rarely include a diagnostic phase in their RFPs). So, many agencies move to make a quick, tangible impression (and make their clients happy) by delivering redesigns that are mostly cosmetic.

A pretty face can last only a few years, but by then the agency is long gone. Invariably, the new owner wishes to make their mark by freshening or updating the website’s look. And another agency will be more than happy to oblige. Repeat ad nauseam, and then some.

Oh, and sometimes these redesigns can be pricey. Like $18 million pricey.

See why I’m so grouchy?

Forget the Long Tail: The Short Head Is Where It’s At

Whether you’re a designer, researcher or website owner, I’ve got some good news for you: diagnostics aren’t necessarily difficult or expensive. Better yet, you’ll often find that addressing the problems you’ve diagnosed isn’t that hard.

And the best news? Small simple fixes can accomplish far more than expensive redesigns. The reason? People just care about some stuff more than they care about other stuff. A lot more. Check this out and you’ll see:

This hockey-stick-shaped curve is called a Zipf curve. (It comes from linguistics: Zipf was a linguist who liked to count words… but don’t worry about that.) Here it is in dragon form, displaying the frequency of search queries on a website. The most frequently searched queries (starting on the left) are very, very frequent. They make up the “short head.� As you move to the right (to the esoteric one-off queries in the “long tail�), query frequency drops off. A lot. And it’s a really long tail.

This is absolutely the most important thing in the universe. So, to make sure it’s absolutely clear, let’s make the same point using text:

Query’s rank	Cumulative %	Query’s frequency	Query
1	1.40%	7,218	campus map
14	10.53%	2,464	housing
42	20.18%	1,351	web enroll
98	30.01%	650	computer center
221	40.05%	295	msu union
500	50.02%	124	hotels
7,877	80.00%	7	department of surgery

In this case, tens of thousands of unique queries are being searched for on this university website, but the first one accounts for 1.4% of all search traffic. That’s massive, considering that it’s just one query out of tens of thousands. How many short-head queries would it take to get to 10% of all search traffic? Only 14 — out of tens of thousands. The 42 most frequent queries cover over 20% of the website’s entire search traffic. About a hundred gets us to 30%. And so on.

It’s Zipf’s World; We Just Live in It

This is very good news.

Want to improve your website’s search performance? Don’t rip out the search engine and buy a new one! Start by testing and improving the performance of the 100 most frequent queries. Or, if you don’t have the time, just the top 50. Or 10. Or 1 — test out “campus mapâ€� by actually searching for it. Does something useful and relevant come up? No? Why not? Is the content missing or mistitled or mistagged or jargony or broken? Is there some other problem? That, folks, is diagnostics. And when you do that with your website’s short head, your diagnostic efforts will go a very long way.

The news gets better: Zipf is a rule. The search queries for all websites follow a Zipf distribution.

And the news gets even jump-up-and-down-and-scream-your-head-off better: Zipf is true not only for your website’s search queries. Your content works the same way! A small subset of your website’s content does the heavy lifting. Much of the rest has little or no practical value at all. (In fact, I’ve heard a rumor that 90% of Microsoft.com’s content has never, ever been accessed. Not once. But it’s a just a rumor. And you didn’t hear it here.) Bottom line: don’t redesign all of your content — focus on the stuff that people actually need.

You’ll also see a short head when it comes to your website’s features. People need just a few of them; the rest are gravy.

And there’s more. Of all the audience types that your website serves, one or two matter far more than the others. What tasks do those audience types wish to accomplish on your website? A few are short-head tasks; the rest just aren’t that important.

As you can see, the Zipf curve is everywhere. And fortunately, the phenomenon is helpful: you can use it to prioritize your efforts to tweak and tune your website’s content, functionality, searchability, navigation and overall performance.

Your Website Is Not A Democracy

When you examine the short head — of your documents, your users’ tasks, their search behavior and so forth — you’ll know where to find the most important problems to solve. In effect, you can stop boiling the ocean…

… and start prioritizing your efforts to diagnose and truly solve your website’s problems.

Now, let’s put these short-head ideas together. Below is a report card for an academic website that starts with the short head of its audience:

In other words, of all the audience types this university website has, the three most important are people who might pay money to the university (applicants,) people who are paying money now (students) and people who will hopefully pay money for the rest of their lives (alumni). How do we know they’re the most important audiences? We could go by user research; for example, the analytics might suggest that these audiences generate more traffic than anyone else. Or perhaps the university’s stakeholders believe that these are the most important ones in their influence and revenue. Or some combination of both. Whatever the case, these three audiences likely swamp all other segments in importance.

Then, we would want to know the short-head tasks and information needs of each audience type. We might interview stakeholders to see what they think (column 2). And we might perform research — user interviews and search analytics, for example — to find out what users say is most important to them (column 3).

Of course, as the good folks at xkcd demonstrate, stakeholders and users don’t always see things the same way:

That’s why talking to both stakeholders and users is important. And once you’ve figured out the short head for each, you’ll need to earn your salary and, through some careful negotiation, combine your takes on each audience type’s needs. That’s what we’ve done in column 4.

Finally, in column 5, we’ve tested each task or need and evaluated how well it works. (Because it’s a university-related example, letter grades seemed appropriate.) You can do this evaluation in an expensive, statistically significant way; but really, enough research is out there to suggest that you don’t need to spend a lot of time and money on such testing. More importantly, these needs and tasks are often fairly narrow and, therefore, easy to test.

So, after testing, we can see what’s not going well. Finding information on “mentoring� is hard for applicants. And current students have a devil of a time when they “look up grades.�

Now we’re done diagnosing the problems and can begin making fixes. We can change the title of the “Paired Guidance Program� page to “Mentoring.� We can create a better landing page for the transcript application. The hard part, diagnostics, is out of the way, and we can now fix and tune our website’s performance as much as our resources allow.

From Project To Process To Payoff

These fixes are typically and wonderfully small and concrete, but because they live in the short head, they make a huge and lovely impact on the user experience — at a fraction of the cost of a typical redesign.

The tuning process itself is quite simple. It’s what we used to arrive at the report card below:

If you repeat this simple process on a regular basis — say, every month or quarter — then you can head off the entropy that causes fresh designs and fresher content to go rotten. Thus, the redesign that your organization has scheduled for two years from now can officially be canceled.

Your website’s owners ought to be happy about all this. And you should be, too: rather than tackling the project of getting your website “rightâ€� — which is impossible — you can now focus on tweaking and tuning it from here on out. So, forget redesigns, and start owning and benefiting from a process of continual improvement.

Special Thanks – Illustrations

Eva-Lotta is a UX Designer and Illustrator based in London, UK where she currently works as an interaction designer at Google. Besides her daytime mission of making the web a more understandable, usable and delightful place, she regularly takes sketchnotes at all sorts of talks and conferences and recently self-published her second book. Eva-Lotta also teaches sketching workshops and is interested in (something she calls) visual improvisation. Exploring the parallels between sketching and improvisation, she experiments with the principles from her theater improvisation practice to inspire visual work.

(al)

---

© Louis Rosenfeld for Smashing Magazine, 2012.

Responsible responsive design demands responsive images—images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users. Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed—and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element. Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them� crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.

The idea behind this project was to produce a consistent set of buttons that could be used for the range of social actions frequently taken in Web applications. These actions are often important goals for users, such as connecting third-party accounts or sharing content to third-party platforms, so their appearance has to be attractive and clear.

The standard buttons provided by third parties (such as Facebook, Twitter and SoundCloud) vary in size, style and interactivity. A consistent button set could reduce a lot of that visual noise and inconsistency. Furthermore, having it in CSS format means that changing the text for certain actions would be a breeze for developers, and it also allows administrators of non-English websites to translate labels into their native languages.

The button set was designed from the beginning to require no extra markup, and the elements used are entirely the choice of the (semantically considerate) designer. All buttons are fully scalable and customizable, and they degrade gracefully on older browsers, although the aesthetics in IE 6 and 7 are admittedly inferior to image-based alternatives.

No raster images or sprites were used. Instead, vector icons were inserted using a custom font file, an @font-face rule and pseudo elements. For more information, John Hicks has an informative write-up on this technique.

Download The Button Set For Free

This button set is free to use and extend, personally or commercially. No attribution is required.

• Preview
• Demo
• Download the package (ZIP, 147 KB)
• GitHub repository (handwritten CSS)
• Sass framework (six buttons) (by @adamstac)

Features

• 100%-vector CSS3 buttons
• @font-face icons and custom font files
• 72 services supported
• Button and icon versions supported
• Em sizing for full scalability
• Generic primary and secondary action buttons for consistency
• Graceful degradation on older browsers

Preview

Screenshots of each set are below. Or view a live demo.

Usage

The button set was designed with simplicity and semantics in mind. No unnecessary or extra markup is required, and button types are called through class names. Call the zocial.css file on your page (make sure the font files and the zocial.css file are in the same directory). Buttons can be displayed with the following markup:

<button class="zocial facebook">Sign in with Facebook</button>

The parent element is agnostic, so you may use <a>, <div> or <button>, but it must contain a child <span> element. [Thanks, Lea!]

To choose buttons from the set, include the appropriate class name for the service, such as .dropbox, .linkedin or .twitter.

Icon versions can be displayed by including an extra .icon class, as follows:

<a class="zocial quora icon">Follow me on Quora</a>

More code samples are available on the Zocial page.

(al)

---

© Sam Collins for Smashing Magazine, 2012.

Editor’s Note: This post is the first in the new Smashing Daily series on Smashing Magazine, where we highlight items to help you stay on the top of what’s going on in the industry. Vasilis van Gemert will carefully pick the most interesting discussions, tools, techniques and articles that were published recently and present them in a nice compact overview. Smashing Daily #2 and Smashing Daily #3 are now published, too.

Vasilis goes through dozens of RSS feeds and hundreds of tweets so that you don’t have to. Do you find the new series interesting? What would you like to have? And what wouldn’t you like to see? Let us know! We’d love to hear your feedback in the comments!

A couple of words from Vasilis himself:

“Years ago I started collecting links, and once a week I would write an email to my colleagues with a small introduction to every link. Later on I decided that more people than just my colleagues might benefit from this collection, so I decided to publish everything on The Daily Nerd.

“Last November, during the Fronteers conference in Amsterdam, Lea Verou convinced me to start writing in English; up until then, I wrote my comments in Dutch. More and more people started following me, and I think that’s a good thing; I believe more talented people than me should know the things I know. By more talented people, I of course mean you, the reader, so you can understand just how excited I was when Vitaly Friedman asked me if I wanted to start publishing the Daily Nerd on Smashing Magazine. So, here we are, the first episode of the Smashing Daily! I hope you like it!”

Smashing Daily #1: Mobile Device Lab, Browsers and Animated GIFs

Your local mobile device lab
Jeremy Keith started an open local mobile device lab in Brighton, and he urges you to do the same in your home town.

Web font performance: Weighing @font-face options and alternatives
An important part of design and UX is performance, so when you decide to use a Web font, you should definitely know what the negative impact that choice might have on your users. Here’s an excellent in-depth article about font performance. Yes, you should definitely read it (and the comments, too, because they’re actually quite good).

Miscellany #7,� Shady Characters
Here’s a short post by Keith Houston, with news and thoughts about unusual characters. A pleasure to read, like everything else on his blog.

TypeStacks: Instant font stacks based on your font
Here’s a nice tool that suggests a font stack based on your chosen font. It knows the fonts served by TypeKit, although it doesn’t seem to know too many Google Fonts. Still, a very handy tool.

Let’s Get Physical (Units)
There are a few occasions when we’d love to use physical units (such as cm and in), but unfortunately these units don’t work as expected in CSS. Boris Smus has written an extensive article about these units, how they should work, why we want them and why they work the way they work.

Cutting the Mustard
The BBC is working on a responsive news website, and it is sharing everything it finds out, which is extremely useful. In this article Tom Maslen explains how the BBC manages browser support. An absolute must read for anybody who is struggling with the growing complexity of browser support. This solution (or something similar) should be implemented everywhere.

H5BP
Here’s an overview of projects related to the HTML5 Boilerplate. Some excellent stuff is in there, but before you start using everything in there, remember the excellent advice of Rachel Andrew: “Stop solving problems you don’t yet have.�

html5shiv and Serving Content From Code Repositories
Never just link to scripts hosted on other domains, because you won’t always get the advantages, such as caching and Gzip. This is explained in detail in this excellent article. Yes, you should definitely read it.

Thinking Async
Loading an external JavaScript file can block the rest of the page from loading, which of course is a major performance and usability problem. The solution is to load scripts asynchronously, and Chris Coyier shows us ways to do that, extensively as always.

Experience Design Is the Future of Mobile Payments
“Holisticâ€� means something like “complete.â€� So, Perry Chan argues that a “completeâ€� user experience is the future of mobile payments. I actually think that right now, in the short run, whatever the future, the things we have right now are just terrible. Anything would less painful (at least here in the Netherlands). (I also think the future of UX on the Web is bigger fonts — much bigger).

Learn CSS selectors interactively
CSS selectors can be pretty hard to understand, especially the difference between nth-child and nth-of-type. There are many tools to visualize the difference, and this is another one by Ben Howdle.

Allen Tan on highlighting and focus,� Readmill Blog
My father always scribbles annotations in the margins of his paper books. He’s probably been doing this for more than 50 years now, and if somehow we could assemble these annotations, it would be an incredibly interesting and useful database. But as it is, it’s pretty useless. Allen Tan writes about this and more in this article on modern digital reading.

Browser Support
If, for whatever reason, you don’t like any of the tools or websites out there that tell you what browsers support what CSS feature, then this tool might be the one you’re looking for. I still prefer When Can I Use… or Mozilla Developer Network Docs, though.

Stamen
Your app needs a map, but you want something other than boring old Google Maps? You could try OpenStreetMap with one of these beautiful map tiles.

Browser Support? Forget It!
What does “browser support” mean exactly? Some think it means pixel perfection for a predefined set of browsers. According to David Bushell, it means something else. This is a good read for people (or clients) who struggle with the ever-expanding browser landscape.

The id Attribute Got More classy in HTML5
One of the easy ways to get a somewhat unique ID is by using the UNIX epoch time, which generates a string like 1336984564. The problem is that in HTML, an ID had to begin with a letter. Mathias Bynens tells us if this is still the case in HTML5.

Autofill City and State From Zip Code With Ziptastic
Filling out forms is a pain in the butt, especially on devices without a traditional keyboard. You should be asking users for as little information as possible. If there were a way to make things easier, you should probably do it. For instance, you could prefill parts of an address when the user enters their ZIP code. Chris Coyier shows us what a flow like that could look like.

CSS Layout Gets Smarter With calc()
A thing we needed desperately before being able to use box-sizing: border-box was the ability to mix different CSS units. There are still some use cases for this, though, and luckily more and more browsers are supporting the calc() property. Here’s how it works.

Last Click

The Origin of the <blink> Tag
Here’s the true story behind the blink tag by the guy who came up with the idea, Louis J. Montulli II. A nice anecdote on early browser history.

mr. div
Of course, you could use a simple Web technology like canvas or WebGL to generate beautiful animations, but why do it the easy way when you could use the ever-amazing animated GIF? Here’s a great Tumblr blog to follow if you’re looking for some random fantastic 4-D inspiration.

What Do You Think?

Do you like this new series? What would you like to see in it? Please provide some feedback, and let us know what you think!

(al) (vf) (il)

---

© Smashing Editorial for Smashing Magazine, 2012.