Alex Lande

The Idea Grip

2016-01-19T00:00:00+00:00

A professor once gave me some advice: “Hold your ideas firmly with the tips of your fingers.”

He picked up a piece of paper to demonstrate. He could wave it around, or walk with it on a windy day, and the sheet would stay in place. If you yanked it away, the sheet would slip through his fingertips and drift away.

The professor was a scientist, and in his metaphor the hand that pulled the idea away was new evidence. It’s a difficult thing to have a good idea, and an even more difficult thing to believe in it. This challenge often leads us to guard our ideas with jealousy and passion. This is a good thing, to a degree. If we don’t hold firm, minor criticisms and bad days will tear ideas away. If we hold with balled fists, ideas cling to us when they’re no longer useful. The key, as in most things, is balance.

In science, particularly in fields with long and rich histories, some ideas become so engrained in a generation of scholars that they can’t be replaced until the scholars themselves are replaced by a new generation. This occurs despite sometimes overwhelming evidence against the older theory. The result of this phenomenon is a long-overdue paradigm shift.

In faster moving fields like the web, these shifts occur on a fraction of the time scale, but the principle remains the same. I think about my professor’s advice often, and strive to reflect upon and reconsider my ideas as things change. Hopefully I’m holding on to them just firmly enough.

The Mouse is an Enhancement

2016-01-13T00:00:00+00:00

There is likely no more common symbol of personal computing (and the web, as an extension) than the mouse. This clever tool is an intuitive, accessible harness for the power of the computer. Most people would be completely lost trying to navigate the web without it. If you’re one of those people, it’s easy to overlook the large numbers of people who use the web without a mouse. It’s time that we start prioritizing these too-often ignored users.

Due to its ubiquity, we’ve become quite good at building mouse-friendly user interfaces. Hover states, dropdown menus, and click handlers are second nature to any web worker. This is a good thing, but it leaves us with some catching up to do for other input types. I propose that we start treating the mouse as an enhancement to web experiences rather than assuming it will be available by default. Realistically, the mouse is an optional peripheral used in desktop computers. Among that group, it’s used by people who don’t have disabilities or injuries affecting the hands and wrists. For everyone else, it’s not available. We should support these use cases first before we bother with the well-understood and well-covered mouse.

Touch

If current trends continue, the majority of web browsing will soon occur on touch devices like phones and tablets. Outside of certain tablet/laptop hybrids, these devices don’t allow for mouse usage.

This territory has been well traveled thanks to the explosion in popularity of the mobile web. Touch screens have a lot in common with mice (particularly the ability to click or tap anywhere on the screen at will), which makes supporting touch inputs relatively easy, at least for basic use cases. The most common considerations are not hiding content behind hover states and using device-appropriate event listeners. If you’re building your website mobile-first, you’re well on your way to treating the mouse as an enhancement.

Keyboard

Many desktop users have a mouse but are unable to effectively use it due to motor control disabilities, repetitive strain injuries, and other conditions of the hands and wrists. Other users are visually impaired and use a screen reader to browse the web. These users navigate the web with the keyboard, perhaps the most often overlooked mode of web interaction.

At the most basic level, all content in a site should be navigable with a keyboard. Making a website keyboard navigable is fairly straightforward. Use real links, buttons, and form elements rather than non-interactive HTML elements for UI controls, so that you can reach them by pressing the tab key. Use tabindex when appropriate to adjust tab behavior beyond browser defaults. Avoid focus traps that a keyboard user can enter but not exit so that they don’t get stuck while trying to move through the page. It’s also a good idea to make your tab order as logical as possible, so that users have a good idea of where their next keypress will take them. Visually moving elements so that they don’t follow their logical DOM order can be confusing when you try to tab through them.

Nearly as important as making content navigable is making that navigation perceivable. If a user can reach content with a keyboard but can’t see which element they have selected, the navigation is useless. The key to perceivable keyboard navigation is providing clear focus states. Focus states are often ignored, tacked on to the end of a project, or worse, removed entirely. Instead of haphazardly throwing focus styles together, we should treat these states as an important part of the interface, and design with them in mind from the beginning. A focus state is the user’s only indication that they have a given element selected, so they must be clear. Hover states, in comparison, can be more subtle, and are arguably less important, because the user can see where the mouse is. If we make focus states a priority early and build interfaces with them in mind, we can easily handle hover styling later.

No-Mouse-First?

I hate to suggest another “-first” development ideology, so instead I’ll say that we should work “mouse-last.” By focusing on touch and keyboard support early, we can ensure that these experiences aren’t overlooked and receive the attention that they deserve.

The Problem with Progressive Enhancement

2016-01-05T00:00:00+00:00

I’ve built my fair share of websites without progressive enhancement. I’m not proud, nor am I ashamed. It’s just a fact.

Typically, this has meant that the site wasn’t functional without JavaScript, either because certain critical behavior depends on JS or the entire thing is a client-rendered SPA. On rare occasion, I’ve built sites this way because JS was critical for the application’s core functionality. This isn’t usually the case, because the vast majority of websites are places where you read and write text, and text works pretty well without rich client-side interactions. Most of the time, websites are built without progressive enhancement because the project has a deadline and a limited budget, and there aren’t enough users without JS to justify the cost.

I think it’s fair to not optimize for (or even support) users who disable JavaScript. JS is one of the three pillars of the front-end. Browsers have made it increasingly difficult to turn it off. By any measure, the number of users willfully disabling JS is low. That said, I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.

Performance

Progressively enhanced websites are often able to perform better on initial page load than their JS-required counterparts, because content is available as it loads, which in a well optimized site occurs before the JS loads. This is most obvious in comparison to client-rendered apps, which must download an often large bundle of JavaScript before the user can see any content. Traditional server-rendered sites can present their content immediately while JavaScript is still loading. JS application frameworks like React and Ember have made great strides in solving this problem over the past couple of years by allowing for relatively easy universal rendering in which the initial render occurs on the server followed by fast client-side renders when the user interacts with the app. This is an extremely powerful pattern.

Even among server-rendered or universal apps, waiting for JS to load before the page is interactive can have a negative impact on users, especially those with slow connection speeds. Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.

Resilience

One of the biggest benefits of progressive enhancement is the ability to make an application more bulletproof. It’s uncommon for JS to be unavailable on a page, but it’s much more common for things to go wrong and for script execution to stop. CDNs crash, files 404, ads explode, and every once in a while some JavaScript that you yourself wrote will hit an edge case and throw, and the app will break for some unlucky user.

Progressive enhancement is a backup plan for when things go wrong. If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper. This is no different than any other process or tool we use to make our applications more reliable. For the same reason that we lint and test code, and perform QA with many devices and in adverse conditions, progressive enhancement can help make web apps robust.

Business, Business, Business

I don’t think that progressive enhancement for the sake of it is a worthy goal. I often hear the process described in sentimental terms— fundamental to the web as an open, universal tool for the global distribution of knowledge. I love that idea, but I think that if you want to sell progressive enhancement in your organization you’ll be better off with cold hard facts.

Progressive enhancement is a tool that will help you build faster, tougher sites. It is an investment in the strength and quality of your application. It will make your users happy because the app will still work, if imperfectly. It might just save you when disaster strikes, and if you’re interested in building the best websites possible, you should give it some thought.

2015 in Review

2015-12-30T00:00:00+00:00

I’m not big on year in review posts, but some good things happened this year that are worth writing down, lest I forget them.

What kinds of things? In 2015, I:

Open sourced Radium, a toolset for managing inline styles in React.
Curated CascadiaCSS. This was the first year for CascadiaCSS, and my second time helping out with CascadiaJS (I did web stuff for the first year of the conference).
Spoke at CSS Dev Conf 2015 about inline styles and scalable CSS. My slides are available on Speaker Deck, and I wrote a blog post about the experience. I’m planning to record a screencast version of this talk soon as well!
Redesigned this blog (as one does).
Published 10 blog posts (if you count this one, anyway).
Started working reading and writing back into my routine.

Not bad. My goal for 2016 is to write a similar list that is twice as long. We’ll see!

In Defense of CSS Resets

2015-12-22T00:00:00+00:00

I love normalize.css. The moment that I learned about it, I tossed traditional CSS resets aside with glee, convinced that it was vastly superior. Now, I’m not so sure.

History Lesson

In the beginning, browsers had a lot of opinions on how elements should be styled by default, and they rarely shared them with each other. Font sizes, margins, line heights, and more had different baselines depending on the browser. This made it relatively common to build a site in one browser and find that it looked quite different in another because you inadvertently depended on some default styles that only the first browser provided.

In response to this challenge, crafty web developers created CSS resets. These stylesheets struck deep at the tyranny of cross-browser compatibility by erasing browser defaults wherever they could. The reset was a blank slate for styling, with default margins, padding, font sizes, and more removed. With default styles out of the way, you could build your site as you saw fit. The most popular of these by far was and remains Eric Meyer’s CSS Reset, a classic of the genre.

After years of productive reset usage, a challenger entered the fray in the form of normalize.css. Normalize took a different tack than traditional resets: what if, instead of destroying default styles, you normalized them across browsers so that you started with a consistent slate rather than a blank one? This idea was very appealing, and caught on quickly. How wasteful, to throw away all of our default styles with a reset? Especially because you were probably going to add a lot of them back anyway.

Targeted resets

As I mentioned before, I’ve used normalize happily for years. That said, I’ve often found cases where I wanted additional style resets on top of it:

Buttons

I can’t remember a single time that I’ve actually wanted to use default button styles in a real project. Any time I style one, I have to remember to override both the border and background rules, and probably padding, all so that the charming browser defaults don’t shine through.

Beyond that, in most projects I find myself creating a class that styles buttons so that they look like links. This is helpful for building accessible interfaces, as UI elements often look like links but behave like buttons (that is, they don’t have an href, but are used for form submissions or JavaScript interactions). The alternative is a scourge of <a href="#"> in your code base. I discussed this issue previously in Anchors, Buttons, and Accessibility.

After repeating this process for the nth time, I realized that it makes a lot of sense to reset default button styles entirely from the start:

button {
  background: transparent;
  border: 0;
  padding: 0;
}

With this targeted reset in place, there’s no need to account for borders and backgrounds every time you style a button, and there’s no need to use an additional class to make buttons look like anchors.

Headings

As I wrote in Abandoning Global Heading Styles, headings are an excellent candidate for a targeted reset. By resetting all of your heading elements to match your normal text and using classes to visually distinguish them, you can easily build a correct document outline without default styles getting in the way.

h1, h2, h3, h4, h5, h6 {
  font-size: 1em;
  font-weight: 400;
}

List Styles

List elements like ul and ol are common choices for marking up UI patterns like menus. Unless the site you’re working on has a large amount of a prose, there’s a good chance that you’ll have more lists that shouldn’t include default list indicators like bullets, or padding on the left, than the opposite.

Removing list styles globally and applying them when necessary can save you more code than you might expect. Try searching your code base to see how many list-style: none declarations are in there.

ol, ul {
  list-style: none;
  margin: 0;
  padding: 0;
}

Opt-in Typography

A final targeted reset that I find myself using is typographic spacing. In many cases, when building an interface you won’t want margins on elements like p or ul to apply. I used to solve this problem by creating utility classes to remove margins and applying them liberally. I’ve found that by working in the opposite direction and only enabling margins when I want them, you can save a lot of code and effort.

This pairs extremely well with a technique like single direction margins.

@custom-selector :--type h1,h2,h3,h4,h5,h6,ul,ol,p,figure,pre,table,fieldset,hr;

:--type {
  margin: 0;
}

.Prose :--type {
  margin-bottom: 1.5rem;
}

The above example uses the Custom Selectors CSS Extension specification syntax, which you can use today with the PostCSS Custom Selectors plugin. You can get a similar effect in most preprocessors, or you can laboriously type out .Prose h1, .Prose h2, etc….

In Practice

If you’re itching to return to simpler times and use an old school reset again, make sure to take a look through normalize first. There are a lot of excellent fixes in there that you’re not going to want to lose, and it’s all well commented, so you’ll learn a thing or two while you’re at it.

If you want to stick with normalize but think that certain targeted resets like these ones might be helpful, I highly recommend SUIT CSS’s base styles, a slim stylesheet designed for use in addition to normalize that includes button, typographic margin, and list style resets, among some other niceties.

How I Learned To Love My Commute

2015-12-15T00:00:00+00:00

I’m very lucky to live close to my work. Most days, to get to the Formidable office, I hop on the bus for a ten minute ride. To pass the time, I gaze out of windows and observe the marks of the passage of time on the city, sometimes pausing briefly for wistful remembrances of my youth. That and Twitter. I wear out the pull-to-refresh gesture like you wouldn’t believe because the bus is boring as hell.

A few months ago I started working on-site at a client’s office a few times a week, which took my commute from ten minutes to an hour. I wasn’t keen on throwing away two hours of my day, and even Twitter has its limits, so I started working on better ways to pass the time. I realized quickly that my commute wasn’t something that I had to get through, but two solid blocks of uninterrupted, distraction-free time, which is actually pretty valuable.

Disconnect

The first key to harnessing this time that’s been given to me was learning to ignore the powerful supercomputer hooked up to all of the world’s knowledge and funny animal pictures that I keep in my pocket. My secret weapon in this battle against distraction? I switched my phone’s data plan to the smallest one available. The cost of a data overage is an excellent deterrent to spending all of your time reading “think pieces” or whatever.

I kind of cheated on this one, because I actually changed my data plan a few months before any of this. It was for essentially the same reason though: I wanted to be more present, and I lack the self-control necessary to not soak in a big vat of internet whenever a free moment presents itself.

With smartphone procrastination made difficult for myself, I was free to pursue other interests— whatever those are.

Reading

When I was younger, I read voraciously. I feasted on a book or two per week, sometimes more. I was a shy, weird kid who lived on a chunk of land far from the nearest town. Books sustained me, showed me new possibilities. I was on some real Reading Rainbow shit. In college, I pillaged the library stacks for new ideas, new stories. I hurt my back carrying piles of books. After graduating, I started to work full time and got tired and irritable and hardly read at all.

As a result, I had accrued a sizable backlog of reading material taking up space in my apartment. I brushed off the dust and packed a couple of books in my bag, and it was good. I quadrupled the number of books I had read over the preceding year in a month. I started to think about what else I could do with the time.

Writing

The first thing that I did when I decided to work on the web was build a blog. I saw it as the sign of a true web worker. I would share the things that I learned, new ideas, idle thoughts. I wrote four posts in four years, and that’s a charitable way to characterize it. Whoops!

I used to love writing almost as much as reading. The desire to write never went anywhere, but the discipline necessary got lost somewhere along the way. With my newfound source of distraction-free bus time, it felt like a good chance to give writing another shot. I picked up a good notebook and a good pen, along with a laundry list of blog post ideas I’ve been handing on to, and put pen to paper, and it was good.

For now, I focus on writing and publishing, and try not to worry about making things perfect. In a good week, I write one or two short posts. Every Tuesday, I publish one. When I write in the morning, I get to stretch my mind and wake up slowly. I find myself more ready for the day ahead. When I write in the evening, I reflect and relax. I don’t let whatever dumb programming problem I was working on during the day infiltrate my mind (unless I’m writing about it, of course).

Writing instead of typing forces me to keep a slow, thoughtful pace. The act of writing becomes meditative. I understand my ideas better after I write them down. I understand myself better, too. If I don’t want to write, or if I’ve finished for the day, I reach for a book. It’s good.

Embracing Constraint

2015-12-08T00:00:00+00:00

I’ve been thinking about the graphics of massively multiplayer online role-playing games from 2004. Bear with me.

For the uninitiated, MMORPGs are a niche sub-genre of video games in which thousands of people play on the same servers simultaneously. Players explore large open worlds, taking on jobs, exploring dungeons, and battling massive and powerful bosses. As they play, they encounter other players on their own journeys, and can choose to cooperate or compete with the other inhabitants of their shared digital world. It’s not uncommon for players to develop analog relationships from the resulting connections: friendships, rivalries, romances.

In 2004, the insular MMO scene was rocked by the arrival of World of Warcraft. The game was a continuation of a popular series of computer games, and was the first foray into massively multiplayer games for the series, the studio that designed it, and a very large and dedicated base of pre-existing fans. Warcraft became an enormous success to a degree that no other game in the genre has before or since. (The genre has fallen out of favor over the last few years, so it’s not impossible that it will remain the most prominent piece of the canon for all time.) The reasons for this had a lot to do with the way that the game eschewed genre conventions, making it more approachable and accessible than traditional MMOs.

Although there was considerable hype during the game’s development process and release, Warcraft’s visual graphics were a sticking point within the gaming community. While other games at the time demonstrated cutting-edge, realistic visuals, Warcraft went in a different direction with a vibrant art style and relatively simple graphics— realism was out the window.

Reactions were mixed, with many players decrying the unimpressive graphics. Common refrains were that Warcraft looked like a cartoon, and that the visuals were embarrassing in comparison to other games released at the time. Then, something interesting happened. The game was released, and it became clear quickly that the lack of advanced graphics really wasn’t a hindrance. Warcraft’s unique visual style and strong creative direction more than made up for any shortcomings in raw power. The result was visually engaging, highly polished, and quite beautiful in its own way.

The truth of the matter was that the game designers were fully capable of creating cutting-edge visuals, but wisely chose not to. This was their design, and it had two key benefits.

The first was that the game didn’t ask much of your computer. It looked good and ran smoothly on low-end hardware, which opened it up to as large of a user-base as possible, including fans of the older games in the series. This practical application of art direction over graphical prowess has roots in the beginning of the franchise in 1994. The original Warcraft: Orcs & Humans made a similar decision to embrace a vibrant, high contrast creative direction over a more realistic and drab one, with the goal of making the game look distinctive on low-end monitors. This practice was so integral to the development process that team members worked with their window blinds open so that the glare of sunlight washed out their screens. If the game was still playable and looked good in those conditions, it should work everywhere.

The second was that it gave the game’s visuals longevity. Video game graphics have been an arms race since the introduction of the medium, with impressive advancements being made all the time. This has the unfortunate side effect of making it relatively easy to estimate when a game was released within a couple of years of accuracy. By refusing to take part in this process, Warcraft was able to work with their initial design for years with minimal updates.

I don’t find video game graphics particularly interesting, to be honest. What I do find interesting is the concept of embracing constraints rather than struggling against them. The designers of World of Warcraft knew that the game they were making would appeal to players using computers with a wide range of technical power, and they knew that it should last as long as possible (a long lifespan is the sign of a successful MMO), so they built a graphical system that would meet those requirements.

In recent years, it has become much more common to see similar graphical decisions made throughout the gaming world. Deliberately retro pixel art has exploded in popularity, making games with lower graphical budgets able to compete and look good doing so. Minecraft, in which everything is made up of brightly colored voxels, is one of the most popular games of all time.

On the web, it’s very common to lash out at the constraints of the medium, or feebly attempt to fix them. Instead of following the grain of the web, we implement custom form controls and build rigid layouts. We build digital monuments to excess that look beautiful on the latest desktop browsers and grind the rest of the web-connected world to a halt. I wonder what would happen if we worked harder to embrace the constraints of the web. Could we design systems built to thrive in low bandwidth, and the glare of the sun as we sit on a park bench? What if someone rebuilt your favorite online store and made it minimal, responsive— of the web. What if that worked, because what people really want are fast, reliable experiences? Wouldn’t that be something?

How I Made My First Conference Talk

2015-12-01T00:00:00+00:00

Earlier this year I gave a talk called React Inline Styles and the Future of CSS at CSS Dev Conf. It was an amazing and terrifying experience, and the fulfillment of a goal I had been working toward for the past two years.

The idea

CSS Dev Conf opened their CFP in March, with the conference scheduled for October. I had submitted a proposal to speak the year before which was rejected, so I was eager to try again. I had been thinking about the topic for a while by the time the CFP opened, so my proposal came pretty easily.

As you would expect, many speakers submit proposals on subjects that they’re experts in. A lot of people submit talks on things they don’t know much about but would like to learn about, too, which can also be a great idea. Teaching something is an effective way to learn about it, and your excitement about the cool new thing you’re doing will carry over into your talk. My topic was half based on personal experience and half things I wanted to learn about, which felt like a nice balance. I had also reviewed proposals earlier in the year when I organized CascadiaCSS, so I had picked up a few ideas.

A few months later in June, I received an email accepting my proposal and danced around a bit. It was time to get to work.

Writing

A couple of weeks later, after stewing on the idea more and using up some of my last available free time for a while, I started the writing process.

My first step was to come up with a rough outline. I wrote a bulleted list of the main topics I wanted to cover, then started to fill in details, examples, and other ideas in each section. This process helped me find a structure for my talk. I reorganized the outline a few times as I started to think of how the ideas in it related to each other.

When the outline was done and I was happy with the general order of things, I grabbed a notebook and started writing a storyboard for the talk. I divided the pages into two columns. In the lefthand column, I drew thumbnails of each slide, and in the other I wrote detailed notes relating to it. This turned out to be one of the most helpful exercises in the entire process.

Making a storyboard got me thinking about how the slides would work as visual aids early, without letting me waste time trying to finish and polish them while I needed to be figuring out the general ideas. This also helped me avoid filling my slides with dense text and bullet points that I would end up reading, which I desperately wanted to avoid. I tried to make my slides as visual as possible so that they would help clarify what I was talking about without distracting.

The day after I finished the storyboard, I wrote the content out in prose as if it was an article for my blog. I find that writing about my ideas is one of the best ways for me to understand and critically analyze them, and I was glad that I did. By the time I was finished, it was the beginning of September, and the conference was just under two months away.

With my storyboard in place, making my actual slides came pretty easily. I started by getting the content and sections that I was sure about done, and left the rest in rough but functional shape. I wanted to make sure that I didn’t wast time on things that had a good chance of changing, or that I might remove. I avoided polish and minor design tweaks— it’s easy to spend hours adjusting type and color that could be better spent elsewhere.

Practice Makes… Something

Once I had a slide deck in workable shape, I started to practice as much as I could. This meant speaking repeatedly in my living room, which I’m sure my girlfriend appreciated. After a while, I had the bright idea to record myself. This let me see what bad speaking habits I was dragging around. (I’m pretty good about “um” and “ah”, but I stumble over my words sometimes, and tend to get ahead of myself.) Watching or listening to yourself is awkward and cringe-worthy, but it was helpful.

The week before the conference, I gave my talk at work as a brownbag lunch. My coworkers were an awesome test audience and gave me valuable feedback. I incorporated as much of it as I could and spend the last week finalizing and polishing my slides.

…And?

The next Sunday, I flew into LAX, made it to the conference, and had a ton of fun at the opening reception and speaker’s dinner trying not to think about the fact that I had to speak in front of a bunch of strangers the next morning.

The day of, I looked over my slides one last time, took a deep breath, and spoke. I’m relieved to say that I survived the ordeal, and wasn’t weirdly sweaty or anything. In fact, it went pretty well! My biggest problem was nerves, but they eased up a little bit as I got into it. I think if anything I probably sounded a little too practiced and not energetic enough. Oddly enough, I think that sounding over-rehearsed was something that I could have done better with by practicing more. If I was more comfortable and not so nervous, I think I would have done a better job with it. Next time!

In the end, I spent about 120 hours preparing for the talk, and practiced it about 15 times. For the most part I was happy with my process. Next time, I’m going to try practicing in front of more people earlier instead of only practicing it at home. I’m also planning to record myself a few times to see how the next one progresses over time.

I’ve got some new talk ideas kicking around now, and I think that next time will be even better. See you at a conference?

Abandoning Global Heading Styles

2015-11-24T00:00:00+00:00

One of the first things I do in new projects is set up global heading styles. These CSS rules define what the site’s h1–h6 elements look like when they’re used on their own— defaults to be overridden as necessary. Typically, this will involve setting font sizes, weights, margins, and maybe a font-family or two. Something like this:

h1 {
  font-size: 2rem;
  font-weight: 700;
}

h2 {
  font-size: 1.5rem;
  font-weight: 400;
  text-transform: uppercase;
}

/* etc */

This seems like a good idea, but it ignores a fundamental aspect of heading elements. They aren’t meant to fit your design system, but to define the document outline of your webpages. Any alignment between the two is a happy accident.

Document Outlines are a Thing

The HTML document outline as it’s currently implemented is a mapping of the structure of a webpage based on heading elements. It’s used by assistive technology like screen readers, and is read by search engine crawlers. The document outline for this page looks like this:

h1: Abandoning Global Heading Styles
  h2: Document Outlines are a Thing
  h2: Classes to the Rescue
  h2: Heading Classes Only

A well formed document outline starts with an h1 with the title of the page, followed by any other heading levels. The key to building a document outline is that it should never skip heading levels: an h3 should never follow an h1 unless there’s an h2 between them. Your outline can go as deep as h6, but it needs to have the previous five heading levels first. The Firefox Web Developer Toolbar extension includes a great tool to see the outline of pages that you’re working on.

This is where setting global heading styles alone can fall short. On a blog or small publication, the outline of a given page might match up with your intended visual styles, but on complex sites that’s often not the case.

Classes to the Rescue

A good and common approach to deal with this issue is to add class selectors to your global heading rules, like this:

h1,
.h1 {
  font-size: 2rem;
  font-weight: 700;
}

h2,
.h2 {
  font-size: 1.5rem;
  font-weight: 400;
  text-transform: uppercase;
}

/* etc */

With this approach, you can set heading elements to be styled as if they were different levels with a class like .h2 any time your document outline and intended styling don’t line up. You can see this pattern in use in CSS frameworks like Bootstrap. This technique has served me pretty well in the past… mostly.

Heading Classes Only

The trouble that I’ve found with the global heading styles with classes approach is that it’s still easier to have an incorrect document outline than to do the right thing. You have the ability to set appropriate heading levels and style them the way that you want, but it’s not particularly obvious when you need to. It can be unclear how the classes are meant to be used (“Do I have to use the .h1 class on h1 elements? Are the classes meant for use on non-heading elements?”) and it’s easy to use the global defaults without noticing that your outline is wrong.

One answer for this is to add tooling like automated accessibility audits that will report when your outline is invalid. Another, which I’ve been a fan of lately, is to reset global heading styles and only use classes to style headings, like this:

h1, h2, h3, h4, h5, h6 {
  font-size: 1em;
  font-weight: 400;
}

.h1 {
  font-size: 2rem;
  font-weight: 700;
}

.h2 {
  font-size: 1.5rem;
  font-weight: 400;
  text-transform: uppercase;
}

/* etc */

This technique encourages you to be mindful and think about the document outline by making it harder to default to the wrong heading level. Small things like this can have a big impact, and help encourage everyone on a team to think about accessibility as they work.

You Better Use Inline Styles, If You Know What’s Good For You

2015-11-17T00:00:00+00:00

I write styles for a lot of different projects. Sometimes I use inline styling with Radium. Sometimes I use CSS Modules. For most client projects I recommend Sass. Every once in a while I use plain old CSS.

There are a lot of good reasons to use any of these tools. There is no silver bullet, no “right choice.” Some projects will benefit from a specific toolset. Some teams will be more comfortable or more productive with one approach or another. When I see articles saying “please don’t use inline styles,” I think to myself: *fart noises*. When I see articles saying “CSS is dead, use inline styles,” I think to myself: *fart noises*.

There’s a secret about inline styles, and it goes like this: the biggest benefits are doable with plain old CSS. I’m talking specifically about specificity equalization and scoping, which I consider to be the best features. With diligence, you can ensure that most of your styles are applied with equal specificity by using class selectors whenever possible. You can avoid naming collisions by carefully managing class names, maybe with a pattern like BEM.

Inline styling introduces a constraint that enforces this style of authorship: no more selectors. That’s the key difference, really. Using CSS for the same result requires diligence, and inline styling changes the toolset so that it’s the only option. In my experience, solutions requiring diligence are more difficult at scale and break down more quickly than those that are enforced through tooling constraints. CSS Modules provides a nice middle ground by enforcing unique class names through build-level tooling. The actual result is effectively the same no matter which path you take.

The other major benefit of inline styling is computed styles. This is a neat trick, and one that most applications probably don’t need. They’ve gotten along this far without it, after all. Nontrivial computed styles are impossible with CSS, and I don’t expect that to change. That’s not to say that computed styles aren’t useful. The team at Formidable is doing great work with them in Victory, a new React data visualization library. Data visualization is an excellent use case for the technique. I expect that novel and interesting approaches to user interface design based on computed styling will emerge over time. The Grid is a promising early example.

Just Tell Me What To Do

The styling mechanism you should choose will probably depend on your project and your team. If you’re writing a React application, don’t want to deal with specificity or scoping, and don’t need server-rendered media queries¹, or if you want to do a lot of style computation, inline styles are a good option. Maybe try a library like Radium or react-style to help with some of the pain points. If you want some similar benefits but don’t want to abandon CSS, try CSS Modules. The tooling there is only viable for Webpack and Browserify projects so far (I think), but the technique revolves around a specification rather than a particular tool, so support for other languages and ecosystems is coming. If you don’t mind the global nature of CSS (or like it, even!), use your favorite preprocessor. If you want scoped styles on a standards track, check out web component styling through the Shadow DOM. There are options, is that I’m saying.

My advice? Pick the tools that will make you happy and productive. Don’t be precious about your decisions— rethink them when things change. Mentally replace all hype and FUD with fart noises. Don’t let anybody tell you what to do.

I’ve been saying this for a long time, but support for server-rendered media queries is coming to Radium. The effort to build them is underway by the whip-smart and dedicated current maintainer of the library, Ian Obermiller. ↩

Cross-Browser Tabindex Woes

2015-11-10T00:00:00+00:00

The HTML tabindex attribute is a useful tool for accessibility when used properly. Unfortunately for a11y-minded developers, most browsers don’t handle the attribute consistently. This can be challenging to deal with.

Tabindex basics

tabindex is an HTML attribute that allows you manipulate the tab order of elements. By default, pressing the Tab key on a web page will set browser focus on interactive page elements in the order that they appear in the document. Once focused, you can use the keyboard to interact with elements—activating a link, submitting a button, or entering information into an input.

Making elements focusable

Applying tabindex="0" to an element makes it keyboard focusable, whether it is an interactive HTML element or not. This can be useful for building custom form controls or application components. but can also be a potential accessibility hazard if these elements don’t have correct WAI-ARIA attributes to make their usage clear to people with screen readers.

Sequential tabindex

tabindex values greater than 0 set elements to particular positions in the page’s tab order. tabindex="1" will make an element the first item to gain focus when tabbing through the page, followed by any higher numbered tab indices, followed by any other keyboard focusable elements (including those with tabindex="0"). If multiple elements have the same tabindex, those items will be ordered relative to each other. Any items with tabindex="1" will be first in the order that they appear in the document, followed by items with tabindex="2", and so on.

This behavior is extremely powerful, but in practice isn’t as useful as you might think. It can be difficult to manage sequential tab indices on a large or dynamic page and ensure that everything stays in the order you want, and setting a custom tab order can make it difficult for keyboard users to move around your page, as their browser focus may not go where they expect.

Removing elements from tab order

The last type of valid value for tabindex is negative values. Adding tabindex="-1" to an element removes it from the document’s tab order completely, preventing keyboard users from focusing on it. This is pretty dangerous and is usually not a good idea unless you have a good reason. An element shouldn’t have tab behavior disabled if users can interact with it.

Good thing all browsers handle tabindex the same way

In building keyboard accessible interfaces, I’ve found that setting tabindex="0" on an element doesn’t always get the job done. After a few frustrating experiences trying to figure out why tabindex doesn’t always work the way you might expect, I put together a test suite to figure out what was going on.

My test document is a table with examples of the primary types of elements that tabindex is valid on, as well as a few that it is not valid on (according to the specification), with various values set. The behavior for various elements varied considerably between browsers and operating systems.

Test details

According to the HTML specification, tabindex is a valid attribute on the following elements:

a
area
button
input
object
select
textarea

Because I love and respect myself, I did not test area or object. I did, however, add examples of each of the other elements, including three types of inputs, as well as div and span. You can try the test suite out here.

So what happens?

Some browsers respect tabindex all of the time. Others respect it for certain elements, or with certain modifier keys held down while tabbing, or with certain system preferences enabled on your computer, or for certain elements under certain conditions. Cool, right? To be fair, this situation has actually improved quite a bit since I looked at this last. Safari (as of OS X El Capitan) has shown the most improvement, going from being incomprehensible to making sense as long as you know the rules.

The good news first. Chrome, Opera, and Internet Explorer all accept their new tab orders with open arms. All interactive elements and elements with a non-negative tabindex can be accessed by tabbing through the document. With the exception of radio buttons. We’ll come back to that later.

Firefox works similarly, with the exception that on OS X a elements aren’t tab-accessible by default, with or without tabindex. You can access a elements with the keyboard in Firefox two ways. You can hold down the option key while pressing tab, or you can change your system preferences. Firefox respects an option called “Full Keyboard Access” in your keyboard preferences, which controls which types of controls can be accessed with tab on your computer. If you toggle that option to “All Controls”, Firefox will focus on links like nobody’s business.

Safari is where things get weird. In Safari, text input elements, textarea, select, div, and span respect tabindex by default, but buttons and radio and option inputs aren’t tab-accessible. If the user sets “Full Keyboard Access” to “All Controls” in their preferences or uses option + tab, all elements will work as expected, same as Firefox.

The radio thing

Radio input support for tabindex is… quirky. As a general rule, once a radio input in a group is selected, only the selected input is tab-accessible. From there, you can use the arrow keys to activate different inputs in the group. If no radio inputs in a group are selected, behavior varies between browsers.

In Chrome and Opera, the first radio input you attempt to tab to in a group is tabbable by default, meaning the first input in the group if you’re tabbing forward, and the last one in the group if you’re tabbing backward. All inputs with sequential tabindex values are tab-accessible too, but setting tabindex="0" won’t do anything at all.

Firefox behaves similarly, except that tabindex="0" works as expected.

Safari behaves the same way as Chrome and Opera, except that you need to use option + tab or set your preferences to access all controls by default to reach radio inputs.

Internet Explorer handles radio inputs in the same way as Chrome and Opera, except for some strange behavior with negative tabindex values in IE8 and IE9. In those browsers, if a radio button is selected and has a negative tabindex, it will still be tabbable. No other browsers behave this way.

Take It Away

The browser differences in default tabbing behavior, like depending on particular system preferences or keyboard modifiers, are annoying for developers unfamiliar with them, but shouldn’t be too big of a deal for your users in general. Hopefully, they’re familiar with their browser of choice by virtue of using it regularly, so they know how to reach various UI controls with their keyboards.

Differences in tabindex support are a little more difficult to deal with, particularly when building custom UI controls. As a general rule, it’s probably a good idea to try to match the tabbing behavior of your component to the type of native element that it most closely resembles. For example, if you’re building a custom select element replacement, you might be best served by using a div with tabindex="0", which will behave the same way as a normal select element in the tab order.

If you need to work with sequential tabindex values, first— try not to. If you absolutely have to, be aware that particular types of elements like a, button, and non-text input may not fit in the tab order the way that you expect them to, depending on the browser.

When in doubt, non-interactive elements like div and span have more consistent support for tabindex than interactive ones like a and button, despite the fact that the attribute is technically not valid when used with them according to the specification. If an element absolutely needs to be in the document’s tab order cross-browser without requiring specific system preferences or keyboard modifiers, div might be your best choice. Just be sure to add appropriate ARIA attributes and keyboard event handlers so that users can tell what the element is and interact with it when they get to it.

CSS Font Sizing Blues

2015-11-03T00:00:00+00:00

I still don’t know how I feel about rems, ems, and pixels. The prevailing wisdom for some time has been that you should never use pixels to size fonts in CSS. Some of the reasons for this practice are more clear to me than others.

It used to be a best practice to always use em values because browser font resizing didn’t work with pixel values, and visually impaired users might need to resize text to use your websites. This made good sense to me. Over time, browser font sizing options crept deeper and deeper into power user territory, and browser zooming became the preferred way for users with visual impairments to enlarge content on the web. With this change, font sizing with pixels became a little more widely accepted.

There are some nice benefits to pixel font sizing. Using absolute units means that your styles will be consistent everywhere, with no need to worry about managing (or avoiding) cascading font sizing through ems. It’s also, frankly, just plain easier to work with. There’s no math involved, it’s always clear what size things should be, and designers and developers can speak the same language. I advocated for pixel-based font sizing on a lot of projects that I worked on, with great success. There were no issues that I could see, and it was one less thing for everyone on the team to worry about.

With the advent of responsive design, and later the first browser implementations of the rem unit, things began to change. For reasons that remain unclear to me, it became the prevailing wisdom that relative font sizing and responsive design were inexorably linked. I once saw a speaker at a conference talk about how sad it made them to see websites use pixels for font sizing, because such websites could “never be responsive.” I found this idea puzzling, because I had built a great number of responsive sites using pixels for font sizing, and everything seemed fine. I couldn’t figure out what I was missing.

Are Relative Units Responsive, or What?

There were a few reasons for the “responsive must be relative” belief that I often heard. The biggest one was sort of philosophical. The idea was that responsive design is all about fluidity, adapting to the current device or browsing conditions. Relative units, by virtue of being relative, were more fluid than absolute units, and thus were more responsive. I understood the appeal, but without seeing concrete benefits in a responsive design the concept didn’t move me much.

The next reason was sort of an extension of the first. Using relative units, we could change the global font size, or the size of various page portions, with media queries. This meant that you could make the page’s font sizing adapt to the device. Maybe on mobile your base size would be 14px instead of 16px. Responsive! Chris Coyier made an excellent demo of this technique at CSS Tricks. This made a lot of sense to me, but I had a problem: I rarely found cases where I actually wanted to resize all font sizes in a given section of a page, and I have literally never done it for a global font size. This is the definition of anecdotal evidence, but it was hard for me to convince myself that the added complexity of relative units was worth it for a behavior that I rarely used.

A third often cited reason was for use with em-based media queries. This practice had some nice benefits in that your media queries, font sizes, and zoom level were in sync, meaning that if you were to zoom in to the page, your media queries would activate as if the browser had resized. This was great for a couple of years, but then devices changed and it was no longer necessary. You could get the same behavior with good old fashioned pixels.

What About Rems?

Font sizing with rems felt like a good general solution, given that it removed the cascading size difficulties inherent with ems, but outside of the font resizing use case, I still couldn’t see many benefits over pixels. This felt especially weird because I always had to add a pixel value as a fallback anyway. What was the point? How were these things really different from pixels if I wasn’t going to change the base size? It felt like a level of indirection that I didn’t really understand. Part of me thought that rems were just pixels for people who didn’t want to admit they were using pixels.

I’ve come around recently, and now prefer to use rems with a fallback, preferably automated by converting rems to pixels or vice versa with a tool like PostCSS. The main reason I like rems, oddly enough, is the same reason that I originally used ems. It turns out that browser font resizing has come back in style. Mobile browsers, Chrome especially, are starting to expose easily accessible controls for resizing text as an accessibility consideration. I still don’t know if there are other good reasons to strictly adhere to relative units, but for now this pragmatic accessibility benefit is good enough for me.

So Should I Use Rems For Everything?

The most valuable insight that I’ve gained from this flux of best practices is that there are a lot of valid reasons to choose any given sizing unit. It’s a good idea to use relative units for most text so that users can resize it, so I try to use rems most of the time. If I have a case where element sizes should be relative to the current text size, then I reach for ems. That could be for sizing heading element text in an article, or for setting padding and border-radius on a button that should scale proportionally. If I really want something to always be a static size, pixels are the way to go. It would be comforting to have a rule like “use pixels for everything,” but the truth is that the right unit to use is going to depend on a whole lot of things, and you’re probably best served mixing and matching. This doesn’t just apply to font sizing, either. There are a lot of good reasons to use relative units for layouts, or for particular component styles, or for pretty much anything.

I don’t know if there’s much of a moral to this story, except that I think it’s important to reevaluate your ideas every once in a while, even the minor ones like which units to size your text with. It’s easy to find yourself engrained in a position without even knowing why. It’s even easier for slightly out of date ideas to continue to influence people— this field changes rapidly, and it’s easy to miss things. I’m going to start thinking more about why I do things the way that I do. Who knows, maybe there’s a better way?

Progress

2015-01-04T00:00:00+00:00

I decided to redesign my website right around New Year’s Day (as one does). A change was overdue— since building the last version, I moved halfway across the United States, stopped freelancing, and started working at Formidable Labs. I spent a couple of days working on a new version, got it to a place that started looking pretty good, then got caught up in other things and never finished (as one does).

I left a screenshot of the design on my desktop as a reminder to pick it up when I had time. A year passed.

In 2015, I decided to redesign my website, and started sketching out new ideas. After a day, I noticed the old screenshot, which had become a permanent desktop fixture. It looked OK to me. Good enough, anyway. I rewrote all of it and tweaked the design a bit, but you’re pretty much looking at the site that I took a screenshot of a year ago. Ship it, right?

Anchors, Buttons, and Accessibility

2014-05-08T00:00:00+00:00

Accessibility is a foundational feature of the web. It is a direct reflection of a key tenet of the platform: the free and universal sharing of knowledge, unfettered by language, location, or disability. This is why it’s disappointing that accessibility is so often (and so easily) overlooked.

To build an accessible website or application, it’s best to start with the foundations: semantic markup. Using the correct markup is an easy win as it does the vast majority of the accessibility work for you. As rich client-side JavaScript applications have grown in popularity, a particular markup misuse has become common: <a href="#">.

What’s wrong with `href="#"`?

If you’re not familiar with this pattern, take a look at the source of your favorite web app, and weep. There are some other similar examples like <a>, <a href="">, and <a onclick="return false;">.

HTML anchor elements in this form don’t do what anchors do: act as a link. (While anchors can act as placeholder links or target link destinations, these uses are much less common.) These links are actually working as user interface controls— clicking on them affects the UI in some way, rather than taking the user to a destination.

The thing is, we already have an HTML element specifically meant for controlling a user interface: <button>. The distinction isn’t just semantic. <button> and <a> respond to different keyboard events, and screen readers treat them differently.

By using an <a>, we tell screen readers that the standard behavior should apply. Pressing the enter key should navigate to the URL of the link. Visually disabled users shouldn’t have to deal with confusing interactions just because sighted users can’t tell the difference.

So I should use a `<button>`?

The non-meaningful href anti-pattern most likely comes up as often as it does because the UI element looks like a link, not a button. Fortunately, HTML elements are designed to describe semantics and behavior, not appearance. Making a button look like a link is pretty straightforward with a bit of CSS:

.link {
  margin: 0;
  padding: 0;
  border: 0;

  background: transparent;
  font-size: inherit;
}

There are some edge cases that these styles don’t cover, but for most basic usage that’s all that you need. You can then add other styles as you’d like to fit your design needs.

In this way, we use <button> as it was meant to be used and save <a> for things that navigate the user to a new page or page fragment. From there, you can use JavaScript to enhance the experience of clicking a link by displaying partial content, opening a panel or modal corresponding to the link, or whatever else you can imagine.

As an added benefit, users who prefer to open links in a new tab or window will be able to use your controls without accidentally opening a tab pointing to the current page plus #. Command- or shift-clicking on a <button> will control the UI of the page you’re on, rather than trying to open a non-existent URL.

Spotting a link that should be a button is easy. Just look for an anchor that doesn’t have a meaningful href.

An Aside on ARIA

For people who really want to stick with <a>, the ARIA role="button" attribute looks like an attractive option. If you add the attribute, the element is pretty much a button, right?

Unfortunately, using an ARIA role will get you part of the way there, but it isn’t a complete solution. While screen readers will interpret the link as a button, the element still responds to keyboard input as if it were a link. Pressing the enter key will fire a click event on the button, but pressing space as you would expect for a button will do nothing. Confusing! If you go this route, you’ll need to write custom JavaScript event handlers to listen for the space key and react appropriately.

If you use a <button>, it just works.

Push some buttons

An argument can be made that this is a UX design issue. If something is a button, it should look like a button instead of a link. Given the shifting definitions of what exactly a button looks like (for better or worse), it is not always going to be that simple.

The good news is that it’s not difficult to provide the correct user experience to all users. Using elements as they’re intended will give visually disabled users the context they need to understand your content, allow keyboard users to control the page in a consistent way, and prevent all users from making frustrating mistakes attempting to open false links.

The web is for everyone— let’s make it accessible.

Conditional Stylesheets Revisited

2012-01-20T00:00:00+00:00

If you’re writing CSS in 2012, there’s a good chance that you’ve tried pre-processing through Sass or LESS. Nicolas Gallagher recently described a Sass technique for mobile first development that allows you to easily deliver large screen styles to outdated browsers. After experimenting with the technique, I’ve found some ways to push it even further.

Pre-processing to the Rescue

Nicolas’ technique uses Sass imports to create a media query-laden style sheet for capable browsers and an IE-specific style sheet that delivers the same styles in a conditional comment.

It feels sort of odd to use an IE style sheet in a world of conditional classes, but if we’re going to we might as well make the most of it. Even if you aren’t much of a pre-processor, you’ve likely realized that modularizing your CSS in this way doesn’t have to stop with media queries. Since we’re already creating an IE-specific style sheet, we might as well import our IE-specific styles (written with the aforementioned conditional classes) into that file and leave them out of the other, like so:

@import "480.scss";
@import "768.scss";
@import "992.scss";
@import "ie.scss";

Easy as that, your main styles are free of .ie7 and .oldie. Feels good, right?

html5shiv Optimizations

One of the little-discussed benefits of media query polyfills like Respond.js is that they make excellent companions to html5shiv. If you’re using both, and a user visits your site on a legacy browser without JavaScript, they’ll only receive your base styles. If you’ve planned for this, that means they’ll see a functional but basic page, one that isn’t crippled by the lack of styled HTML5 elements and media queried layout.

The same thing is possible with the Sass importing method. It’s easiest if you’re using Modernizr, which has both html5shiv and a conditional loader called yepnope built in. Using yepnope, we can ensure that the legacy style sheet only loads when html5shiv is in use:

<!--[if (lt IE 9) & (!IEMobile)]>
  <script>yepnope('/css/legacy.css')</script>
<![endif]-->

You can toss a script like Selectivizr in at the same time, if you’re so inclined.

Be Not Afraid

Although I’ve been talking about Sass here, this style of modular CSS isn’t dependent on it. It works with LESS, with a build script a la HTML5 Boilerplate, and if you’re really masochistic you could do it by hand with copy and paste. (Don’t do that.)

If your design is fully responsive and is built on a fluid grid, IE users will still enjoy an experience that meets them halfway.

My only concern is that the technique is IE specific. In the last week, multiple people have visited this site using Firefox 3. That’s pretty strange, but it’s worth noting that there are still people using legacy browsers other than IE. As always, take a look at your statistics before you do anything rash.

Daybreak

2011-11-04T00:00:00+00:00

Note: This post is very old, and almost nothing in it is still true.

This is a rough draft.

This is my third rough draft, specifically. The others I threw away because they didn’t work. They tried for too little, or too much. After finishing the design for this one, I fought off the urge to throw it out as well and decided that the best course of action was to publish my rough draft, and go from there.

The web is a fantastic medium because it gives us these sorts of opportunities. This will remain a draft for quite some time, but it will be updated often, subject to tweaks and changes on every front. I’m lucky to have realized along the way that this can never be perfect, but it can be good, and even great. It can also be a place of experimentation and missteps, and you can expect plenty of both.

Along those lines, I plan to publish an article every month or two. They’ll vary in length and subject, but most will relate to design and the web in some way. A few may even be more technical: discussions of process or tricks. Either way, each will have a unique and fitting art direction, in the tradition of many talented folk. I’m doing so for two reasons: first, because I think that it would be interesting, and second, because I am selfish. A unique design for every article is a great venue for attempting new things. It also gives me a good excuse for only publishing every once in a while, instead of being embarrassed by it.

If you’re interested in technical mumbo-jumbo, the inner machinations of this site are all stored in a repository on GitHub. It’s powered by Jekyll, with fonts served by Typekit, and is built on Andy Clarke’s 320 and Up boilerplate.

Thank you so much for visiting. More soon.

Alex Lande

The Idea Grip

The Mouse is an Enhancement

Touch

Keyboard

No-Mouse-First?

The Problem with Progressive Enhancement

Performance

Resilience

Business, Business, Business

2015 in Review

In Defense of CSS Resets

History Lesson

Targeted resets

Buttons

Headings

List Styles

Opt-in Typography

In Practice

How I Learned To Love My Commute

Disconnect

Reading

Writing

Embracing Constraint

How I Made My First Conference Talk

The idea

Writing

Practice Makes… Something

…And?

Abandoning Global Heading Styles

Document Outlines are a Thing

Classes to the Rescue

Heading Classes Only

You Better Use Inline Styles, If You Know What’s Good For You

Just Tell Me What To Do

Cross-Browser Tabindex Woes

Tabindex basics

Making elements focusable

Sequential tabindex

Removing elements from tab order

Good thing all browsers handle tabindex the same way

Test details

So what happens?

The radio thing

Take It Away

CSS Font Sizing Blues

Are Relative Units Responsive, or What?

What About Rems?

So Should I Use Rems For Everything?

Progress

Anchors, Buttons, and Accessibility

What’s wrong with href="#"?

So I should use a <button>?

An Aside on ARIA

Push some buttons

Recommended Reading

Conditional Stylesheets Revisited

Pre-processing to the Rescue

html5shiv Optimizations

Be Not Afraid

Daybreak

What’s wrong with `href="#"`?

So I should use a `<button>`?