#214: It’s a matter of CSS perspective

CSS transforms and perspective

One thing I don’t see enough on the web are experiments with CSS transforms and I was reminded of this the other day when I saw this great example from Meng To:

I think transforms and changing perspective in this way can be used in a lot of places, and not just on splashy marketing sites.

Speaking of which—ztext.js is a lil JavaScript library that lets you apply perspective and transforms to text. And the great thing about this is just how dosh garn easy it is to apply very fancy typographic techniques to whatever typeface you’re using on your site and even add animations to them, too:

Stay tuned to the blog in the coming weeks as we have a dedicated article to CSS perspective coming out soon that is more of a hands-on walkthrough rather than just our reference in the Almanac.


Morphing SVG with react-spring

Continuing with this thread of cool things I don’t see enough of, here’s Mikael Ainalem writing about morphing SVG elements and how they can be an effective way of grabbing someone’s attention and adding polish to a design. (If you’re new to react-spring, Adam Rackis recently covered that as well.)

One of the interesting points that Mikael makes and one that had me nodding violently to, was this point:

I have yet to find the perfect development environment for working with SVG. Currently, I go back and forth between the vector editor, the IDE, and the browser. There’s a bit of copying and some redundancy involved. It’s not perfect, but it works. I have experimented a bit, in the past, with scripts that parse SVGs. I have still not found something that I can apply to all scenarios. Maybe it’s just me who got it wrong. If not, it would be great if web development with SVGs could be a bit more seamless.

I definitely agree on this point. I feel like working with SVG requires handling all these different tools—editing them in an editor, viewing them in the browser, opening up DevTools to inspect the element. Perhaps there’s a tool or a workflow that I should be using that could make working with SVG easier.

There are some tools that might hit the sweet spot for you, check out our roundup of Tools to Visualize and Edit SVG Paths.

There’s a part of me that desperately wants to draw SVG and animate it and edit the code all in the same place. Oh that also reminds me of this tool I spotted earlier that lets you drag and drop an SVG and then warp it into all sorts of weird shapes:


Figma Community

The other day I remembered that Figma has a ton of plugins and community-built improvements which can make the design process so much easier. Take plugins for example, where they can automate things that might otherwise be annoying, or the community resources which are basically assets you can drag and drop into your work

One example I love is the The Avatar illustration system where you can attach all sorts of body pieces and facial features to create new illustrations:

Our post on Diverse Illustration has some other tools that work similarly as well.

And there’s one super handy plugin where you can sync a Figma doc with Google Sheets. This is fabulous because updating text nodes in Figma and making the design use realistic data can be a giant pain. Oh and that reminds me, there’s this great website called Design Systems for Figma which is a collection of Figma documents so you can see how people are organizing things and documenting them. I’ve been looking through them a bit to see if there’s something missing in our design system at Sentry.


The difference between aria-label and aria-labelledby

These two HTML attributes are tricky because they’re so very similar but Leonie Watson sets out the difference clearly in this handy post where she writes:

There are ways an element can be given an accessible name without using aria-label or aria-labelledby. For example, put text inside a link or button, use the alt attribute to give an image a text description, or match the for attribute on a label element with the id attribute of the form field it relates to.

If you think ARIA is the right solution, then the second question is whether the piece of text already exists in the document. Generally speaking it’s better to reuse than duplicate, so using aria-labelledby to associate the piece of text with the element makes sense if the text already exists. If it does not exist elsewhere, then use aria-label.

This might be a bit embarrassing to say in this ol’ newsletter—but!—I wonder if I should take a course on ARIA specifically. I feel like so much of my attention when it comes to web design has been entirely focused on the visual representation—animations and typography and CSS—that I haven’t given anywhere near as much thought into semantics and meaning.

Following Leonie’s work is a very good place to start, I think.


Building a community-driven site with Eleventy

Stephanie Eckles walks through how she built Style Stage with Eleventy and contributions from other folks and one part that made me perk up a bit is when she makes this super interesting point:

In the not-so-distant past, creating a community-driven site could potentially be a painful process involving CMS nightmares trying to create contributor workflows. Armed with Eleventy and a few other modern tools, this is now nearly fully automatable with a minimum of oversight.

This is possible for a bunch of reasons: Netlify’s deploy previews, being able to setup Zapier/IFTTT actions to redeploy a site, and the developer friendliness of Eleventy. When combined together, these tools make things exponentially easier to update a website and allow others folks to contribute, too.

And this makes me even more excited for the future of these tools.

Stephanie approached this from two angles. The technological side, and the human side, meaning all the things you need to think about to be ready for public contribution.

Netlify’s Open Authoring is still a mighty cool concept that I’d love to see more CMS’s figure out how to implement nicely.


Dropdowns with custom styles

Speaking of Stephanie’s work, earlier this month she also wrote about styling select elements and how they can be a bit of a pain; making sure browsers render the select in a similar way, recreating the dropdown triangle, and figuring out styles for both focused and disabled states.

There are a lot of things to care about here! So I’m most definitely going to need this post when I get around to styling select elements again in the future.

Sandrina Pereira’s “Hybrid Select” is also a very strong contender, as it seems to have gotten nothing but thumbs up from the accessibility community.


This vs. That

Here’s a nifty website called This vs. That which compares two similar things in web development and points out all the differences between them. Take display: none and the hidden attribute for example. It sounds like they’re very similar but under the hood, and not to mention the impact that they have on the user, makes they’re very different.

There’s a whole bunch of good practices here. I need to spend a little while sitting down and going through these examples later this evening with the hottest cup of tea I can muster.


CodePen PRO

Did you know it’s possible to make private Pens on CodePen? Or that you can upload assets and use them on any demo you make? You can even pair program live with anyone without being in the same room.

That’s the power of CodePen PRO and it all starts at $8 per month.

Sign Up Now →


[Chris]: An illustration from Elijah Manor about CSS “Resets” vs CSS “Normalize”:

Normalizing isn’t a new concept. The first commit on Normalize.css was 9 years ago (2011). You won’t find stuff like h3 styles in there, because browsers are already consistent with that, so it doesn’t wipe them away. I like its sister-in-arms sanitize.css which is philosophically similar but has some more opinionated stuff in it like box-model adjustments. I don’t really see these things be talked about that much anymore. Not enough to have a sense of which philosophy seems to have more use than the other anyway. Perhaps it’s because there are other philosophies out there, like:

  • Just do what Bootstrap gives you. (They have their own concept called Reboot).
  • My fancy styling system has its own ideas. (e.g. I know someone who really likes Material UI, and they have an import called CssBaseline you import if you want to).
  • Do nothing. Browsers aren’t terribly inconsistent anyway, and when they are, it might not matter much. Plus, by applying styles you are making things more consistent as you go. If there is a bug, fix it with a style.
  • * { margin: 0; padding: 0; } is a classic (the origin of this site’s logo) that does a lot of forceful resetting.

If you’re going to go the Normalize philosophical route, I always thought and interesting approach is to start with that as your style.css essentially. Then never remove anything, but only change and add to it. That way you’re guaranteed consistent styles and aren’t double-applying styles.