Repetitive strain injury - Wikipedia, the free encyclopedia

In the early months of 2013 I started to feel arm pain when I was typing on my laptop. I had felt it a few times briefly over the years. Normally I would take a few stretching breaks and continue on. Not this time.

My computer at the time was a Retina Macbook Pro. I used it on the couch at home and hooked up to an external monitor at work along with an external keyboard and mouse. I was a young designer in SF working at a startup so I thought it was a good idea to spend most of my time using computers and writing code.

The pain went from bad to worse. It didn’t show signs of slowing down. But I pushed on.

I told my boss casually in a 1 on 1 that my arms were hurting. I tried to mask the pain and tell him I would magically get better soon. “You should stop. I’ve had some battles with RSI, just rest. It can get really bad. It is not worth it.”

Even when your manager commands you to stop typing, it can be tough. If I am not typing, what value do I provide? How can I be helpful? If I am not adding value why would they keep me around?

I reduced my computer interaction but I kept trying to do work. The pain in my arms continued to get worse. What started out as some wrist pain while I worked, evolved into what felt like a sunburn down both of my arms. It hurt to pick up or use my phone. It hurt to touch a computer.

At this point I would describe myself as in a state of “very freaked out” My career was largely centered around designing through writing on a computer. My internal perceived value was tied to my ability to manipulate, produce, and delete code. Would I need to change careers? Could I use some dictation software to code? What am I going to do? What careers involve no computering? My head was filled with stressful questions.

I went to several doctors in search of an answer. None seemed very helpful. They all prescribed ‘rest’. Most gave me a list of computer mice and keyboards to try out. They gave me some medication for the pain.

When you are in constant pain, you will generally try anything in search of relief. So I tried the doctors’ suggestion. I didn’t touch a digital device for two months. My friends texted for me. Sometimes I would read digital news over other peoples shoulders. I figured an extended break was what I needed.

I iced my arms daily. I got massages. I smoked a lot of weed with high levels of CBD. I smoked a lot of weed with high levels of THC. After eight weeks of rest I tried typing again. The pain quickly flared up. Rest hadn’t help at all. I was frustrated. I wasn’t making any progress. But not knowing what else to do, I kept researching. I kept trying new things. Some worked. Most didn’t.

Pain Management & Getting Better

The following list of things started to turn things around. They did not fix me permanently.

Even when I wasn’t in pain, if I didn’t continually keep up these habits, I would have flareups that would be debilitating to my ability to work. I struggled seriously with RSI on and off for about 2.5 years. My biggest tips are: if you have pain, slow down. Reduce your workload. Take it seriously. There are a lot of ways you can contribute to better software that don’t require you to type with your hands.

Self Massage

https://www.youtube.com/watch?v=mEHMbhuxfAU

I generally did the massage in this video once a day. It was great for both immediate and long-term pain relief. Doing it consistently, even when I wasn’t feeling a lot of pain, helped me keep the pain at bay.

Pushups & Pullups

~100 quality pushups per day 3 days a week. You don’t need to do 100 straight. It’s okay if it’s 5 at a time. It’s okay to fall short when you are starting out. Work up to it at your own pace. But working on upper body strength has always helped me. My worst flareups have been when I was working too much and not working out enough. I’m not talking heading to the gym and lifting tons of weights for hours on end. Generally 5–10 minutes of pushups spread out over the day will suffice. Often times I’d do 5–10 at my desk once an hour to take a quick break, stretch my arms, and build strength back up. I don’t always have access to a pull up bar, but doing a few pull ups and arm hangs has also had a big affect on keeping my arms pain free while working.

Stretching

Arm stretches are great. I generally took a break every 90 minutes or so to stretch my arms.

I generally mix and matched a few of these: http://www.rsipain.com/stretching-exercises.php

Wrist Sleep Support

I got bad advice at one point to wear wrist supports at work while I typed. They didn’t seem to help and I’ve later heard from some doctors they are generally bad in this situation because they help weaken muscles when you need to strengthen them.

Sleeping with wrist supports definitely reduced the amount of pain I was feeling when I had a bad flareup. Not something you should have to do permanently.

Ice

I am a believer in the power of ice. A few days a week I would fill up a tub with ice and water and soak my arms for about 15 minutes. Helps with inflammation.

As little trackpad and mousing as possible

Often times when I notice problems I know exactly what the problem is. The trackpad. It’s often when I’m not writing a lot of code and doing more work in GUIs where I generally default to using a trackpad / mouse a bunch. I’ve had to adopt a number of habits to reduce my need for using a trackpad or a mouse. When I do have to do some extended mousing I find a small wacom tablet is my best option.

Refactoring my brain

Both of these articles were a huge help:

Programmer’s Guide to Healing RSI

How I cured my RSI pain

I did read parts of both The Mindbody Prescription, and The Divided Mind (I didn’t finish either.) I started to recover immediately after reading all of these posts though.

All of these things helped. But they also took time to do and when I didn’t do them I was constantly susceptible to having a flareup, even if I was only working 8 hours a day.

Since the Retina Macbook Pro came out, I’ve worked at a company that supplied one for me. Last July I decided to leave my job and strike out on my own. When I left my job I was actively managing RSI pain. It was pretty bad, I was paying out of pocket to get massages a few times a week for pain relief. I was doing pushups and stretching often. I was able to work, but it was painful.

I mailed my work computer back and I bought a Macbook.

My RSI pain went away almost immediately. All of a sudden I could work as much as I want without being in an ounce of pain. ** Update: A number of people have asked why I think this is. My biggest assumption is that it’s a different form factor. The keyboard is different, the body is thinner. As I am personally a small dataset I don’t want to claim causality, but I can say I consistently struggled with RSI the entire time I had a Retina Macbook Pro. Switching to any other computer might have had the same effect as switching to a Macbook.**

I can’t tell you how life changing this has been. It’s been about a year now. I’m still 100% pain free and have been the whole time. I feel back to my normal self. It’s fun to use a computer again for the first time since late 2012.

I hope some of the above tips help you get back to a pain-free life as soon as possible.

Mobile-first CSS has pretty much nothing to do with mobile-first design or development practices. They can be related, but don’t have to be.

Mobile-first CSS has to do with how you architect your code and media queries, as well as how browsers parse your CSS.

I often times step into codebases that have max-width media queries that target mobile devices. Something to the tune of:

.post-title {
  font-size: 48px;
}

@media only screen and (max-width: 320px) {
  .post-title {
    font-size: 24px;
  }
}

When I first started using media queries — this was a constant pattern in my code. I was used to writing desktop styles first and I loved the convenience of being able to ‘fix’ my desktop design for mobile.

Something didn’t feel right though. And I started to wonder. Is this pattern really an anti-pattern?

In Harry Roberts’ wonderfully written ‘code smells in css’ there is a great line that helped shape the way I think about authoring CSS:

Rulesets should only ever inherit and add to previous ones, never undo.- Harry Roberts

When applying this thinking to how we architect our media queries, we could say a device shouldn’t parse multiple definitions of the same ruleset if it doesn’t have to.

When a devices web browser parses your CSS, it doesn’t parse the code within media queries that don’t apply to it.

I.E devices that have a screen-width smaller than 64em will not parse anything inside this block:

@media only screen and (min-width: 64em) {
   /* Some CSS here */
}

In other words all CSS that isn’t inside a media query will get parsed by your mobile-devices no-matter what. So you should use that to target the smallest devices with your default styles and override from there as your content demands it.

Anecdotally since I started developing my CSS mobile-first, I build fully responsive interfaces much more quickly as opposed to when I start at large screen-sizes and work backwards from there. I find that I don’t have to ‘fix’ my desktop view as my mobile-first CSS works as a desktop interface. I do override my mobile styles to enhance a design at larger screensizes…but I never feel like I’m fixing something that is broken. This was a big shift in my mental approach for authoring CSS.

Light-weight css files turn out to be another by-product of making the switch to mobile-first CSS. Personally I think smaller files are rad because there is less to read and the less you have to read the more time you have to look at cat gifs.

Josef Müller-Brockmann — Grid Systems

“IMMACULATE typography is certainly the most brittle of all the arts. To create a whole from many petrified, disconnected and given parts, to make this whole appear alive and of a piece — only sculpture in stone approaches the unyielding stiffness of perfect typography. For most people, even impeccable typography does not hold any particular aesthetic appeal. In its inaccessibility, it resembles great music. Under the best of circumstances, it is gratefully, accepted. To remain nameless and without specific appreciation, yet to have been of service to a valuable work and to the small number of visually sensitive readers — this, as a rule, is the only compensation for the long, and indeed neverending, indenture of the typographer.

THE REAL reason for the number of deficiencies in books and other printed matter is the lack of — or the deliberate dispensation with tradition, and the arrogant disdain for all convention.”

Jan Tschichold — The Form of the Book

FORM & VARIANCE

The web is fluid. This should be considered when designing screens that are to be rendered by browsers. Last month people visited bluebottlecoffee.com using 1,222 different screen sizes. Building sites that are responsive is only one of the design considerations this introduces. How do you build an interface that is well balanced across all screen sizes? How do you build these interfaces quickly? How do you build them to be readable? How to do you build them to be performant? How do you account for the unknown?

ACCOUNTING FOR THE UNKNOWN

Besides designing for an ever growing number of screensizes and resolutions we must also account for the settings a user picks for their browser. One of these settings is the base font-size. While this can’t be detected with site analytics, it’s estimated from user research studies that 10–12% of people set their default font-size to something other than 16px. So how do we build designs that scale proportionally and relatively for the myriad of combinations between devices and font-sizes that people choose to view the web on? How do we design components and interfaces to be harmonious with each other in the faces of so many unknowns?

PROPORTIONS

Using relative sizing units — we can ensure that measurements will remain proportional no matter what font-size a user has chosen. An explicit pixel value however — will not scale relative to a users settings. This leads to designs that may be responsive — but do not posess the desired visual harmony. Static comps with explicit pixel values are not reflective of the raw materials that make up the web.

ALIGNMENT

The reality of front-end development is that people of varying skill levels will inherently touch your front-end code. This is not a bad thing, but it is a problem that requires design solutions. You must have a system in place that makes it easy for people to build well balanced interfaces with as little difficulty as possible. Not everyone will care about the quality of code, or how it renders to the browser. Not everyone will test the interface on a wide variety of devices with various font-size settings. The best solution I have seen so far is to use a defined system for people to work within, that doesn’t make them think about things they don’t want to think about. The result of this is that regardless of the interface you are working on — your components will all have the same sets of relative proportions and things will just magically line up without time lost to debugging or re-inventing the wheel.

IT’S JUST TEXT

The web, is mostly text. People have been studying typography for centuries and we would be smart to leverage the findings of brilliant designers dedicated to this craft. Regardless of the medium — most great design is mathematically based. When designing around text, modular scales and attention to proportion is considered to be the start of a sound approach. Consider this exerpt from Tschichold’s “Form of the Book”:

The geometrically definable irrational page proportions like 1:1.618 (Golden Section), 1: V^2, 1: V^3, 1: V^5, 1:1.538, and the simple rational proportions of 1:2, 2:3, 5:8 and 5:9 I call clear, intentional and definite. All others are unclear and accidental ratios. The difference between a clear and an unclear ratio, though frequently slight, is noticeable.

While all of these scales would be a good starting point to use for creating a beautiful and harmonious design — all but one lead to sequences of non integer numbers. The 1:2 scale (powers of two) leads to a series of integers that browsers don’t have difficulty rendering. While computers were largely invented to compute mathematical problems, browsers are notoriously horrible at math. They compute simple arithmetic equations and render values inconsistently. To avoid complicated and unsolvable debugging sessions where things don’t line up — integers are the best route.

These ratios are common patterns that can be seen in print, architecture and music so often it is hard to deny them as an elegant underlying order.

Katsura Villa, a Japanese residence and temple is “founded on the unit of the tatami mat which measures 90:180cm” or a 1:2, powers of two ratio. “The aesthetics of this architecture lie in the beauty of its proportions and the materials used.”

KATSURA VILLA

A scale comprised of 5, 10, 20, 25, 30 etc. cannot be represented by a ratio. They are ticks on a numberline not seen anywhere else in nature, print, architecture or music when studying cohesive design systems.

WHY USE 16 AS A BASE?

The default font-size for most browsers is 16px and this is no accident. This is a font-size comparable to type in a book. While printed type is often smaller it’s partly because books are often times held closer to the face then digital screens. While mobile phones and tablets are generally held at the same distance as books they are also used while moving more frequently — this movement affects the readability of word shapes and so 16px is generally the smallest type for content you want to serve up to a user.

In this sample list of graphics display resolutions, you will notice that all of these numbers are divisible by 16, one exception that is not listed here is the SXGA+ graphics resolution that is not approved by any organization and was a break from the mold. It resulted in some weird graphics problems… but that is a different story for a different time.

Granted not all browsers are used at full screen 100% of the time — but it’s a good thing to consider when trying to create proportional designs that scale well. While we aren’t print designers working within a fixed medium — there are consistencies in almost every graphics resolution which we can use to our advantage. It should be noted that these numbers are often times indivisible by 5 and only divisible by 10 50% of the time.

While 5 and 10 are common units because we are (generally) born with ten digits on our hands — it seems more suitable to use 16 as a base measurement for this medium. Time in music is most commonly divided this way as well. 1/16, 1/8, 1/4 1/2 and whole notes. These paralells are not a coincidence. Math and music are the sisters of design.

INCLUSIVE DESIGN

It’s easy to fall into the trap of designing for one context. If you have working legs, you are not likely to notice that a building has been constructed with a long staircase that is not accessible to someone in a wheelchair. If you can’t walk up stairs, you definitely notice. One of the core values I like to embrace when designing is ‘being hospitable.’

What does being hospitable look like on the web? For me being hospitable means not making assumptions about our users and their capabilities. I have better than 20/20 vision. When I first started out as a designer I used a lot of small font-sizes. I thought they looked aesthetically pleasing. I still do.

But I’m not designing for myself. I’m trying to design for everyone. It should be considered that compared to a 20 year old’s retina, the retina of a 40 year old only receives about 50% of available light. An 80 year old retina only receives about 20%. So text set at lower font-sizes and/or low contrasts are actually impossible for some people to read. For reference, a quick scan of age demographics from my personal site analtyics reveals that 40%+ of people that visit my websites are above the age of 35.

Everyone can read large type. Not everyone can read small type. In a similar fasion: everyone can walk up a ramp, while only some people can walk up stairs. I think we should be welcoming to our web guests and cater to their accessibility needs because, well, it’s the right thing to do. It’s a frustrating experience to need to zoom in just to read text. So let’s not make people do it.

Originally posted here: http://mrmrs.io/writing/2015/10/06/design-systems/

Further Reading

• Mathematical Web Typography
• Frank Chimero - The Web's Grain
• Frank Chimero - What Screens Want
• The Form of the Book: Essays on the Morality of Good Design (Classic Typography Series)

Several years ago I worked on a print and email product where our main directive was to ship 0 bugs. While simultaneously shipping features as quickly as possible. On the web ‘mean time to fix failure’ is generally more valuable than ‘mean time between failure.’ This makes sense. Often times you can fix a bug on a website before many people will see it. In the world of print and email though you only get one chance. You can’t unmail an electronic or print document. The ability to work quickly without creating errors or bugs is critical.

Over 3.5 years I ended up shipping two small prose based errors to production. One was caught before we mailed it, one was not. Instead of saying “Track your progress” the text said “Rack your progress.” Not perfect, but definitely better than my record on the web.

It wasn’t an accident I was able to do this. I’m not nor have I ever been a super genius that writes mistake-free code. I benefited from working with engineers that treated this problem of bug free development as their number one priority. They treated my development workflow as a first-class citizen. I was able to sit in meetings and explain problems I had — and people tried to build tools to help me solve them.

The following is a rough outline of our development process. The ideas are simple but they require upfront effort and intention.

Upfront process

When you build a component, tests should be written that expose each state a component can be in. This test should generate a static html file and a corresponding image for every discrete state a component can be in.

What is a component?

Everything is a component. A link is a component. A text input with a label is a component. A modal is a component. A page is a component. Components can be composed of other components.

The test that generates all states of a component should be written before visual ui implementation is begun. This allows the front-end engineer to see all states simultaneously as they work. This has an enormous effect on both the development velocity of new components and the ability to refactor or modify existing components.

For example: If a user can click on a button and reveal new content within the interface — then there should be a test that generates this discrete state. If different accounts render different text to within a component this should be reflected in a test for the component.

When a component has fully undergone and passed visual QA, you can save the generated assets as a canonical set of images and html files.

Refactoring

When you refactor or modify a component you can then run the existing tests and diff the new assets against the ones that have passed QA (imageMagick is great for this). You can then return a list of html files and images that represent visually broken interfaces. This will speed up the ability to refactor existing interfaces without rigorous manual testing. This type of QA is often time consuming and brittle. Many times it doesn’t get done at all. Because who has time?

Side Effects

This development method will also help new members of a dev team get a comprehensive overview for all the states an interface can be in. This feature is also immensely beneficial for designers who are trying to observe the various states of a component that they might be tasked to redesign. Visualizing all the discrete states an application can be in will make your design systems better. This in essence is the most pure form of a ‘living style guide’ and will help your design team develop a cohesive and modular design system.

We can live in this world! The technology exists. We just need to be intentional. If you’re a backend engineer or programmer this is my plea for help. Grab the closest designer or front-end developer and just talk to them. Ask them what slows them down the most. Spend time observing how they work as you might recognize problems in their workflow that they don’t. Front-end developers like myself often lack the agency to fix their own problems and so we just accept the reality that everything is horrible. This doesn’t have to be the case. Everything doesn’t have to be horrible. I was fortunate to work with some amazing people who showed me how great things can be for a designer. They decided to treat front-end development as a first class citizen. I think you should too.

Let’s work together. Let’s push the web forward.

Further reading:

Pure UI

Originally posted at http://mrmrs.io/writing/2016/04/21/developing-ui/

You are in your mid-twenties and your vision is 20/20 or better. You are not color blind and all the devices you own have a ‘retina’ screen. You are standing in a major city and your internet is fast.

Imagine

Your vision isn’t 20/20 anymore, just like 65% of the population, it’s worse than that. Like 4.25% of people on the planet you are color blind. You are now 1 in 10. You are dyslexic. Your phone is 3 years old. You can’t afford a new one. Your data plan caps out at 3g and 1 gigabyte a month. The internet connection where you spend most of your time is not what you’d like it to be.

Imagine

You can’t see at all. You use a computer with a screen reader. A mouse is mostly useless to you. You use your keyboard to navigate around interfaces and sites.

If you woke up tomorrow without knowing what your life would be like — and you needed to build a new internet for everyone. What would you think about? What would your priorities be? What problems would you try to solve?

American philosopher John Rawls (1921–2002) had a lot of mind-crushing ideas, but perhaps the most significant was his concept of “the veil of ignorance.” It best applies to the creation of social contracts. At risk of oversimplification, Rawls’s scenario was basically this: Let’s pretend you were instantly able to re-create American society in totality, and you could do it in whatever way you wanted. You could make (or eliminate) whatever laws you desired, and you could implement whatever financial and judicial structures you believed would work best. However, you must do this under a magical “veil of ignorance.” The moment after you create this system, you’ll no longer be yourself (and you don’t have any idea what your new role in this society shall be). You might be a rough facsimile of your current self, or you might be someone entirely new. Your gender might be different, or your race. It’s possible you will be extremely destitute and appallingly ugly. You’ll have a different level of intelligence and a different work ethic. You might suddenly be disabled, or super athletic, or homosexual, or criminally insane. As such, you will (probably) want to create a society that is as fair and complete as possible, since you have no idea what station you’ll inherit within your own new, self-constructed boundaries. You need to think outside of your current self, because tomorrow you’ll be someone else entirely.

Chuck Klosterman — ‘I Wear the Black Hat’

John Rawls mostly philosophized about theories of justice but I think he would have been a pretty great designer.

Imagine

You drive to a job interview. Before you get out you look in the mirror and straighten your tie. Both of your legs work so you open the door and climb out. Earlier that day you ran 6 miles and did 20 minutes of stretching afterwards. Your legs feel great! You walk across the parking lot and bound up a set of stairs. You don’t think twice about it.

Imagine

You don’t have two working legs. You arrive at a building for a job interview. You exit your automobile and roll across the parking lot. There is no ramp. Your wheelchair can’t climb stairs. You don’t know what to do.

Thanks to the Americans with Disabilities Act this doesn’t happen as much as it used to. Most people don’t view a set of stairs as a barrier to a building. We don’t observe whether or not there is a ramp. We don’t notice if a doorway is wide enough for a wheelchair. Or if a hallway is wide enough to make a 180 degree turn. We most likely don’t think about this because our life doesn’t necessitate it.

When we build things — we must think of the things our life doesn’t necessitate. Because someones life does.

Imagine the frustration of people who use things designed by people who don’t take their basic needs into consideration. I think it is dehumanizing.

“The ADA is one of America’s most comprehensive pieces of civil rights legislation that prohibits discrimination and guarantees that people with disabilities have the same opportunities as everyone else to participate in the mainstream of American life — to enjoy employment opportunities, to purchase goods and services, and to participate in State and local government programs and services.”

Think about the current state of the website/application/digital product you were working on. Can everyone use it with the same opportunity to participate in ‘mainstream American life?’ Statistically speaking, probably not. But you are providing a service.

Facts

• At 20 years old, your retina receives 100% of the light that hits the eye.
• At 40 years old, only 50% of the available light enters the retina.
• For an 80 year old, 25% of the available light passes through the retina.

When people say “My old tired eyes can’t read this” It is because they can’t.

I’ve often hear two complaints when designing for accessibility.

• Accessible color combinations limit my choices as a designer.
• Big type looks clumsy.

First lets talk about color contrast.

There are 140,737,479,966,720 combinations of hexcodes. Obviously not all of them are accessible. If only 1% of all color combinations are accessible than there are still almost 141 million combinations to choose from. This seems more than adequate to paint any bikeshed you will come across for the rest of your career.

Typography

“If it is too small people can hit command + and make the type bigger”

This is a fact that can’t be disregarded. But I offer a counter: If the type is so big that it offends your user they can hit command — and make the type smaller. I have never observed anyone do this. Quite often, I watch people bump up the font-size of the page they are viewing. This seems backwards.

Typography, like color, and music is all about how values relate to each other. If large type looks clumsy it is most likely due to an ineffective type scale that doesn’t relate to the proportions within your design system. Type scales are all about relativity.

The thing about large type, is that everyone can read it. Not everyone can read small type. This is a fact. No one complains that typefaces set at 20px are too big to read. In all of the user testing I have ever done that has never been said. But people have complained about the readability of type set to the equivalent of 10 and 12px.

Consider the consequences of building a ramp instead of a staircase. Anyone can get up a ramp. But not everyone can get up a set of stairs. As a design community I think we should be building more ramps.

The Morality of Designing

I’m a designer. I am not here to focus on making things pretty. I’m here to make things work.

I am a designer because I want to solve problems. I want people to be less frustrated when they use technology. I want to make their lives easier. I don’t want to make anyones life more difficult. These two sentiments sound the same, but they are not. I find both are important to consider.

When I sit down to design things I try to put on the veil of ignorance. I imagine a world where I am not who I am right now. And I think about all the things that could possibly frustrate me. Then I think some more.

I try to design for that reality. I don’t design for myself and my perfect eyesight, my retina screens, and my fast internet connection.

I design for everyone I can think of. Which is a growing list of people with a growing list of concerns that possess a growing number of devices made up of a wide variety of screen sizes.

If everyone can use your product I think it’s good for your business. But even if it wasn’t, I think it would be the right thing to do. Which makes it worth doing.

So I’d do it anyway.

Further Reading

• Mathematical web typography
• Relative Readability
• Section 508
• tota11y

Cross posted from: http://mrmrs.io/writing/2016/03/23/the-veil-of-ignorance/

User-testing is an important part of the design process. It allows you to both hear what users have to say as well as observe how they use a product. Over the last three years I have participated in a number of testing sessions. In that time I never heard a user complain about:

1. the use of system fonts in a design.
2. a website having the same typeface as another site.
3. a page using system fonts that loaded too quickly.
4. a site NOT using web fonts.

On the flip side I:

1. observed users abandon a website because the page was loading slowly.
2. heard people complain about the dreaded flash of unstyled text.

These points were enough to convince me that webfonts cause more problems then they solve and weren’t worth the cost to my users or myself. Webfonts come with a number of costs. They cost money to license. They cost time to implement. They cost time to download, and with some mobile data plans they can cost money to download as well.

Typography is not about aesthetics, it’s about serving the text. If even a small percentage of people don’t consume your content due to a use of webfonts, your typography is failing.

All this being said I care deeply about aesthetics, and I’ve found the following two sentiments to be true:

System fonts can be beautiful.
Webfonts are not a requirement for great typography.

Originally posted here: http://mrmrs.io/writing/2016/03/17/webfonts/

WHAT GOOD CSS DOES

• Doesn’t break any functionality of plain html.
• Makes an interface more readable for everyone on any device.
• Enhances the usability of an interface for all devices.
• Allows you to quickly change a single interface without breaking other unseen interfaces.
• Renders quickly in the browser.
• Runs at 60fps (no jank on window resize or during scrolling).

WHAT GOOD CSS IS

• Highly reusable — even across projects.
• Well documented.
• Easy to read and understand.
• ID free.
• Mobile-first.
• Easy to maintain.
• Very very small.
• Unassuming.

There is an abundance of CSS on the web that constricts these built-in features of HTML. I believe that as CSS authors, we have a responsibility to stop this. If you find yourself writing CSS that removes any of these three features, take a minute to stop and rethink its purpose. Ask yourself what problem could be so important that it’s worth solving at the cost of universal access to your content & readability?

CSS is not here to make our lives as developers easy. It’s here to enhance the usability of the web for our users. CSS should never limit usability.

When we write stylesheets that cascade, we should keep these simple points in mind.