Category: 2020 End-of-Year Thoughts

The series is a wrap, my friends! Thanks for reading and a big special thanks to all the authors this year who shared something they have learned. Many authors really swung wide with thoughts about how we can be better and do better, which, of course, I really love.

• Adam showed us logical properties and, through their use, we’re building layouts that speak the language of the web and are far more easily adaptable to other written languages.
• Jennifer told us that even basic web skills can make a huge difference for organizations, especially outside the tech bubble.
• Jake used TypeScript as a literal metaphor that may be good, or not, to apply to ourselves.
• Miriam defended the genre of CSS art. Not only is it (more than) OK to be a thing, it can open up how we think and have practical benefits.
• Jeremy had lots of luck building with the raw languages of HTML, CSS, and JavaScript, and in doing so, extended the life of his projects.
• Natalya released our tension, telling we can and should waste our time, since this year is all wrong for creativity and productivity anyway.
• Geoff had an incredibly salient point about CSS. Since everything is relative, think about what it’s relative to.
• Mel showed us that there are a variety of interesting sources of open-source-licensed imagery.
• Kitty gave us permission to stop chasing the hype.
• Matthias paid homage to the personal website.
• Ire said that the way websites are built didn’t change all that much this year, and ya know what, it didn’t have to.
• Eric opened the door to other accessibility professionals to have their say. There are some bright spots, some of which came ironically from the pandemic, but the fight is far from over.
• Kilian blamed our collective feeling of being behind on the idea that we think the newfangled is much more widely used than it is. The old is dependable, predictable, and crucially, the vast majority of what we’re all doing anyway.
• Shawn demonstrated that each of us has our own perspective on what is old and new based on when we started. We can’t move our “Year Zero” but we can try to see the world a bit more like a beginner.
• Manuel told us that keeping up isn’t a game we need to play, but it is worth learning things about the languages that we already “know” as there are bound to be some things in there that will surprise you.
• Andy said that every solution to a problem he faces is solved by simplification.
• Erik thinks one of the keys to great design is great fonts.
• Eric went on a journey of web standards, browsers, and security and not only learned a lot but got some important work done along the way.
• Cassidy is seeing old ideas come back to life in new contexts, which makes a lot of sense considering we’re seeing the return of static file hosting as a fresh and smart way to build websites.
• Eric shared a trick that your neighborhood image compression algorithm can’t really help with: indexing colors. If your PNG can look good with a scoped color palette, you’ll have tremendous file size saving there even before it is optimized.
• Kyle is changing his bet from everything changing to things being more likely to stay the same.
• Brian learned to be OK with not knowing everything. Focus on one thing can mean understanding less about others, but that’s the nature of life and time.
• Lea has the numbers on web technology usage on a very wide slice of the internet. Her findings echo what many others in this series are saying: there is a lot more old tech out there than new.
• Jeremy compared video games and the constraints they face (and thrive from) to the constraints we face on the web (which are many).

If I had to pick the biggest major thread that people latched on to (with absolutely zero prompting), I’d say it’s the idea that the web is full of old technology and that’s not only OK but good. There is no pressing need to learn new things, which haven’t always settled out, and can bring more complexity than is necessary.

I’ll do one myself here.

I’m going with the concept of the edge. I definitely didn’t understand what that word meant before this. I’m not entirely sure I have it right, but my understanding is it means global CDNs, but with more capability. We’ve long known CDNs are good, and that we should serve all our static asset (like images) from them. An image served from a physical server 50 miles away arrives at your browser a lot faster than a server 2,000 miles away, because physics.

Well serving images from CDNs is great, but we’re starting to serve more from them. A Jamstack site might serve literally everything from a global CDN, which is an obvious performance win.

And yet, we still need and use servers for some things. A website may need to have a logged-in user, which then pulls a list of things from database which that user owns. A classic single-origin server can do that. Like I literally buy a server from some company to do this work, and while that’s all virtualized, it’s still a physical computer in one physical location (like how AWS has regions like us-west-1).

But there is a (relatively) new alternative to buying a server: serverless. You don’t have to buy a server; you can run your code serverlessly (a “cloud function” like AWS Lambda). I think this is awesome (cheap, fast, secure, easy) but, believe it or not, these cloud functions still have a single physical location they run from. I think that’s weird, but I imagine that’s what helps keep it cheap in these early days. That’s changing a bit, and cloud functions are starting to be available (wait for it) at the edge.

As I write, Lambda@Edge is about 3× the cost of Lambdas in one particular region.

I definitely want my cloud functions to be run on the edge. If I do, it’s better for literally everyone in terms of performance. Right now, I just have to decide if I can afford it. But as time has proven, costs in this market trend downward even as capability increases. I think we’re trending toward a world where all cloud functions are always running at the edge at all times.

Extend that thinking a little further, it’s all-edge-all-the-time. All my static assets are at the edge. All my computing is at the edge. All my data storage is at the edge. The web will always need physical infrastructure, but as the world is more and more covered in that infrastructure, I’m hoping that the default way to develop for the web becomes edge-first.

Oh, and if there is a team that is going to go build out infrastructure in Antarctica, can I come? I really wanna go there.

The post Edge Everything appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

There’s a “C” word in web development that we don’t give enough attention to. No, I’m not talking about “continuous integration”, or even “CSS”. The “C” word I’m talking about is “constraints”. Understanding constraints is a vital part of building software that works the best it can in its targeted environment(s). Yet, the difficulty of that task varies based on the systems we develop for.

Super Nintendo games were the flavor of the decade when I was younger, and there’s no better example of building incredible things within comparably meager constraints. Developers on SNES titles were limited to, among other things:

• 16-bit color.
• 8 channel stereo output.
• Cartridges with storage capacities measured in megabits, not megabytes.
• Limited 3D rendering capabilities on select titles which embedded a special chip in the cartridge.

Despite these constraints, game developers cranked out incredible and memorable titles that will endure beyond our lifetimes. Yet, the constraints SNES developers faced were static. You had a single platform with a single set of capabilities. If you could stay within those capabilities and maximize their potential, your game could be played—and adored—by anyone with an SNES console.

PC games, on the other hand, had to be developed within a more flexible set of constraints. I remember one of my first PC games had its range of system requirements displayed on the side of the box:

• Have at least a 386 processor—but Pentium is preferred.
• Ad Lib or PC speaker supported—but Sound Blaster is best.
• Show up to the party with at least 4 megabytes of RAM—but more is better.

If you didn’t have a world-class system at the time, you could still have an enjoyable experience, even if it was diminished in some ways.

Console and PC game development are great examples of static and variable constraints, respectively. One forces buy-in of a single hardware configuration to participate, while the other allows participation on a variety of hardware configurations with a gradient of performance outcomes.

Does this sound familiar?

Web developers arguably have the most difficult set of constraints to contend with. This is because we have to reconcile three distinct variables to create fast websites:

1. The network.
2. The device.
3. The browser.

With every year that passes, I gain more understanding of just how challenging those constraints are to work within. It’s a lesson I learn repeatedly with every project, every client, and every new technology I evaluate.

Coping with the constraints the web imposes is a hard job. The part of me that abhors how much JavaScript we ship has difficulty knowing where to draw the line of when too much is too much. Developer experience has a role in our day-to-day work, and we need just enough of it to grease the skids, but also without tanking the user experience. Because, as our foundational documents tell us, users are first in line for consideration.

So what did I learn this year?

The same thing I relearn every year, just in a subtly different way every time: there are costs and trade-offs associated with our technology choices. This year I relearned—in clear and present fashion—how our technology choices can lock us into architectures that can both harm the user experience if we don’t step lightly and become increasingly difficult to break out of when we must.

Another thing I learned is that using the platform is hard work. Yet, the more I use it, the stronger my grasp on its abstractions becomes. Direct use of the platform isn’t always the best or most scalable way to work, but using it on a regular basis instead of installing whatever package scratches whatever itch I have right this second helps me to understand how the web works at a deeper level. That’s valuable knowledge that pays off over time, and your ability to build useful abstractions becomes more difficult without it.

Finally, I learned yet again this year that our constraints are variable. It’s acceptable if some things don’t work as well as they should everywhere—but we need to be very mindful of what those things are. How acceptable those lapses in our responsibility to the public depends on the function we serve. If it’s a remotely crucial function, we need to proceed with the utmost care and consideration of users. If this year of rising unemployment and remote learning has taught us anything, the internet is for more than commerce.

My hope is that the web becomes more adaptive in 2021 than it has been in years past. I hope that we start to have the same expectations for the user experience that we did when we were kids playing PC games—that an experience can vary in its fidelity in order to accommodate slower systems—and that’s a perfectly fine thing for the web. It’s certainly more flexible than expecting everyone to cope with the exact same experience, whether they’re on an iPhone 12 or an Android Go phone.

The post Recognizing Constraints appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

My 2020 was colored by the considerable amount of time I spent analyzing data about CSS usage in the wild, for the CSS chapter of the Web Almanac, by the HTTP Archive. The results were eye-opening to me. A wake-up call of sorts. We spend so much time in the bubble of bleeding-edge tech that we lose touch with how the web is really built. Most of the web favors old, stable tech instead of new bling.

CSS-in-JS? Only 2% of websites.

React? Only 4%.

Service Workers? Less than 1%.

Houdini? Practically 0%. 

Nobody uses jQuery anymore, right? Wrong. It appears on 83% of all websites! Everyone uses Jamstack instead of bloated CMSes, right, right? Wrong. Static site generators are used in less than 1% of websites, WordPress powers one-third of the Web.

A lot of the code we found could have been written a decade ago. When new tech ends up being used sufficiently to appear in these stats, it’s often because the primary driver is a popular library or framework. Effectively, we (standards folks, browser implementers, etc.) are building tech for tooling authors, who are the ones really building tech for the average web developer. Quite a perspective shift, isn’t it?

The post How The Web is Really Built appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Recently, I’ve become more deeply aware of the inherent tension between change and inertia, as it applies to the evolution and use of web technologies. These forces have always been present and opposed to each other, but it seems to me that the side effects of these collisions are impacting web development more noticeably.

On one hand, we’ve never seen more progress in the expansion of the array of web platform capabilities; the web is powerful and mature in ways that our 10-year younger selves would be seriously envious of. But on the other hand, like the crisp fall winds signal a seasonal shift, there’s a chill in the air settling down the once feverish pace of new JavaScript features—hello, JavaScript fatigue!—and new JavaScript frameworks seemingly launching weekly.

Technology is a word that describes something that doesn’t work yet.

Douglas Adams

As Adams’s humorous quip might imply, the software (technology) we work on doesn’t work yet, because it (and everything around it!) is always changing and evolving to something better.

Or… so it has seemed for a long time. But from where I peek out at web community trends, I think our community is shifting from the rapid expansion of the past few years to a season of consolidation and establishment.

There seems to be an expected assumption that any web team or project must stack itself on top of Babel, Webpack, TypeScript, JSX for the markup, styled-components (or CSS-in-JS of some sort), and one of just a handful of JavaScript frameworks (like React, Vue, or Angular).

That’s not to say these are the only options. I know there’s the Jamstack crowd who’s increasingly embracing static-site generation, and I know there’s the upstart Svelte crowd who wants to compile away all that front-end framework complexity (or so they claim).

But let’s be honest: the “diversity” we see in front-end framework tech now is more surface than substance. They all use some flavor of component-oriented mechanics (based on some kind of virtualized DOM), and with each new release of each framework, the parity between them is only increasing. We’ll see this space continue its contraction over the next few years, I think, to where the best parts of Svelte are built into React, and vice versa.

What will all this consolidation mean for the pace of change of JavaScript, or CSS, or even HTML itself? Will the core web platform technologies keep growing as they have, or will the demand for these changes subdue as developers stop asking for more and focus instead on doing more with what they’ve already got.

Is front-end tech almost solved? For my whole career, we’ve been assuming that every few years we’ll see a wholesale reinvention of the front end, on that ever-constant search for the perfect framework that rules them all. Are we nearing that point?

What’s clear to me is that the community is favoring inertia over change right now. What does work works so well—why should we rock the ship and try to disrupt and re-invent? The sheer brilliance (paired with countless human decades of blood sweat and tears) that has created the amazing front-end tools and frameworks might have finally done a good enough job that we don’t collectively care to keep asking it to do more.

Can you imagine trying to launch a competitor to React or Vue right now? Can you imagine trying to build a different tool to unseat TypeScript¹? It sure seems like a daunting enough hill that’s probably not worth trying to climb.

The big players have drawn in all the attention of millions of web developers worldwide, and they survived the heated change-fest over the last five years. We’re now settling on those few options that are left, as plenty powerful enough to build what we want. These solutions may not be idealist absolute maximums, but they’re undoubtedly approaching (at least) local maximums.

With the craziness we’ve all faced down in this weird year of 2020, maybe deep down in our guts, we’re all just yearning for some boring, stable, predictable comfort. Maybe that’s at least in part reflecting in our technology choices!?

I’ve been betting on change for, quite frankly, nearly two decades of my career in web technology. But I think my bet might be shifting to the predictability of inertia. We should assume that the default will be to stick to what you know already works rather than constantly looking for what might be emerging next.

Where’s your bet?

The post Change vs. Inertia appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

I spent a good chunk of my work life this year trying (in collaboration with the amazing Noam Rosenthal) to standardize a new web platform feature: a way to modify the intrinsic size and resolution of images. And hey! We did it! But boy, was it ever a learning experience.

This wasn’t my first standardization rodeo, so many of the issues we ran into, I more-or-less anticipated. Strong negative feedback from browsers. Weird, unforeseen gotchas with the underlying primitives. A complete re-think or two. What I didn’t anticipate though, was that our proposal — which, again, was “only” about modifying the default display size of images — would run afoul of the fundamental privacy and security principles of the web. Because before this year, I didn’t really understand those principles.

Let me set the table a bit. What were we trying to do?

By default, images on the web show up exactly as big as they are. Embedding an 800×600 image? Unless you stretch or shrink that image with CSS or markup, that’s exactly how large it’s going to be: 800 CSS pixels across, and 600 CSS pixels tall. That’s the image’s intrinsic (aka “natural”) size. Another way to put this is that, by default, all images on the web have an intrinsic density of 1×.

That’s all well and good, until you’re trying to serve up high-, low-, or ✨variable✨-density images, without access to CSS or HTML. This is a situation that image hosts like my employer, Cloudinary, find themselves in quite often.

So, we set out to give ourselves and the rest of the web a tool to modify the intrinsic size and resolution of images. After a couple of re-thinks, the solution that we landed on was this:

1. Browsers should read and apply metadata contained within image resources themselves, allowing them to declare their own intended display size and resolution.
2. Following in the recent footsteps of image-orientation — by default, browsers would respect and apply this metadata. But you could override it or turn it off with a little CSS (image-resolution), or markup (srcset’s x descriptors).

We felt pretty good about this. It was flexible, it built on an existing pattern, and it seemed to address all of the issues that had been raised against our previous proposals. Alas, one of the editors of the HTML spec, Anne van Kesteren, said: no. This wasn’t going to work. And image-orientation needed an urgent re-think, too. Because this pattern, where you can turn the effects of EXIF metadata on and off with CSS and HTML, would violate the “Same-Origin Policy.”

Uh… what?

Aren’t we just scaling and rotating images??

Confession time! Before all of this, I’d more or less equated the Same-Origin Policy with CORS errors, and all of the frustration that they’ve caused me over the years. Now, though, the Same-Origin Policy wasn’t just standing between me and handling a fetch, it was holding up a major work initiative. And I had to explain the situation to bosses who knew even less about security and privacy on the web than I did. Time to learn!

Here’s what I learned:

• The Same-Origin Policy isn’t a single, simple, rule. And it certainly isn’t == CORS errors.
• What it is, is a philosophy which has evolved over time, and has been inconsistently implemented across the web platform.
• In general, what it says is: the fundamental security and privacy boundary of the web is origins. Do you share an origin with something else on the web? You can interact with it however you like. If not, though, you might have to jump through some hoops.
• Why “might?” Well, a lot of cross-origin interactions are allowed, by default! Generally, when you’re making a website, you can write across origins (by sending POST requests off to whoever you please, via forms). And you can even embed cross-origin resources (iframes, images, fonts, etc) that your site’s visitors will see, right there on your website. But what you can’t do, is look at those cross-origin resources, yourself. You shouldn’t be able to read anything about a cross-origin resource, in your JavaScript, without specially-granted permission (via our old friend, CORS).
• Here’s the thing that blew my mind the most, once I finally understood it: cross-origin reads are forbidden by default because, as end-users, we all see different world-wide webs, and a website shouldn’t be able to see the rest of the web through its visitors’ eyes. Individuals’ varied local browsing contexts – including, but not limited to, cookies — mean that when I go to, say, gmail.com, I’m going to see something different than you, when you enter that same URL into your address bar and hit “return.” If other websites could fire off requests to Gmail from my browser, with my cookies, and read the results, well – that would be very, very bad!

So by default: you can do lots of things with cross-origin resources. But preventing cross-origin reads is kind of the whole ballgame. Those defaults are more-or-less what people are talking about when they talk about the “Same-Origin Policy.”

How does this all relate to the intrinsic size and resolution of images?

Let’s say there’s an image URL – https://coolbank.com/hero.jpg, that happens to return a different resource depending on whether or not a user is currently logged in at coolbank.com. And let’s say that the version that shows up when you’re logged in, has some EXIF resolution info, but the version that shows up when you’re not, doesn’t. Lastly, let’s pretend that I’m an evil phisher-man, trying to figure out which bank you belong to, so I can spoof its homepage and trick you into typing your bank login info into my evil form.

So! I embed https://coolbank.com/hero.jpg on an evil page. I check its intrinsic size. I turn EXIF-sizing off, with image-resolution: none, and then check its size again. Now, even though CORS restrictions are preventing me from looking at any of the image’s pixel data, I know whether or not it contains any EXIF resolution information — I’ve been able to read a little tiny piece of that image, across origins. And now, I know whether or not you’re logged into, and have an account at, coolbank.com.

Far-fetched? Perhaps! But the web is an unimaginably large place. And, as Jen Simmons once put it,

Browsing the web is basically going around running other people’s untrusted and potentially malicious code, willy-nilly, all day long. The principles that underly web security and privacy — including the Same-Origin Policy — enable this safety, and must be defended absolutely. The hole we were unintentionally trying to open in the Same-Origin Policy seemed so small, at first. A few literal bits of seemingly-harmless information. But a cross-origin read, however small, is a cross-origin read, and cross-origin reads are not allowed.

How did we fix our spec? We made EXIF resolution and orientation information un-readable across origins by making it un-turn-off-able: in cross-origin contexts, EXIF modifications are always applied. An 800×600 image whose EXIF says it should be treated as 400×300 will behave exactly like a 400×300 image, would, no matter what. A simple-enough solution — once we understood the problem.

As a bonus, once I really understood the Same-Origin Policy and the whys behind the web’s default security policies, a bunch of other web security pieces started to fall into place for me.

Cross-site request forgery attacks take advantage of the fact that cross-origin writes are allowed, by default. If an API endpoint isn’t careful about how it responds to POST requests, bad things can happen. Likewise, Content Security Policy allows granular control over what sorts of embeds are allowed, because again, by default, they all are, and it turns out, that opens the door to cross-site scripting attacks. And the new alphabet soup of web security features — COOP, COEP, CORP, and CORB — are all about shutting down cross-origin interactions completely, fixing some of the inconsistent ways that the Same-Origin Policy has been implemented over the years and closing down any/all possible cross-origin interaction, to achieve a rarefied state known as “cross-origin isolation”. In a world where Spectre and friends mean that cross-origin loading can be exploited to perform cross-origin reading, full cross-origin isolation is needed to guarantee saftey when doing various, new, powerful things.

In short:

• Security and privacy on the web are actually pretty amazing, when you think about it.
• They’re a product of the platform’s default policies, which are all about restricting interactions across origins.
• By default, the one thing no one should ever be able to do is read data across origins (without special permission).
• The reason reads are forbidden is that we all see different webs, and attackers shouldn’t be able to see the web through potential victims’ eyes.
• No ifs, ands, or buts! Any hole in the Same-Origin Policy, however small, is surface area for abuse.
• In 2020, I tried to open a tiny hole in the Same-Origin Policy (oops), and then got to learn all of the above.

Here’s to a safer and more secure 2021, in every possible sense.

The post I learned to love the Same-Origin Policy appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

In an age where so much web design is already neat, clean, and simple, I can think of three ways to distinguish your site from the norm:

1. Stunning visuals that cannot be created in UI vector editors, like Figma and Sketch
2. Beautifully-animated interactions that cannot be dreamt in the language of Stacks of Rectangles
3. Typography

The third is the most accessible, and an awesome place to differentiate your brand. Accordingly, look for a renaissance of type — a flourishing of serifs, throwbacks, quirky fonts, and genre-bending typefaces. Expect that font pairing will become an even more important skill, and picking great fonts for your brand will carry even more weight in the near future.

After all, it’s basically a design cheat code.

🔥 There are only two “cheatcodes” in UI design. The first is: USE GOOD FONTS. Here, the popular but slightly too goofy Abril Fatface pales in comparison to stately Freight.
(10/50)

PS. More font recs here: https://t.co/zFle4by2Iq pic.twitter.com/vnpoHMq4I0

— Erik D. Kennedy (@erikdkennedy) November 27, 2020

The post Three Ways to Distinguish a Site From the Norm appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

When I first got this writing prompt, my mind immediately started thinking stuff like, “What tech have I learned this year?” But this post isn’t really about tech, because I think what I’ve learned the most about building websites this past year is simplification.

This year, I’ve learned that keeping it simple is almost always the best approach. Heck, I’ve been banging that drum for a while, but this year has really solidified those sort of thoughts. I’m trying to think of a single instance where a complex, technical issue has arisen this year, where the end-solution didn’t come about due to simplification, and I’m coming up blank. Sure, ideas almost always start off over-complicated, but I’m learning more and more that slowing down and refining ideas is the best approach.

Brendan Dawes created this great piece of art, and coincidentally, a copy of it sits on my wall. I think it illustrates my working process perfectly and acts as a constant reminder to refine and simplify.

I run Piccalilli and released my first course this year. I really wanted to self-publish that material, too. Sure, keeping it really simple would have me publishing the course on an existing platform, but I had some red lines. The first being that I had to own everything because if a provider or platform turned out to be ass-hats, then I’d be in a pickle.

Another red line was that my content had to be written, rather than videos, which again, makes owning my own content important, because some platforms can pull the rug from under your feet. A good example is Medium’s ever-changing content access rules and inconsistent paywall behavior.

Finally, the red line of all red lines was this: the content had to be fully accessible and easily accessed. You might be thinking they’re the same thing, but not quite: the easily accessed part means that if you buy content from me, you sure as heck will get to it with as little friction as possible.

This loops me nicely back to keeping things simple. To make access simple for my valued students, I needed to simplify my approach to them accessing content, while locking people out who hadn’t purchased it. My immediate thoughts — naturally — went into some complex architecture that was extremely smart™, because that’s what we do as developers, right? The difference this year versus previous years is that I forced myself to simplify and refine because I wanted to spend as little time and energy as possible writing code — especially code I know is going to haunt me in the future.

So, again, thinking about these red lines, the big caveat is that currently, my site runs off a static site generator — Eleventy, naturally — and my need for simplification along with this caveat led me to an obvious conclusion: use the platform.

In short, I used Service Workers to give people access to content. My site builds twice on Netlify. Once is what you see, over on piccalil.li. But there’s a secret site that is all exposed (it’s not really, it’s like Fort Knox) that has all the content available. When you buy a course, my little API scurries along to that site and finds all the content for it. It then pushes that down to you. Then, the platform takes over because I use the baked-in Cache and Response APIs. I create a Response for each lesson in the course, then stick it in the Cache. This means that whenever you go to a lesson, you get that version that was previously hidden from you. The added bonus to this is that the content is offline-first, too. Handy.

Sure, this solution relies on JavaScript, but heck, not much at all — especially when you compare it to even the simplest projects that produce extremely JavaScript-heavy outputs, like Gatsby et al.

Using the platform is super low maintenance because, y’know, it’s all baked into the browser, so it doesn’t keep me up at night, worrying that it’ll suddenly break if a rogue developer deletes a package. I could have also put together some galaxy brain stuff but that has a huge risk of creating technical debt and breaking at least one of my red lines: make content fully accessible and easily accessed. The platform again, wins.

If I push a big ol’ bundle of JavaScript down the pipe to a low-powered device and/or a slow connection, the chances are that content will not make it, or if it does, it will likely fail to parse. That alienates a lot of people which breaks red lines for me. Sure, building the site with this technology would keep it simple for me, as I wrote it, but utilizing the platform keeps it simple for everyone — especially me, when I need to maintain it. I’m digging that, a lot.

The post Learning to Simplify appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

This year I had the pleasure of re-launching The Accessibility Project. I spend a lot of time researching and writing about accessibility and inclusive design, so this felt like the cumulation of a lot of that effort. The site now uses all sorts of cool web features like CSS Grid, @supports, and media features, aria-current, Service Workers, and Eleventy. But that’s really not the important bit.

The important bit I learned this year is the same thing I learn over and over again: When it comes to disability, representation matters.

In my exploration, the importance of representation is a layered truth I find myself re-internalizing as I learn more about the different communities that make up the accessibility space. I am extraordinarily thankful to be welcomed into these communities, and grateful to be able to participate in them. 

We must, however, acknowledge that it is a lot easier for me to enter into these communities than the other way around. Disabled people frequently face many barriers towards representation in many industries, ours included. Considering that, I thought I’d ask disabled people who work on the web what they’ve learned. Here’s what they told me:

Software Engineer Nadhim Orfali comments on their experience working with design systems, accessibility, and documentation:

After a company-wide shift to Vue, it’s easier and faster for teams to adopt the design system. Due to the release of scoped packages along with CI/CD architecture and intertwined with documentation, the process is more streamlined with most of the accessibility built-in. I’m seeing teams much more aware and interested in all matters relating to accessibility, which can only be a good thing!

User experience designer Francis C. Rupert comments on how quarantine has affected everyone:

In 2020 everyone was struck with a shared Situational Disability by everyone wearing a mask. Hearing loss isn’t necessarily always about volume, but speech discrimination. We collectively lost the ability to distinguish between consonants and vowels, and everyone else sounds garbled through their masks.

Anne Berlin, technical SEO and web manager, also comments on some remote work benefits:

I don’t have to worry about someone coming in with strong fragrance, which can send my brain into haywire. I can control the light level of the room and brightness level of my monitors, and a bit more control over the noise level.

It’s not all good vibes, however. Web developer Olu also chimes in about remote work: 

Quarantine has also shown how adaptable companies can be when their backs are against the wall. It’s funny how disabled people can ask for accommodations for years and then when they have no choice suddenly these accommodations are becoming permanent for everyone. 

Anne also mentions:

Pressure to pass as abled due to ignorance about “invisible” disabilities or lack of proactively inclusive culture for a range of things including cognitive styles, or issues with overstimulation.

Disability is more than physical access. Managing Director Josh Clayton mentions the cognitive fatigue that comes with framework churn:

The continued use of React is concerning. The JavaScript ecosystem is fragmented, with a lot of people doing a lot of work and nobody producing anything new. I don’t mind investing in technology where I feel like I’m getting something. There’s just so much churn, I don’t bother to keep up. I would like to think it’s not sacrificing future employability if I was going to look for a new job, but when it comes to other person’s money, there’s the “newshiny,” or “is this actually the right thing you should be doing right now?”

Developer EJ Mason doesn’t mince words:

What I have learned about the industry is that it is unrepentantly ableist.

While I’m happy to see progress being made on some fronts, we need to understand that doing technical work to make websites accessible is only part of the picture. We need to realize that usable products can be created in exclusionary spaces. Only by including disabled people in the product creation process can we truly improve as an industry.

Thank you to Jennilee Rose, Nadhim Orfali, Francis C. Rupert, Jen Diaz, Anne Berlin, Olu, Josh Clayton, EJ Mason, and everyone else who shared their experiences with me.

The post Representation Matters appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

What’s one thing I learned about building websites this year? Not all that much.

This year, unlike most previous years, I didn’t explore a lot of new technologies. For obvious reasons, it’s been a difficult year to be as engaged in the hot new topics and to spend time playing around with new things. So, for the most part, I’ve tried to keep calm and carry on.

That said, I did try a couple of things that were new to me. I built my first React application (after stubbornly holding out for so long). This was a bit of a struggle for me, coming from using a fully fledged framework, like Angular, to a strictly UI library, like React, and I learned a lot about the difference between libraries and frameworks in the process.

I also trialled Tailwind to see what a radically different way of writing CSS (or in this case, not writing CSS) could be like. This was a really fun trial and although I’ve gone back to my good-ole-SCSS, I have taken with me the idea of utility CSS classes. For example, I now create utility classes for things like aligning text, so the line text-align: center; is only written once in my CSS file.

But ultimately, I’ve found that my way of building websites hasn’t changed all that much this year. And more importantly, it didn’t have to.

The post Not Much appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

One thing I noticed about building websites in 2020: despite all the social networks and publishing platforms craving our content, our stories, and our attention, people are somehow still building personal websites. Over the course of the year, many of you have launched or relaunched your website. It indeed feels like the personal website is experiencing a little revival.

To me, this comes as no surprise. The benefits of having your own personal site are enormous and appealing. As a creator, publishing on your own website might even be the single best thing you can do, both professionally and personally.

Personal websites are such a thing. If you don’t have a website yet, come join us on the other side where the web is (still) personal. It’s worth it.

The post Make it Personal appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

This year I learned, or relearned maybe, that “normal” is subjective at best, and pretty misleading otherwise. If this forsaken year has taught us anything, it’s that there is no such thing as normal. Things change. People adapt. Everything is relative to everything else.

Besides being quite metaphysical, this somewhat connects to front-end development, our industry, and the sort of expectations we have for people down there. Too often, it feels like we tend to apply our own insecurities onto others.

I learned this way and so should you.

I know about this and you should too.

I don’t care about this therefore it’s not necessary.

This behavior needs to stop. We have to acknowledge that this industry is, for the most part, self-made and therefore does not have a clear learning path, let alone a defined success trajectory. As they say, Your Mileage May Vary™.

Let this message be for everyone who’s just starting in this field, everyone fresh out of bootcamp or university, and everyone with insecurities or impostor syndrome. This is for everyone who feels like they are not enough and don’t belong here.

You belong here.

Your experience, no matter how different than someone else’s, is valid.

There is no definitive list of skills to have. There is no mandatory technologies to look for. You don’t have to keep chasing the hype. At the end of the day, knowing HTML, CSS and some JavaScript should be enough to make do. You will learn the rest in due time. You have your entire career to learn new things. There is no rush to learn everything right now.

Breathe. Enjoy what you already know. You are doing well. Welcome to the craft.

The post There is No Normal appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.