Front End Web Development

Ruby Sass to be put to pasture on March 26, 2019

Css Tricks - Tue, 04/03/2018 - 3:36am

There have long been multiple implementations of Sass. Most notably, the canonical Ruby version, now at 3.5.6. Then there is LibSass, the C++ version, which is at version 3.4 and...

Current LibSass 3.4 should be compatible with Sass 3.4.

LibSass is notable because it powers the majority of Sass ports. Over 30 of them, apparently, including the most popular one: node-sass, which provides Sass for the bajillion projects out there that wanna run an npm-y JavaScript-based dev environment and avoid the Ruby dependency.

It's a little unfortunate LibSass isn't up-to-date with current canonical Sass, but I think it's on freeze as it's been stated that LibSass will never be canonical Sass. Update: it's not on freeze. It was actually Ruby Sass that was once on freeze with the intention of allowing LibSass to catch up. As I write, LibSass is at 3.5.2, so it's close.

Dart Sass just went 1.0.0, and is now 100% compatible with Ruby Sass 3.5.6. They announced that Ruby Sass has now begun deprecation and—after March 26th, 2019—will no longer be maintained.

The future of Dart Sass looks pretty good:

Another big announcement: as of today, I'm working full-time on @SassCSS. This has been a goal for my entire career and I'm thrilled that it's finally happening

— Blue Gay Carmen San Diego (@nex3) April 3, 2018

The Dart Sass compatibility is also great, because node-sass can now switch to Dart Sass bindings and become entirely up to date. Will it? I have no idea. The maintainer of LibSass and node-sass is the same person (Michael Mifsud), and with 30+ bindings to LibSass, I can't imagine LibSass just going away. I guess we'll just have to wait and see a while. I gotta imagine someone will jump on making a node version of Dart Sass one way or another.

I, for one, would love to see a Web Worker version.

The post Ruby Sass to be put to pasture on March 26, 2019 appeared first on CSS-Tricks.

IBM Plex

Css Tricks - Mon, 04/02/2018 - 11:32am

Here’s a free new font for IBM Plex, a family of typefaces by the iconic company of the same name. It's on Google Fonts if you want to use it.

And we're talking about a multifaceted font. It touts having:

  • Roman and Italics
  • Four subfamilies
  • Eight weights
  • Support for 100 languages

The site promoting the font is noteworthy in and of itself. It's been designed to showcase how the typefaces were built as a single, complex system and tells the story in interactive sections using a parallax effect. Even if you’re not a big fan of the typefaces themselves (although I certainly am), it’s still super interesting to see how they visually describe the challenges they faced when in the design process. There’s lots of weird and interesting UI things going on here.

If you love news about companies making their own fonts, there have been a few others lately like U.S. Soccer's 90 Minutes and Netflix Sans.

Direct Link to ArticlePermalink

The post IBM Plex appeared first on CSS-Tricks.

Catching up on AMP News

Css Tricks - Mon, 04/02/2018 - 8:55am

The big news since we last talked about AMP is that the AMP team announced that there will be a way for non-AMP sites to make their way into the coveted Google search results carousel. Malte Ubl:

Based on what we learned from AMP, we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology in areas of Google Search designed for this, like the Top Stories carousel.

You can't do it now, nor is it clear exactly how you'll be whitelisted, but apparently Google is open to it. The ticket in will be utilizing hopefully-someday standardized things like Feature Policies, which, like AMP, disallow certain features in the name of... well that's the thing. It used be be in the name of speed, but the messaging seems to be more like in the name of privacy and security now. Also a good goal, just funny that "Pages" is about the last thing left in the AMPcroymn. Sorry.

This is the checklist of related technologies. Makes my eyes glaze over a bit as I know precious little about any of them. Much of it needs to progress through standards processes and browser implementation first, and we'll just have to see how practical it all is. If it means people stop creating amp-dot version of their websites (the new m-dot), that'd be pretty swell.

Tim Kadlec and Yoav Weiss got shout-outs in that AMP announcement for their idea of a "Content Performance Policy". As in, if a website promises and upholds the promises of being fast and not doing nefarious crap, it gets the same benefits as an AMP site.

I mention that as Tim has some new AMP data to share, directly related to AMP's speed. Tim found 50 random news article pages that were using AMP and tested them various ways. I'll summarize the results in best to worst order:

  1. The non-AMP version: not great
  2. AMP version standalone: a bit better
  3. AMP version with cached copy of AMP library: a good bit better
  4. AMP version from Google Search: instant

Tim mentions that it isn't very useful to test against those instant results:

evaluating AMP’s performance based on how those pages load in search results tells us nothing about the effectiveness of AMP itself, but rather the effectiveness of preloading content.

If we can adhere to some standards-based stuff and get Google doing that same preloading for those of us who'd rather not amp-dot, that'd be great. Show me the money. Did I do that movie reference right? I never saw that movie.

The post Catching up on AMP News appeared first on CSS-Tricks.

Know JS online event

QuirksBlog - Mon, 04/02/2018 - 5:24am

On 13th of April the inaugural Know JS online conference takes place. I’m tangentially involved, though I will not speak. The conference is online, and runs from 9am to 6pm Eastern on 13th of April. You can attend from the comforts of your own house.

Know JS is a fairly special type of online conference. Four speakers, Kyle Simpson, Bianca Gandolfo, Kent C. Dodds, and Jem Young, will give not a conference talk, but a full two-hour workshop about a topic of their choice. By buying a ticket you get access to all four of these workshops.

In addition, all four speakers will release a pre-recorded short presentation that sets the tone for their workshops, and these presentations will be available for anyone, not just for ticket holders. They will be published as they come in, starting today.

Tickets are $299, and we decided to cap their number at 50, so that some sort of live interaction between the attendee (that’s you!) and the teacher is possible.

This is a fairly unique type of conference, and credit wholly goes to Kyle, who came up with the idea. His fellow organisers, Brian Rinaldi and me, thought this was a very interesting take that we should try. So here we are, trying it.

This project started with Brian and me meeting in Sofia, and since we’re both conference organisers the conversation quickly turned to conference organising. We found that both of us would like to run a JavaScript event that was not focused on one or more of the popular framenworks, but instead on the language itself. We feel this topic is somewhat underrepresented in today’s conference cycle.

We decided to get Kyle Simpson on board, and our thoughts started to run toward an online event. Although all three of us would prefer a real conference, we weren’t sure how well the topic would be received. So we’re testing the waters, as it were, and if this event is a success, we’ll probably make the jump to an offline conference, ideally with editions in the States and in Europe.

We’ll see what happens next. But if you’re interested in JavaScript the language, please take a good look at what we’re offering.

Iron Man’s Arc Reactor Using CSS3 Transforms and Animations

Css Tricks - Mon, 04/02/2018 - 3:29am

Alright Iron Man fans, fire up your code editors! We are going to make the Arc reactor from Iron Man’s suit in CSS. Here’s what the end result will look like:

See the Pen Iron Man's Arc Reactor by Kunal Sarkar (@supersarkar) on CodePen.

The Full Page Wrapper

We will make our Arc reactor on a dark full-page background. Here’s our code to make a full page wrapper element:

body { margin: 0; } .fullpage-wrapper { height: 100vh; background: radial-gradient(#353c44, #222931); }

Why do we declare no margin on the body? The <body> element has some margin set to it by default in the user agent stylesheet. This prevents the elements inside the <body> to touch the edges of the screen. Since we want our wrapper to cover the entire screen, edge to edge, we removed that default margin on <body> element by setting it to 0.

We’ve given our .fullpage-wrapper the full height of the viewport. We don’t have to specify a width because a div is full width by default. We could have gone with another approach by setting both the width and height of the element to 100% but that comes with some possible drawbacks as more elements are added to the screen. Using viewport units ensures our wrapper always occupies the full vertical space of the screen, regardless of what it is or what other elements are added to the layout.

We also used a radial gradient on our wrapper using radial-gradient() CSS function. The parameters inside the function are the color start and end points. So, the center of the background will be more #353c44 and more #222931 towards the edges. It’s subtle, but a nice touch.

Centering the Reactor Container

Before we start creating our reactor, let’s create a container for it and center it:

.reactor-container { width: 300px; height: 300px; margin: auto; border: 1px dashed #888; }

This gives us a 300px x 300px box with dashed border. The margin: auto; declaration ensures equal horizontal spacing.

But why it doesn’t center it vertically?

Per CSS2 specs, if we give auto margin to the left and right side, then the entire available space will be equally divided to left and right margin. This isn’t the same case for the top and bottom margin though. For top and bottom margin the CSS2 spec says:

If margin-top, or margin-bottom are auto, their used value is 0.

However, we do have a good news. The flexbox layout follows new rules of alignment, and here’s what the Flexbox spec has to say:

Prior to alignment via justify-content and align-self, any positive free space is distributed to auto margins in that dimension.

This means if the element in consideration is displayed as a flex item, then margin: auto; will work in both the directions. Let’s make our wrapper a flex container and its child elements flex items:

.fullpage-wrapper { width: 100%; height: 100vh; background: radial-gradient(#353c44, #222931); display: flex; }

There, that’s much better:

There are many other methods to center elements in HTML. There’s a detailed guide on centering right here on CSS-Tricks to learn more.

The Reactor Core: Concentric Circles in CSS

We know that new elements in HTML are created from left to right (for left-to-right languages), or top to bottom. Elements never overlap, until you provide some negative margin.

So, how are we going to display concentric circles? We will use absolute positioning.

The default value of position property is static. Static and relative positioning follow the flow of top to bottom and left to right. However, an absolutely positioned element is not treated as a part of the document flow and can be positioned anywhere using the top, right, bottom and left properties.

Let’s start by creating the smallest circle:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- the smallest circle --> <div class="core-inner"></div> </div> </div> .core-inner { position: absolute; width: 70px; height: 70px; border-radius: 50%; border: 5px solid #1b4e5f; background-color: #fff; }

We need to center this div. You might be tempted to apply the same flexbox concept we used on the reactor element to center this circle as well. But, here’s what CSS2 spec has to say about setting margin: auto; on absolutely positioned elements:

If none of the three (top, height, and bottom) are auto: If both margin-top and margin-bottom are auto, solve the equation under the extra constraint that the two margins get equal values.

This means if an absolutely positioned element has any value for top, height and bottom other than auto, then setting the top and bottom margin to auto will center the element vertically.

Same case for horizontal centering: if an absolutely positioned element has any value for left, width and right other than auto, then setting the left and right margin to auto will center the element horizontally.

That means we don’t need flexbox layout to center an absolutely positioned element with a known height and width. We just have to make sure that we give some value to top, right, bottom and left other than auto. So, we will use 0:

.core-inner { position: absolute; width: 70px; height: 70px; top: 0; right: 0; bottom: 0; left: 0; margin: auto; border-radius: 50%; border: 5px solid #1b4e5f; background-color: #fff; }

We do not want to repeat these five lines for all the concentric circles we are going to have, so let’s create a separate class for this. We also don’t want to define border-radius: 50%; for all the divs that we want to display as circles, so we will create a class for that too:

.circle { border-radius: 50%; } .abs-center { position: absolute; top: 0; right: 0; bottom: 0; left: 0; margin: auto; } .core-inner { width: 70px; height: 70px; border: 5px solid #1b4e5f; background-color: #fff; }

Also, add these new classes to out .core-inner element:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- the smallest circle --> <div class="core-inner circle abs-center"></div> </div> </div>

Okay, our concentric circle is centered. Let’s make it glow.

But CSS doesn’t have any "glow" property.

Don’t worry, we have the box-shadow property. Instead of giving the shadow a dark color, we will give it a bright color to make the shadow look like glow. Pretty clever, isn’t it? &#x1f609;

Let’s do this:

.core-inner { width: 70px; height: 70px; border: 5px solid #1b4e5f; background-color: #fff; box-shadow: 0px 0px 7px 5px #52fefe; }

Let’s take a break and understand the syntax of box-shadow first because we will be using it a lot. Here are what those values for box-shadow mean in that order:

  • x-offset: how much we want to push the shadow on the right side (x-axis). Negative values will push the shadow to the left side.
  • y-offset: how much we want to push the shadow up or down (y-axis).
  • blur-radius: how blurry we want our shadow to be.
  • spread-radius: how much we want our shadow to spread.
  • color: color of the shadow.

Play with these values a bit to see their effects in real time.

In real life, shadows don’t drop only outside of an object. Shadows drop upon the objects too. Imagine a pit dug by a dog, it will have a shadow inside it, right?

We can give a shadow inside an element using the inset keyword in the box-sizing property. To give an element both, outside and inside shadow, we simply separate them with a comma. Let’s do this to get an outside and inside glow to our reactor’s inner core:

.core-inner { width: 70px; height: 70px; border: 5px solid #1B4e5f; background-color: #fff; box-shadow: 0px 0px 7px 5px #52fefe, 0px 0px 10px 10px #52fefe inset; }

Now it’s starting to look sci-fi!

Let’s create one more circle on top. We want the inner circle to display on top of the other circles, so we will add new circle divs *above* the inner-circle in code:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- the second circle --> <div class="core-outer circle abs-center"></div> <!-- the smallest circle --> <div class="core-inner circle abs-center"></div> </div> </div>

The elements down in the code, are displayed above on the screen. If we put the core-outer below the core-inner in the code, then core-inner won’t be visible, because core-outer will cover it.

Let’s give style to outer-code. The outer core will be a little bigger than the inner core and we will give an outer and inner glow to core-outer too:

.core-outer { width: 120px; height: 120px; border: 1px solid #52fefe; background-color: #fff; box-shadow: 0px 0px 2px 1px #52fefe, 0px 0px 10px 5px #52fefe inset; }

I want you to do one thing: look at the shadows (glow) and try to identify which one is of which circle. There are four shadows and two circles (until now).

To finish designing the core, we will need one more circle that will wrap the inner and outer circles:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- the third circle --> <div class="core-wrapper circle abs-center"></div> <!-- the second circle --> <div class="core-outer circle abs-center"></div> <!-- the smallest circle --> <div class="core-inner circle abs-center"></div> </div> </div>

This one will be a little bigger, and will again have same shadows, we will use a dark background for core-wrapper:

.core-wrapper { width: 180px; height: 180px; background-color: #073c4b; box-shadow: 0px 0px 5px 4px #52fefe, 0px 0px 6px 2px #52fefe inset; } Creating Reactor Coils and Rotating with CSS3 Transforms

We have the core of the reactor, now we need a tunnel around the core. Actually, we can create an illusion of a round tunnel by drawing just one more circle little bigger than the core-wrapper. Let’s do it:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- the largest circle --> <div class="tunnel circle abs-center"></div> <!-- the third circle --> <div class="core-wrapper circle abs-center"></div> <!-- the second circle --> <div class="core-outer circle abs-center"></div> <!-- the smallest circle --> <div class="core-inner circle abs-center"></div> </div> </div>

...a little wider and add same glow to the tunnel:

.tunnel { width: 220px; height: 220px; background-color: #fff; box-shadow: 0px 0px 5px 1px #52fefe, 0px 0px 5px 4px #52fefe inset; }

Our tunnel is ready.

Make sure you do not just copy paste the code. Have a look at the glows of the circles and identify which glow is of which circle, whether it is outside glow or inset glow.

Now, we need eight coils on this tunnel. The coils are simple rectangles, but the major challenge is that we need the coils to run along the round path of the tunnel; not in straight line.

One way to do this would be to create eight small rectangles, shift their center to the center of the reactor, and rotate each coil by an increasing angle (in multiples of 45deg).

Let’s not complicate it and make one rectangle coil at a time:

<div class="fullpage-wrapper"> <div class="reactor-container"> <div class="tunnel circle abs-center"></div> <div class="core-wrapper circle abs-center"></div> <div class="core-outer circle abs-center"></div> <div class="core-inner circle abs-center"></div> <div class="coil-1"></div> </div> </div> .coil-1 { position: absolute; width: 30px; height: 26px; background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; }

Now, we want to place this coil in the center at top of the tunnel. Like this:

Our reactor-container is 300px x 300px, so the center is at 150px from top and left. The tunnel is 220px wide, so its radius will be 110px. This gives us the top offset of the coil: 150px - 110px.

We can keep left of the coil to 150px, but since our coil is 30px wide, it will shift the middle of the coil by 15px to right, that’s why we need to subtract 15px from 150px to get the left offset of the coil.

We can either calculate these ourselves and put the value, or we can use the CSS calc() function. Let’s use the CSS calc() function to calculate the top and left properties of the coil:

.coil-1 { position: absolute; width: 30px; height: 20px; top: calc(50% - 110px); left: calc(50% - 15px); background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; }

As you can see, the calc() function takes a mathematical expression as its argument and solves it.

Now we need eight such coils but they must lie on the tunnel. To do that, as discussed, we can simply place the eight coils at this same place, then transform their origin to the center of the reactor, and rotate each coil by an increment of 45 degrees.

We need to update the coil’s origin because by default it is set to the center of the coil; we want it at center of the reactor:

We will use transform-origin property to set the origin of the coil:

.coil-1 { position: absolute; width: 30px; height: 20px; top: calc(50% - 110px); left: calc(50% - 15px); transform-origin: 15px 110px; background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; }

The first value, 15px, in transform-origin is the x-offset (horizontal distance) from the top-left corner of the element, and the second value, 110px, is the y-offset (vertical distance) from the top-left corner of the element.

The coil’s origin is now at the center of the reactor, let’s rotate it by 45 degrees using the CSS3 transform property and see what happens:

.coil-1 { position: absolute; width: 30px; height: 20px; top: calc(50% - 110px); left: calc(50% - 15px); transform-origin: 15px 110px; transform: rotate(45deg); background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; }

Great! That’s exactly what we want.

Before creating all the eight coils, let’s create a coil container div that will contain all the eight coils:

<div class="fullpage-wrapper"> <div class="reactor-container"> <div class="tunnel circle abs-center"></div> <div class="core-wrapper circle abs-center"></div> <div class="core-outer circle abs-center"></div> <div class="core-inner circle abs-center"></div> <!-- the coil container --> <div class="coil-container"> <div class="coil coil-1"></div> </div> </div> </div>

You will notice we also added a class "coil" to the "coil-1" element. We will keep all the common styles for coils in the "coil" class, and the individual coil element classes will only have their angle of rotation:

.coil-container { position: relative; width: 100%; height: 100%; } .coil { position: absolute; width: 30px; height: 20px; top: calc(50% - 110px); left: calc(50% - 15px); transform-origin: 15px 110px; background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; } .coil-1 { transform: rotate(45deg); }

The output will remain same.

Now, let’s make all the eight coils inside .coil-container:

<div class="fullpage-wrapper"> <div class="reactor-container"> <div class="tunnel circle abs-center"></div> <div class="core-wrapper circle abs-center"></div> <div class="core-outer circle abs-center"></div> <div class="core-inner circle abs-center"></div> <!-- the coil container --> <div class="coil-container"> <div class="coil coil-1"></div> <div class="coil coil-2"></div> <div class="coil coil-3"></div> <div class="coil coil-4"></div> <div class="coil coil-5"></div> <div class="coil coil-6"></div> <div class="coil coil-7"></div> <div class="coil coil-8"></div> </div> </div> </div>

...and give different rotations to all the coils (in increment of 45 degrees):

.coil { position: absolute; width: 30px; height: 20px; top: calc(50% - 110px); left: calc(50% - 15px); transform-origin: 15px 110px; background-color: #073c4b; box-shadow: 0px 0px 5px #52fefe inset; } .coil-1 { transform: rotate(0deg); } .coil-2 { transform: rotate(45deg); } .coil-3 { transform: rotate(90deg); } .coil-4 { transform: rotate(135deg); } .coil-5 { transform: rotate(180deg); } .coil-6 { transform: rotate(225deg); } .coil-7 { transform: rotate(270deg); } .coil-8 { transform: rotate(315deg); }

Our reactor is almost ready.

Animating the Coils With CSS3 Animations

In Iron Man’s Arc reactor, the coils don’t move but they will in our reactor. We will animate the coils to rotate along the tunnel and will use CSS3 animations for this—no JavaScript.

To create an animation, you need to know the initial and final states of the object you are going to animate. We define these initial and final states in CSS by using @keyframes at-rule:

@keyframes reactor-anim { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }

We want the element to be at 0 degrees and animate it until it reaches 360 degrees. And we named this animation as "reactor-anim."

The element we want to animate is .coil-contailer. Notice, we didn’t define which object to animate yet, we have only defined the initial and the final state and name of the animation.

We need to link the element to the animation in order to take effect. We do it by using animation-name property on .coil-container:

.coil-container { position: relative; width: 100%; height: 100%; animation-name: reactor-anim; animation-duration: 3s; }

Notice, we also gave the duration of animation using animation-duration property. This defines how much time it should take to go from the “from” state to the “to” state defined using the @keyframes at-rule.

See the Pen Arc-Reactor-Ease-In by Kunal Sarkar (@supersarkar) on CodePen.

We need to change two things here: we want the animation to go on infinitely and we want a linear animation. You can see the animation is slow at the beginning, then fast, then again slow at the end—this behavior is defined by the timing function of an animation.

Let’s make these changes:

.coil-container { position: relative; width: 100%; height: 100%; animation-name: reactor-anim; animation-duration: 3s; animation-iteration-count: infinite; animation-timing-function: linear; }

We used animation-iteration-count property to set the animation to infinite, and animation-timing-function to make the animation linear, the default value of animation-timing-function is ease.

See the Pen Arc-Reactor-Linear-Infinite by Kunal Sarkar (@supersarkar) on CodePen.

We can combine all of these animation properties...

animation-name: reactor-anim; animation-duration: 3s; animation-iteration-count: infinite; animation-timing-function: linear;

...into one shorthand property like this:

animation: 3s infinite linear reactor-anim; Final Touches to the Reactor Container

Our reactor is ready, now let’s make some final changes to the .reactor-container. First, we will need one dark circle behind the reactor:

<div class="fullpage-wrapper"> <div class="reactor-container"> <!-- dark circle behind the reactor --> <div class="reactor-container-inner circle abs-center"></div> <div class="tunnel circle abs-center"></div> <div class="core-wrapper circle abs-center"></div> <div class="core-outer circle abs-center"></div> <div class="core-inner circle abs-center"></div> <div class="coil-container"> <div class="coil coil-1"></div> <div class="coil coil-2"></div> <div class="coil coil-3"></div> <div class="coil coil-4"></div> <div class="coil coil-5"></div> <div class="coil coil-6"></div> <div class="coil coil-7"></div> <div class="coil coil-8"></div> </div> </div> </div>

Let’s give a dark background and add some glow to it:

.reactor-container-inner { height: 238px; width: 238px; background-color: rgb(22, 26, 27);; box-shadow: 0px 0px 4px 1px #52fefe; }

See the Pen Arc-Reactor-Semi-Final by Kunal Sarkar (@supersarkar) on CodePen.

See how the dark background and the glow creates an emboss effect?

Next, let’s make the .rotator-container round and give it some shadow and border, then we are done:

.reactor-container { width: 300px; height: 300px; margin: auto; border: 1px dashed #888; position: relative; border-radius: 50%; background-color: #384c50; border: 1px solid rgb(18, 20, 20); box-shadow: 0px 0px 32px 8px rgb(18, 20, 20), 0px 0px 4px 1px rgb(18, 20, 20) inset; }

See the Pen Iron Man's Arc Reactor by Kunal Sarkar (@supersarkar) on CodePen.

Cheers! Our Arc Reactor is ready and even with a little animation as an added bonus. To level this up, we could explore using custom properties to create reusable variables for our color and number values for easier maintenance. Similarly, we could look into using a preprocessor—like Sass, Less or PostCSS—to write functions that do the mathematical lifting for us. Would love to see examples like that in the comments!

The post Iron Man’s Arc Reactor Using CSS3 Transforms and Animations appeared first on CSS-Tricks.

w descriptors and sizes: Under the hood

Css Tricks - Sun, 04/01/2018 - 3:23am

Eric Portis digs into how the browser decides which image to downloads when you give it <img srcset="" sizes"">. Notably, a browser can do whatever it wants:

Intentionally un-specified behavior lets browsers provide innovative answers to an open-ended question.

Still, calculations happens based on what you give it and you can still do a good job with that part.

The very weirdest part about all this is that the sizes attribute can alter an images "natural width", which can lead to unexpected upscaling, a thing we're trained to loathe. If you're in that situation, you can either...

  • use an inline width attribute
  • set an inline style with a max-width
  • embrace the fact you might experience occassinal upscaling

Direct Link to ArticlePermalink

The post w descriptors and sizes: Under the hood appeared first on CSS-Tricks.

A DevTools for Designers

Css Tricks - Sat, 03/31/2018 - 3:39am

There has long been an unfortunate disconnect between visual design for the web and web design and development. We're over here designing pictures of websites, not websites - so the sentiment goes.

A.J. Kandy puts a point on all this. We're seeing a proliferation of design tools these days, all with their own leaps forward. Yet...

But, critically, the majority of them aren’t web-centric. None really integrate with a modern web development workflow, not without converters or plugins anyway; and their output is not websites, but clickable simulations of websites.

Still, these prototypes are, inevitably, one-way artifacts that have to be first analyzed by developers, then recreated in code.

That's just a part of what A.J. has to say, so I'd encourage you to read the whole thing.

Do y'all get Clearletter, the Clearleft newsletter? It's a good one. They made some connections here to nearly a decade of similar thinking:

I suspect the reason that nobody has knocked a solution out of the park is that it's a really hard problem to solve. There might not be a solution that is universally loved across lines. Like A.J., I hope it happens in the browser.

Direct Link to ArticlePermalink

The post A DevTools for Designers appeared first on CSS-Tricks.

Tracking Uncertainty of Work

Css Tricks - Fri, 03/30/2018 - 9:24am

Ryan Singer writes about project and time management issues that I’ve been experiencing lately. He describes two states of every project: uncertainty and certainty, or “figuring things out” and “making it happen.”

Ryan describes it like this:

Work is like a hill with two sides. There's an uphill phase of figuring out what to do and how to approach the problem. That’s the climb. After you reach the top, there aren’t anybody [sic] ruinous unknowns. You can see down to the other side and finish executing. It's straightforward to estimate and finish the work from that point.

As far as I see it, the hardest thing about the first half of every project is making sure that everyone on a team is communicating constantly as tiny design decisions can have enormous, cascading effects on an engineer. I think that’s something I’ve always struggled with since I just want to get to the "making it happen" part as soon as humanly possible. It also goes back to something Geoff wrote a little while back about setting good expectations before and during the project process.

Direct Link to ArticlePermalink

The post Tracking Uncertainty of Work appeared first on CSS-Tricks.

New on Typekit: Fresh faces for spring 2018

Nice Web Type - Fri, 03/30/2018 - 7:47am

It’s been a whirlwind month! We’ve added new foundry partners we’re excited to share with you, boosted our offering for folks on free plans, and there’s more than ever to explore in our Marketplace.

No matter what plan you’re on, there’s something for you in this month’s roundup of new type.

New in the Marketplace

Gretel Script is a three-style type family packed with potential — thanks especially to the caps style, which is ideal for working in text that needs to be a little more clear without being a harsh departure from the lively flow of the Grande and Piccolo styles. Designed by Michael Hochleitner, Christoph Schütz, Simon Liesinger, and Franziska Weitgruber from Typejockeys, Gretel is based on the calligraphy of Natascha Safarik.

You’ll also find more new type from Typejockeys in the subscription library: Freude, Henriette Regular and Compressed, and Ingeborg Block and Striped.

Two new foundries are joining our library from Type Network, and you’ll find sixteen additional families from Type Network foundries in Marketplace this month. Guyot is the newest release from Retype, a small foundry established in 2007 by Ramiro Espinoza and Paula Mastrangelo in The Hague, Netherlands. In designing Guyot, Espinoza took inspiration from typefaces attributed to French punchcutter François Guyot, who worked in the early 16th century. Medusa, also by Espinoza, is a fantastic sprawling script intended to embrace the wild ornamentation of formal English handwriting as it was practiced in the mid-19th century.

Ivy Foundry‘s Jan Maack designed Swing King in collaboration with Danish illustrator Erik Sørensen, and the typeface includes unique signs and symbols that accentuate the lighthearted feel of the sans-serif. If that’s a little more freewheeling than you need, Ivy Style Sans is a bit more subdued — and also check out Ivy Style TW for a unique “typewriter” style that feels great to write in.

Other Type Network partners with new offerings in the Marketplace this month include Lipton Letter Design, Newlyn, and TYPETR.

New in the subscription library

We’re delighted to welcome Debi Sementelli to Typekit this month, whose playful style shines through in each of the three script families she’s added to our subscription library. Dom Loves Mary is a neat one to try out when you’re aiming for an elegant look, as it comes with an all-caps text style that can thoughtfully balance the script when used in combination.

Designer Ryoichi Tsunekawa added 31 of his Dharma Type families to our library earlier in March, which is a lot of fonts seeing as most families include multiple styles (Rama Slab includes 18!).

Piepie was an immediate hit on the team; we even worked it into an Instagram compilation on Pi Day. You may recognize Bebas Neue from the Dharma Type collection as well — it’s a popular standby for clean, bold headings.

Designed by Morten Rostgaard Olsen, København from Fontpartners takes inspiration from the Danish capital city — particularly in the Pictos style featuring arrows, ornaments, and several landmarks. We’ve added København Sans, Stencil, and Sans Stencil too — a total of 20 styles altogether.

Brian Willson at Three Islands Press specializes in historic type that seems especially well-suited for antique maps and correspondence. The aptly-named Geographica is modeled after the handwriting of an 18th-century cartographer. It includes plenty of cartographic ornaments, too! All styles are available for purchase in Marketplace, and we’ve added the Regular, Italic, and Hand Regular styles to the subscription library. Look for Professor and Viktorie in the library, too.

New for all plans

We’ve added around 150 open-source fonts from Google to our Limited Library, including popular picks like Oswald and, for Devanagari support, Kadwa.

And for even more global script support, we’ve added 12 fonts from 9 different families from Swathanthra Malayalam Computing — a huge boost for Malayalam support on Typekit.

So many! But which fonts do I have access to?

Not sure what plan you’re on? The fastest way to check is to visit your Account page on Typekit when you’re logged in with your Adobe ID (the same one you use for your Creative Cloud sign-in).

When you visit the Browse page (which is where you’ll end up most of the time anyway when you’re logged in), you’ll see a menu bar near the top, just under the Search field.

If you’re logged in and see a “My Library” tab here, these are the fonts included with your current plan. There’s no extra charge for these — go ahead and use them!

  • All Families — Yup, this is all the fonts we have. Make sure you have water and someone knows where you’re going before you dive in here.
  • Full Library — These fonts are included with most paid Creative Cloud subscriptions (exceptions include things like the Photography plan) and with any standalone Typekit plan.
  • Limited Library — You can use these fonts without a paid plan! You’ll need an Adobe ID if you want to use them on your computer, but that’s it. Great way to get a feel for how Typekit works if you aren’t ready to commit.
  • Marketplace — You don’t need a subscription plan, but you do need to pay. There’s one-of-a-kind stuff here you’d otherwise have to contact a type foundry directly to get, and once you purchase a font, you’ll have permanent access to it.

Why pay for type? Well of course, it’s up to you whether you do. Some fonts are free, and it’s usually because their creation was heavily subsidized by a company like, well, Adobe. Or Google. Plenty of great type innovation happens on teams like these, but there are a lot of type designers who work outside of these big companies. Unless they’re personally motivated (and probably financially backed) to make their work open-source, selling the fonts they design is how they make their living.

In any case, there’s a lot of type to choose from out there, and we’re excited to see what you do with it. Let us know what you think!

Vue Design System

Css Tricks - Fri, 03/30/2018 - 3:51am

We talk a lot about Vue around here, including some practical applications of it, but haven't gotten deep into designing for it. In this post, Viljami Salminen describes his Vue design process and the thinking that led him to build the Vue Design System:

A design system can help establish a common vocabulary between everyone in an organization and ease the collabo­ration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past...

Viljami lists Design Principles, Tokens, Elements, Patterns, and Templates as the way in which he structures a system and I think it’s a pretty interesting approach and a parallel to Lucas Lemonnier's post on creating design systems in Sketch, using Atomic Design as the structure. I particularly like how Viljami fits everything together in the example style guide that’s provided.

Direct Link to ArticlePermalink

The post Vue Design System appeared first on CSS-Tricks.

Solved With CSS! Colorizing SVG Backgrounds

Css Tricks - Fri, 03/30/2018 - 3:41am

CSS is getting increasingly powerful, and with features like CSS grid and custom properties (also known as CSS variables), we’re seeing some really creative solutions emerging. The possibilities are still being explored on what CSS can do to make writing UI’s simpler, and that’s exciting!

One of those is now one of my favorite CSS features: filters. Let’s look at how we can use filters to solve a problem you may have encountered when working with SVG as a background image on an element.

CSS Filters

First, let’s start by with an overview of filters. They include the following functions:

  • blur()
  • brightness()
  • contrast()
  • drop-shadow()
  • grayscale()
  • hue-rotate()
  • invert()
  • opacity()
  • saturate()
  • sepia()

These effects can also be achieved with SVG filters or WebGL shaders, but CSS filters are the easiest way to implement basic transformations in the most browser-efficient manner. Because they are shortcuts of SVG filter effects, you can also use filter: url() and specify a filter effect ID onto any element. If you want to play around with custom filters, I recommend checking out

The Problem: Editing SVG Backgrounds

I love using the SVG (scalable vector graphics) format for web design. SVG is a great image format for the web, and since it’s based on code, it allows for high-quality responsive and interactive content. When you inject SVG onto the page, you have access to each of its internal elements and their properties, allowing you to animate them, update values (such as color), and dynamically inject additional information. SVG is also a great icon format, especially instead of icon fonts, and in smaller UI elements due to its high quality (think: retina screens) and small image size (think: performance).

I find that often, when SVG is used for these smaller elements, or as a large area of illustration, it’s included as a background image for simplicity. The drawback to this is that the SVG is no longer under your control as a developer. You can’t adjust individual properties, like fill color, of an SVG background because it is treated just like any image. This color conundrum can be solved with CSS! Filters to the rescue!

Adjusting Brightness

The first time I discovered the SVG background challenge was when I was working on a website that had white SVG icons for social share icons that lived on a background determined to match that application. When these icons were moved onto a white background, they were no longer visible. Instead of creating a new icon, or changing the markup to inject inline SVG, you can use filter: brightness().

With the brightness filter, any value greater than 1 makes the element brighter, and any value less than 1 makes it darker. So, we can make those light SVG’s dark, and vice versa!

What I did above was create a dark class with filter: brightness(0.1). You can also do the opposite for darker icons. You can lighten icons by creating a light class with something like filter: brightness(100) or whatever is suitable to your needs.

Icons with a fill color of #000, or rgb(0,0,0) will not brighten. You need to have a value greater than 0 in any of the rgb channels. fill: rgb(1,1,1) works great with a high brightness value such as brightness(1000), but even brightness(1000) will not work on pure black. This is not an issue with light colors and white.

Adjusting Color

We’ve now seen how to adjust light and dark values with a brightness() filter, but that doesn’t always get us the desired effect. What if we want to inject some color into those icons? With CSS filters, we can do that. One little hack is to use the sepia filter along with hue-rotate, brightness, and saturation to create any color we want.

From white, you can use the following mixtures to get the navy, blue, and pink colors above:

.colorize-pink { filter: brightness(0.5) sepia(1) hue-rotate(-70deg) saturate(5); } .colorize-navy { filter: brightness(0.2) sepia(1) hue-rotate(180deg) saturate(5); } .colorize-blue { filter: brightness(0.5) sepia(1) hue-rotate(140deg) saturate(6); }

The world is your oyster here. SVG is just one use case for multiple filters. You can apply this to any media type—images, gifs, video, iframes, etc., and support is pretty good, too:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

DesktopChromeOperaFirefoxIEEdgeSafari18*15*35No176*Mobile / TabletiOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox6.0-6.1*37*No4.4*6457

One final note here is to remember your user! Filters will not work in Internet Explorer, so please send a visible image to all of your users (i.e. don’t use a white SVG with an applied filter on a white background, because your IE users will not see anything). Also, remember to use alternative text for icon accessibility, and you’ll be golden to use this technique in your own applications!

The post Solved With CSS! Colorizing SVG Backgrounds appeared first on CSS-Tricks.

Focusing on Focus Styles

Css Tricks - Thu, 03/29/2018 - 7:14am

Not everyone uses a mouse to browse the internet. If you’re reading this post on a smartphone, this is obvious! What’s also worth pointing out is that there are other forms of input that people use to get things done. With these forms of input comes the need for focus styles.


People are complicated. We don’t necessarily perform the same behaviors consistently, nor do we always make decisions that make sense from an outsider’s perspective. Sometimes we even do something just to… do something. We get bored easily: tinkering, poking, and prodding things to customize them to better suit our needs, regardless of their original intent.

People are also mortal. We can get sick and injured. Sometimes both at once. Sometimes it’s for a little while, sometimes it’s permanent. Regardless, it means that sometimes we’re unable to do things we want or need to do in the way we’re used to.

People also live in the world. Sometimes we’re put into an environment where external factors conspire to prevent us from doing something the way that we’re accustomed to doing it. Ever been stuck at your parents’ house during the holidays and had to use their ancient-yet-still-serviceable desktop computer? It’s like that.


Both mouse and touch input provide an indicator for interaction. For touch, it is obvious: Your finger acts as the bridge that connects your mind to the item on the screen it wants to activate. For mice, a cursor serves as a proxy for your finger.

However, these aren’t the only forms of input available to us. Keyboards are ubiquitous and can do just about anything a mouse or touch input can accomplish, provided you know all the right keys to press in the right order. Sometimes it’s even easier and faster than using a mouse!

Think about the last time you were using Cut, Copy, Paste, and Save functionality. Maybe it was the last time you were working on a spreadsheet? Were you switching between mouse and keyboard input to get things done as efficiently as possible? You probably didn’t give that behavior a second thought, but it’s a great example of switching input on the fly to best accomplish a goal. Heck, maybe you even took some "me time" during this thankless task to poke the Like button on Facebook on your smartphone.

If you have trouble using your hands, other options are available: Wands, sticks, switches, sip and puff devices, voice recognition, and eye tracking technology can all create input in a digital system. These devices will identify a content area and activate it. This is similar to how you can hit the tab key on a keyboard and the next cell in a spreadsheet will be highlighted, indicating that it has been moved to and is ready to be edited.

In this video, video editor and accessibility consultant Christopher Hills demonstrates the capabilities of Switch Control, software that helps people experiencing motor control impairments use hardware switches to operate their computing devices.

It’s worth pointing out that you could be relying on this technology one day, even if it’s only for a little bit. Maybe you broke both of your arms in an unfortunate mountain biking accident, and want to order some self-pity takeout while you recuperate. Maybe you’re driving and want to text your family safely. Or maybe you’ll just get old. It’s not difficult to think of other examples, it’s just not a concept people like to dwell on.

If it’s interactive, it needs a focus style

We can’t always know who is visiting our websites and web apps, why they’re visiting, what they’re going to do when they get there, what conditions they are experiencing, what emotions they’re feeling, or what input they may use. Analytics might provide some insight, but does not paint a full picture. It’d be foolish to have the tail wag the dog and optimize the entire experience based on this snapshot of limited information.

It’s also important to know that not everyone who uses assistive technology wants to be identified as an assistive technology user. Nor should they be forced to disclose this. Power users—people who leverage keyboard shortcuts, specialized software, and browser extensions—may appear to navigate like a user of assistive technology, yet may not be experiencing any disability conditions. Again, people are complicated!

What we can do is preemptively provide an experience that works for everyone, regardless of ability or circumstance.

Identify and activate :focus

With these alternate forms of input, how do we identify something to show it can be activated? Fortunately, CSS has this problem handled—we use the :focus and :active selectors.

The grammar is straightforward. Want to outline a link in orange when a user focuses on it? Here’s how to describe it:

a:focus { outline: 3px solid orange; }

This outline will appear when someone navigates to the link, be it by clicking or tapping, tabbing to it via keyboard input, or using switch input to highlight it.

A common misconception is that the focus style can only use the outline property. It’s worth noting that :focus is a selector like any other, meaning that it accepts the full range of CSS properties. I like to play with background color, underlining, and other techniques that don’t adjust the component’s current size, so as to not shift page layout when the selector is activated.

Then say we want to remove the link’s underline when activated to communicate a shift in state. Remember: links use underlines!

a:active { text-decoration: none; }

It’s important to make sure the state changes, from resting to focused to activated, are distinct. This means that each transition should be unique when compared to the component’s other states, allowing the user to understand that a change has occurred.

We also want to make sure these state changes don’t rely on color alone, to best accommodate people experiencing color blindness and/or low vision. Here’s how a color-only state change might look to a person with Deuteranopia, commonly known as Red-Green colorblindness:

I purposely removed the underline and the browser’s native focus ring from the link in the video to better illustrate the issue of discoverability. When trying to tab around the page to determine what is interactive, it isn’t immediately obvious that there is a link present. If colorblindness is also a factor, the state change when hovered won’t be apparent—this is even more apparent with the addition of cataracts.


:focus-within—a focus-related pseudo class selector with a very Zen-sounding name—can apply styling to a parent element when one of its children receives focus. The focus event bubbles out until it encounters a CSS rule asking it to apply its styling instructions.

A common use case for this selector would be to apply styling to an entire form when one of its input elements receives focus. In the example below, I’m scaling up the size of the entire form slightly, unless the user has expressed a desire for a reduced animation experience:

See the Pen :focus-within Demo by Eric Bailey (@ericwbailey) on CodePen.

The selector is still relatively new, so I’m sure we’ll get more clever applications as time goes on.


People also have opinions. Unfortunately, sometimes these opinions are uninformed. Outside the practice of accessibility there’s the prevalent notion that focus styles are "ugly" and many designers and developers remove them for the sake of perceived aesthetics. Sometimes they’re not even aware they’re propagating someone else’s opinion—many CSS resets include a blanket removal of focus styles and are incorporated as a foundational project dependency with no questions asked.

This decision excludes people. Websites and web apps aren’t close-cropped trophies to be displayed without context on a dribbble profile, nor are they static screenshots on a slick corporate sales deck. They exist to be read and acted upon, and there’s rules that help ensure that the largest possible amount of people can do exactly that.


The fact of the matter is that sometimes people will insist on removing focus styles, and have enough clout to force their cohorts to carry out their vision. This flies in the face of rules that stipulate that focus mechanisms must be visible for websites to be truly accessible. To get around this, we have the :focus-visible pseudo-selector.

:focus-visible pseudo-selector styling kicks in when the browser determines that a focus event occurred, and User Agent heuristics inform it that non-pointer input is being used. That’s a fancy way of saying it shows focus styling when activated via input via other than mouse cursor or finger tap.

The video of this CodePen demonstrates how different styling is applied based on the kind of input the link receives. When a link is hovered and clicked on via mouse input, its underline is removed and shifts down slightly. When tabbed to via keyboard input, :focus-visible applies a stark background color to the link instead.

Chromium has recently announced its intent to implement :focus-visible. Although browser support is currently extremely limited, a polyfill is available. Both it and :focus-within are in the Selectors Level 4 Editor’s Draft, and therefore likely to have native support in the major browsers sooner than later.

You may know :focus-visible by its other name, :-moz-focusring. This vendor prefixed pseudo-selector is Mozilla’s implementation of the idea, predating the :focus-visible proposal by seven years. Unlike other vendor prefixed CSS, we’re not going to have to worry about autoprefixing support! Firefox honors a :focus-visible declaration as well as :-moz-focusring, ensuring there will be parity for our selector names between the two browsers.

One step forward, one step back

Browser support is a bit of a rub—the web is more than just Chrome and Firefox. While the polyfill may provide support where there is none natively, it’s extra data to download, extra complexity to maintain, and extra fragility added to your payload.

There’s also the fact that devices are far less binary about their input types than they used to be. The Surface, Microsoft’s flagship computer, offers keyboard, trackpad, stylus, camera, voice, and touch capability out of the box. WebAIM’s 2017 Screen Reader Survey revealed that mobile devices may be augmented by keyboard input more than you may think. Heuristics are nice, but like analytics, may not paint a complete picture.

Another point to consider is that focus styles can be desirable for mouse users. Their presence is a clear and unambiguous indication of interactivity, which is a great affordance for people with low vision conditions, cognitive concerns, and people who are less technologically adept. Extraordinarily technologically adept people, ones who grok that screen readers and keyboard shortcuts are essentially Vim for a GUI, will want the focus state to be apparent as they use the keyboard to dance across the screen.

Part of building a robust, resilient web involves building a strong core experience that works in every browser. The vanilla :focus selector enjoys both wide and deep support to the degree that it’s a safe bet that even exotic browsers will honor it.

The world is full of things that some people may see as ugly, while others find them to be beautiful. Personally, I don’t see focus styles as an eyesore. As a designer, I think that it’s a foundational part of creating a mature design system. As a developer, describing state is just business as usual. As a person, I enjoy helping to keep the web open and accessible, as it was intended to be.

If you’d like to learn more about the subject, UX Designer Caitlin Geier has a great writeup on focus indicators.

The post Focusing on Focus Styles appeared first on CSS-Tricks.

The revolutionary project management tool

Css Tricks - Thu, 03/29/2018 - 7:13am

(This is a sponsored post.) is a project management tool your team will actually enjoy using. It makes it fun and easy for everyone to collaborate, focus on what's important, and get more done at work. It's a visual project management tool that’ll help you and your team collaborate and achieve more together.

With you can manage projects and tasks in a single board, move through the timeline visually and intuitively and communicate with your teammates in the context of each task. Plus, it connects with all the apps you already use and love like Dropbox, Google Drive, and Zapier.

Start free trial.

Direct Link to ArticlePermalink

The post The revolutionary project management tool appeared first on CSS-Tricks.

Quick Reminder that Details/Summary is the Easiest Way Ever to Make an Accordion

Css Tricks - Wed, 03/28/2018 - 8:18am

Gosh bless the <details> element. Toss some content inside it and you have an accessible expand-for-more interaction with just about zero work.

See the Pen Simple details. by Chris Coyier (@chriscoyier) on CodePen.

Toss a <summary> in there to customize what the expander text says.

See the Pen Multiple Details/Summary by Chris Coyier (@chriscoyier) on CodePen.

Works great for FAQs.

There is really no limit to how you can style them. If you don't like the default focus ring, you can remove that, but make sure to put some kind of styling back.

Here I've used a header element for each expandable section, which has a focus state that mimics other interactive elements on the page.

The only browser that doesn't support this are the Microsoft ones (and Opera Mini which makes sense—it doesn't really do interactive).

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

DesktopChromeOperaFirefoxIEEdgeSafari121549NoNo6Mobile / TabletiOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox6.0-6.137No46457

But even then, it's just like all the sections are opened, so it's not a huge deal:

Wanna style that default triangle? Strangely enough, the standard way to do that is through the list-style properties. But Blink-based browsers haven't caught up to that yet, so they have a proprietary way to do it. They can be combined though. Here's an example of replacing it with an image:

summary { list-style-image: url(right-arrow.svg); } summary::-webkit-details-marker { background: url(right-arrow.svg); color: transparent; }

See the Pen Custom Markers on Details/Summary by Chris Coyier (@chriscoyier) on CodePen.

Unfortunately, they don't turn, and there is no way to animate the default triangle either. One idea might be to target the :focus state and swap backgrounds:

See the Pen Custom Markers on Details/Summary by Geoff Graham (@geoffgraham) on CodePen.

But that seems to be limited to WebKit and Blink and, even then, the arrow will return once the item is out of focus even if the item is still expanded.

The post Quick Reminder that Details/Summary is the Easiest Way Ever to Make an Accordion appeared first on CSS-Tricks.

React’s New Context API Explained

Css Tricks - Wed, 03/28/2018 - 8:17am

In this video tutorial, Wes Bos looks into the new context API and the problem that it’s trying to solve:

React 16.3 has a new Context API which makes accessing data and functions anywhere in your application a snap. If you ever find yourself passing data down via props 4-5 levels deep, context might be what you are looking for.

Don’t forget about Neal Fennimore’s recent post on putting things into context. It covers the concept in great detail and provides some workarounds for the quirks you might encounter when using it.

Direct Link to ArticlePermalink

The post React’s New Context API Explained appeared first on CSS-Tricks.

On Paid Newsletters: An Interview With Adam Roberts of SitePoint’s Versioning

Css Tricks - Wed, 03/28/2018 - 3:09am

You don’t often think of email as something you pay to get. If anything, most people would pay to get less of it. Of course, there are always emails you like to get and opt into on purpose. We have a newsletter right here on CSS-Tricks that we really try to make worth reading. It’s free, like the vast majority of email newsletters. We hope it helps a bit with engagement and we make it worth doing financially by showing the occasional advertisement. It’s certainly not a full-time job.

I spoke with Adam Roberts who is trying to make it a full-time job by running SitePoint’s Versioning newsletter as a paid subscription. I don’t know much about this world, so I find it all pretty fascinating. I know Ann Friedman has a paid newsletter with a free variant. I know theSkimm is a free newsletter but has a paid membership that powers their app. I was told Bill Bishop made six figures on his first day going paid, which is wild. In the tech space, Ben Thompson’s Stratechery is a paid newsletter.

Let’s hear from Adam on how it’s doing it. I’ll ask questions as headers and the paragraph text is Adam.

So you're doing it! Making the transition from a free, advertising-supported newsletter to a paid, subscriber-based newsletter. There is a lot to dig into here. Is the motivation a more direct and honest relationship with your readers?

Yep, it's crazy! Versioning provides devs, designers and web people curated links aimed at making them more productive and up-to-date with the bleeding edge of their industry. I've done the newsletter for nearly four years and, up until now, it's been a thing I squeeze in for an hour or two during my day, as a break from my actual job (most recently, head of content for the site). Now, it's no longer being squeezed, and is my actual job! I can now focus entirely on making it something people find valuable. They'll know that everything I include is there because I think it'll make their lives, skills or knowledge better. I've always set a high standard for myself when it comes to what I include—never something I'm 50/50 on (unless it's an emerging tech) and I never include something because we have a deal or something. Now, this is an actual formal thing. Ads were always a means to an end, now we have a better means, and hopefully a better end!

Is it a straight cut? Anyone who doesn't subscribe for a fee will stop getting it and have no way to read it?

If you sign up as a paid member, you'll get the daily newsletter. You’ll also get periodic members-only updates, like deep dives on an emerging subject, always-updated posts on important subjects, and media guides. If you sign up to receive free updates, you'll get a weekly update plus other periodic free updates.

I'm sure there are financial concerns. Anyone in this position would be nervous that paid subscribers won't match what was coming in from advertisers before. Is that a concern here? How in-depth did you get trying to figure out the economics of it? Is there potential that it's even better business?

Given this is a SitePoint venture and not my own thing, we had to make sure it was worthwhile for subscribers and that the numbers were friendly! There's definitely potential this will work better in a financial sense, while also be being better for subscribers—we wouldn't be doing it otherwise!

Do you have a good sense of what your readers want from you? It seems to me Versioning is largely a link-dump, but with your hand-curation and light commentary. Did you come to that over time?

I have always had a fairly active reader base, with people dropping me a line via email or Twitter to thank me for something they liked. We also have the requisite creepy email analytics (e.g. opens and clicks), which help to spot trends and subjects to focus on or avoid. It's a challenge to cover a few different subject areas well (like front-end and back-end development, design, etc.) but I think most readers working in a particular niche in our industry find it helpful to know what everyone else is up to. The world also evolves quickly—the first edition covered a jQuery library, for example. That's not an area that's stayed in the forefront of the news since! Mind you, the first edition also had a Star Wars link, so maybe some things do stay the same.

I struggle with even knowing what I want from a newsletter. Most days, give me some personality. I want news but I want to know why I should care and I want an expert to tell me. Then other days, I hate to say it, but I want less talk and more links. Cool story about a goat, but I'm here for the performance links (or whatever). Are you a newsletter connoisseur yourself? Are you writing a newsletter you wanna read?

I think if I ran into Versioning in the wild, I'd want to subscribe to it. I'm working to try to get the content balance right—providing the right stuff for people, plus commentary that's enjoyable. The other day I had links to an article on understanding state in React (I think it was on some site called CCS-Tricks, am I spelling that right? &#x1f609;), an article on fake science gurus on Facebook, one on an Australian cyborg who tried to pay for a train with a chip in his hand, and the video for Warren G’s Regulate (an allusion to the likely response to the various Facebook crises).

I subscribe to so many newsletters, and they're all different. I think consistency in each newsletter helps. If I was to drop the format and post a long, detailed screed about one subject, that would not go over well. My aim is to include one link that every reader wants to click. Often, that's all you can handle as a reader, especially on mobile where the interface doesn't make collecting tabs easy. That's also why I include the destination domain in brackets next to every link—I don't want people to end up somewhere they're not expecting. Also, some sites (like the The New York Times, The New Yorker, and Wired) have limits on the number of free articles people can view. I don't want people to accidentally run out of freebies because of me—I want them to realize how much they value a site and support it.

Do paid newsletters replace the traditional blog or do you see them complementing one another? We’ve obviously been using our newsletter to support the blog and vice versa, but I’m curious if adding a paid layer changes that relationship.

The formats have different, complementary strengths, and so I don’t think the paid layer necessarily changes this. Newsletters are good at highlighting particularly important things, putting them in context, and maybe taking a long view of a certain issue. Sites (or blogs) are good at adding interactive elements and keeping content up-to-date and accurate as things change.

In our case, one of the things our email platform, Substack, allows us to do is send a particular edition out as both a newsletter and a post. This means a member can access it wherever is best for them. It also means I can do things like send out an initial newsletter outlining a particular topic, then update the online version with new content. I will use this to produce updated, canonical posts for a particular subject or technology. And these formats can be either free to all, or only available to paid members. There’s a lot you can do with this level of flexibility, I’m sure I’m only scratching the surface. The key is to produce something worthwhile for an audience and the format is secondary.

What is it about newsletters that seems to be clicking with people lately? If someone asked you, hey, I have a ton to say about this general topic, and so I'm thinking of either starting a blog or a newsletter, would you say newsletter? Any SEO concerns there?

There is a backlash against the algorithmic tide. Instead of opening a feed and hoping for good content, why not find someone you trust, and whose opinion and taste you find interesting and useful, and sign up to consistently receive content from them. You'll still get the "something new and cool" dopamine hit you would in a feed, but it'll be more consistent and reliable. And they're all separate entities; there's no "if you followed this publication, maybe you should follow this other one" thing. And if you stop enjoying them, you can just unsubscribe.

Newsletters are intimate. Your inbox is your personal space, where you step back from the tumult and take stock of the stuff that you've decided matters most to you. That's why spam and relentless, poorly-conceived marketing emails always feel like such a violation.

I think newsletters and podcasts are both growing in prominence for the same reasons. Both mediums reward consistency and reliability in format and topic, are built on personality, and have an intimate feel. Someone's either talking into your ears for hours every week, or writing to you in your private space.

Speaking of concerns, SEO is a tricky one. Algorithms are part of the discussion here again. SitePoint has a pretty decent search footprint, but new and niche publications aren't so lucky. I suspect there will be a mini-industry of newsletter curation services start to develop. I would actually love to be in that space.

Filter bubbles are another concern. Newsletters are another opportunity for people to only read the stuff they agree with. But it turns out algorithms and social networks aren't so good at stopping that either!

I was very, very, very sad to see the end of the Awl (and the Hairpin). That was a site that was chock-full of amazing content that was not targeted to appeal to Facebook and such, and as a result, it ultimately wasn't sustainable. It kind of feels like such cases—plus the re-tooling of Facebook's feed away from publications and towards people, and the rise of newsletters—are all related. It's reductive to say "newsletters are the new blogs," but it's probably not far off. I would 100% be telling someone to start a newsletter. Actually, I'd tell them to use Substack, but I would have to declare my bias!

Tech-wise, what tooling are you using to curate, create, and send here?

I love talking about this stuff! Uses This is one of my favorite sites. Honestly, it's pretty low-tech at the moment, just busy. I have a Pocket account with a #versioning tag, so that often gives me a dozen or so links at the start of the day, sourced from my internet meanderings through the evening. I subscribe to a million newsletters, both in my work and personal accounts, on a hopefully both diverse and relevant range of topics.

I subscribe to quite a few RSS feeds using Feedly, too. Nuzzel, which sends you a daily/weekly digest of the most-shared links among people you're following in Twitter and Facebook, is very useful here too. I have a personal Twitter/Nuzzel feed, plus one I've specifically set up for this purpose. Refind is another service trying to solve this problem. Its breadth and depth kind of give me a headache though. They've got a Nuzzel-like daily/weekly digest, a service for creating your own newsletters, a cryptocurrency—there's a lot.

I also have the requisite very big Tweetdeck set-up to grab other links that catch my eye. Oh, and Initab is a new Chrome tab extension you can populate with feeds from certain subreddits and other place. I've been playing around with psuedo-Tweetdeck-for-Reddit services too. And Spectrum is a new community service thing I found last week, looks like it could be a winner too. And I need to be more active in Facebook groups. Also, Slack!

So yeah, there's a lot. A bit of a combo of algorithms and people, hopefully I have the balance right. I also change newsletters, feeds, and other sources regularly, trying to find a better balance.

As for collecting and writing, it's actually fairly simple—I find something I like, copy the URL into a Markdown doc, then write a description. I deliberately use a web-based Markdown editor (currently Stackedit, though I have used Dillinger and Classeur in the past). Something web-based is good because I can easily tab to it without having to switch to a new app. Stackedit is good because you can paste the generated preview directly into Campaign Monitor and (now) Substack and have formatting and links sorted. I then have a Google Doc to collect links I've already shared, and to gauge the reception in the audience—I want to spot trends like a rising interest in micro-services.

Building emails is something we all sort of love and loathe as front-end developers. How did you approach your email design and did you learn anything from building it?

Yes, email design is hard! Fortunately for me, the content and approach I’ve adopted lends itself to a stripped-back design with very little going on. Versioning is just text and a few images, so it required practically zero design. Our use of Campaign Monitor and now Substack meant we could sidestep some of the template work. In general terms though, my advice would be:

  • Focus on the purpose and content of the newsletter, produce a template based on that. It’s more important to produce something compelling, promote it in the right places, gain an audience, and then keep it (and grow it) by making sure you’re consistent in your production.
  • If you can (via a survey or through whatever data your email platform offers) work out what devices and platforms your audience uses to access email. People read email in all sorts of obscure ways, but you can likely cover the main ones for your audience with relatively little effort.
  • Don’t forget the plaintext user! Make sure your URLs are short, your images have alt tags, you’re generally nice to those in your audience who are in this boat. Versioning, given the niche, has a high proportion of these.
  • If all else fails, work with an expert or use one of a plethora of tools and services to do the work for you. Substack has a stripped-back CMS, Campaign Monitor and MailChimp have built-in template builders, and there are plenty of other services you could use. The compatibility issues with email are legendary. You could instead spend your time on things like a distinctive logo and branding or a landing page that communicates your newsletter’s value.

Ultimately people will enjoy a simple newsletter full of content they love presented in a way they can absorb. The design shouldn’t tie you in knots!

Let’s open this up to readers. Are you into the idea of paid newsletters?

The post On Paid Newsletters: An Interview With Adam Roberts of SitePoint’s Versioning appeared first on CSS-Tricks.

Compressive Images Revisited

Css Tricks - Tue, 03/27/2018 - 7:50am

Tim Kadlec returns to the topic of how to make images on the web as performant as possible and looks at the technique called “Compressive Images” which is now not recommended for a bunch of reasons. Tim summarizes his point here:

By now the trade-off is pretty clear. Compressive images give us a reduced file size, but it greatly increases the memory footprint. Thanks to the standards that have been developed around responsive images, it’s a trade-off we no longer need to make.

If you’re interested in learning more then it’s hard not to recommend Jason Grigsby’s masterclass called Responsive Images 101, too.

Direct Link to ArticlePermalink

The post Compressive Images Revisited appeared first on CSS-Tricks.

Typespotting: Laundromat mural in the Mission

Nice Web Type - Tue, 03/27/2018 - 6:59am

Walking along 24th Street in the Mission District of San Francisco, I saw this type mural for the first time not long ago.

The laundromat has been there for years, but I’m less sure about their painted sign (maybe it was just touched up?), and “Protect the Sacred” was definitely new to me. In any case, I thought the whole thing was striking. There’s a homegrown charm to Mr. Burbujas and a definite Mission flavor, while the “Protect” work is something totally different but equally awesome.

I took closer shots of the sign from a less skewed angle, and tried both elements in our visual search feature to see what might be close in the Typekit library.

P22 Stanyan Bold, the very first result, sure did appear to be a close match to the sample text, but it seemed a little scratchier than I wanted; it seemed to be reflecting the texture of the sign more than the shape of the letters themselves. Many of the following results were similar to Garamond in style, definitely picking up on the prominent serifs.

Scrolling further down, the Duality family stood out to me; it seemed to have a little more clarity around the edges than Stanyan, but a similarly hand-drawn personality.

While the contrast between Aviano Black and the sample text does seem really close — as though drawn with the same pen, at nearly the same angle — the letter width is definitely not a match. Adorn Smooth Serif feels much closer in this sense, and I feel like the T is especially similar. I wish the O were a little narrower, though.

I shrank down the spacing considerably for Adorn Smooth here (BURBUJAS) in an attempt to get a slightly narrower feel to the text. I’m not all that experienced with 3D effects in type but had some fun playing around to see what I could do. I’m not sure this is ready for 24th Street, but as usual the visual search feature turned up type options I probably never would’ve thought to try out on my own.

Seen any neat type in the wild lately? If you snap a photo of it, try sending it through our visual search to see what’s similar in the Typekit library – and let us know what you find!

React Code Style Guide

Css Tricks - Tue, 03/27/2018 - 3:24am

I've been having the time of my life with React lately. But on my journey, I’ve had a hard time finding good code style guidelines to keep the mix of JSX and JS clean and readable. I've been coming up with my own style guides that I'd love to share. Maybe these will be useful to you and, of course, feel free to share similar guidelines in the comment thread below.

Rule #1: Destructure your props

One of my favorite ES6 features is destructuring. It makes assigning object properties to variables feel like much less of a chore. Let's take a look at an example.

Say we have a dog that we want to display as a div with a class named after its breed. Inside the div is a sentence that notes the dog's color and tells us if it's a good dog or bad dog.

class Dog extends Component { render () { return <div className={this.props.breed}>My {this.props.color} dog is {this.props.isGoodBoy ? "good" : "bad"}</div>; } }

That technically does everything we want, but it just seems like quite a big block of code for what really is only three variables and one HTML tag.

We can break it out by assigning all of the properties of props to local variables.

let breed = this.props.breed; let color = this.props.color; let isGoodBoy = this.props.isGoodBoy;

Using ES6, we can put it in one clean statement like this:

let { breed, color, isGoodBoy } = this.props;

To keep everything clean, we put our ternary operator (more on that later) in its own variable as well, and voila.

class Dog extends Component { render () { let { breed, color, isGoodBoy } = this.props; let identifier = isGoodBoy ? "good" : "bad"; return <div className={breed}>My {color} dog is {identifier}</div>; } }

Much easier to read.

Rule #2: One tag, one line

Now, we've all had that moment where we want to take our entire function and make it a mash of operators and tiny parameter names to make some uglified, superfast, unreadable utility function. However, when you're making a stateless Component in React, you can fairly easily do the same thing while remaining clean.

class Dog extends Component { render () { let { breed, color, goodOrBad } = this.props; return <div className={breed}>My {color} dog is {goodOrBad}</div>; } }


let Dog = (breed, color, goodOrBad) => <div className={breed}>My {color} dog is {goodOrBad}</div>;

If all you're doing is making a basic element and placing properties in an HTML tag, then don't worry about making such a big deal of all the functions and wrappers to get an entirely separate class going. One line of code will do.

You can even get creative with some ES6 spread functions if you pass an object for your properties. Using this.props.content will automatically put the string between the open and close tag.

let propertiesList = { className: "my-favorite-component", id: "myFav", content: "Hello world!" }; let SimpleDiv = props => <div {... props} />; let jsxVersion = <SimpleDiv props={propertiesList} />;

When to use the spread function:

  • No ternary operators required
  • Only passing HTML tag attributes and content
  • Can be used repeatedly

When not to use the spread function:

  • Dynamic properties
  • Array or object properties are required
  • A render that would require nested tags
Rule #3: The rule of 3's

If you have three or more properties, then put them on their own line both in the instance and in the render function.

This would be fine to have just one line of properties:

class GalleryImage extends Component { render () { let { imgSrc, title } = this.props; return ( <figure> <img src={imgSrc} alt={title} /> <figcaption> <p>Title: {title}</p> </figcaption> </figure> ); } }

But consider this:

class GalleryImage extends Component { render () { let { imgSrc, title, artist, clas, thumbnail, breakpoint } = this.props; return ( <figure className={clas}> <picture> <source media={`(min-width: ${breakpoint})`} srcset={imgSrc} /> <img src={thumbnail} alt={title} /> </picture> <figcaption> <p>Title: {title}</p> <p>Artist: {artist}</p> </figcaption> </figure> ); } }

Or the render:

<GalleryImage imgSrc="./src/img/vangogh2.jpg" title="Starry Night" artist="Van Gogh" clas="portrait" thumbnail="./src/img/thumb/vangogh2.gif" breakpoint={320} />

It can get to be too much of a codeblock to read. Drop each property to the next line for a clean, readable look:

let { imgSrc, title, artist, clas, thumbnail, breakpoint } = this.props;


<GalleryImage imgSrc="./src/img/vangogh2.jpg" title="Starry Night" artist="Van Gogh" clas="landscape" thumbnail="./src/img/thumb/vangogh2.gif" breakpoint={320} /> Rule #4: Too many properties?

Property management is tricky at any level, but with ES6 destructuring and React's state-based approach, there are quite a few ways to clean up the look of a lot of properties.

Let's say we're making a mapping application that has a list of saved addresses and a GPS coordinate for your current location.

The current user information of position and proximity to favorite address should be in the parent Component of App like this:

class App extends Component { constructor (props) { super(props); this.state = { userLat: 0, userLon: 0, isNearFavoriteAddress: false }; } }

So, when we make an address and we want it to note how close you are to the address, we're passing at least two properties from App.

In App render ():

<Address ... // Information about the address currentLat={this.state.userLat} currentLong={this.state.userLon} />

In the render function for Address Component:

render () { let { houseNumber, streetName, streetDirection, city, state, zip, lat, lon, currentLat, currentLon } = this.props; return ( ... ); }

Already, you can see how this is getting unwieldy. If we take the two sets of information and break them out into their own objects, it becomes much more manageable.

In our App constructor ():

this.state = { userPos: { lat: 0, lon: 0 }, isNearFavoriteAddress: false };

At some point before App render ():

let addressList = []; addressList.push({ houseNumber: "1234", streetName: "Street Rd", streetDirection: "N", city: "City", state: "ST", zip: "12345", lat: "019782309834", lon: "023845075757" });

In App render ():

<Address addressInfo={addressList[0]} userPos={this.state.userPos} />

In the render function for Address Component

render () { let { addressInfo, userPos } = this.props; let { houseNumber, streetName, streetDirection, city, state, zip, lat, lon } = addressInfo; return ( ... ); }

Much, much cleaner. React also has some great ways to ensure that object properties exist and are of a certain type using PropTypes that we don't normally have in JavaScript, which is just a great OOP thing anyway.

Rule #5: Dynamic renders - Mapping out arrays

Quite often in HTML, we're writing the same basic pieces of code over and over, just with a few key distinctions. This is why React was created in the first place. You make an object with properties that return a complex, dynamic HTML block, without having to write each part of it repeatedly.

JavaScript already has a great way to do lists of like information: arrays!

React uses the .map() function to lay out arrays in order, using one parameter from the arrays as a key.

render () { let pokemon = [ "Pikachu", "Squirtle", "Bulbasaur", "Charizard" ]; return ( <ul> { => <li key={name}>{name}</li>)} </ul> ); }

You can even use our handy-dandy spread functions to throw a whole list of parameters in by an object using Object.keys() (keeping in mind that we still need a key).

render () { let pokemon = { "Pikachu": { type: "Electric", level: 10 }, "Squirtle": { type: "Water", level: 10 }, "Bulbasaur": { type: "Grass", level: 10 }, "Charizard": { type: "Fire", level: 10 } }; return ( <ul> {Object.keys(pokemon).map(name => <Pokemon key={name} {... pokemon[name]} />)} </ul> ); } Rule #6: Dynamic renders - React ternary operators

In React, you can use operators to do a conditional render just like a variable declaration. In Rule #1, we looked at this for stating whether our dog was good or bad. It's not entirely necessary to create an entire line of code to decide a one-word difference in a sentence, but when it gets to be large code blocks, it's difficult to find those little ?'s and :'s.

class SearchResult extends Component { render () { let { results } = this.props; return ( <section className="search-results"> {results.length > 0 && => <Result key={index} {... results[index] />) } {results.length === 0 && <div className="no-results">No results</div> } </section> ); } }

Or, in true ternary fashion

class SearchResult extends Component { render () { let { results } = this.props; return ( <section className="search-results"> {results.length > 0 ? => <Result key={index} {... results[index] />) : <div className="no-results">No results</div> } </section> ); } }

Even with our tidy result mapping, you can see how the brackets are already nesting quite densely. Now, imagine if our render had more than just one line. It can pretty quickly get unreadable. Consider an alternative:

class SearchResult extends Component { render () { let { results } = this.props; let outputJSX; if (results.length > 0) { outputJSX = ( <Fragment> { => <Result key={index} {... results[index] />)} </Fragment> ); } else { outputJSX = <div className="no-results">No results</div>; } return <section className="search-results">{output}</section>; } }

Ultimately, the code length is about the same, but there is one key distinction: with the first example, we're rapidly switching back and forth between two different syntaxes, making visual parsing taxing and difficult, whereas the second is simply plain JavaScript with value assignments in one, consistent language and a one-line function return in another.

The rule of thumb in this situation is that if the JavaScript you're putting into your JSX object is more than two words (e.g., it should be done before the return call.

Wrap up

The combination of syntax can get messy, and these are the most obvious situations where I saw my code going off the rails. Here are the basic concepts that these all come from and can be applied to any situation that wasn’t covered here:

  • Use ES6 features. Seriously. There are a lot of fantastic features that can make your job easier, faster, and much less manual.
  • Only write JSX on the right side of an = or a return.
  • Sometimes you need JavaScript in your JSX. If your JavaScript doesn’t fit on one line (like a .map() function or ternary operator), then it should be done beforehand.
  • If your code starts looking like (<{`${()}`} />), then you’ve probably gone too far. Take the lowest level outside the current statement and do it before this one.

The post React Code Style Guide appeared first on CSS-Tricks.

A CSS Approach to Trap Focus Inside of an Element

Css Tricks - Tue, 03/27/2018 - 3:00am

I recently read this article by Keith Grant which introduced the newly arrived <dialog>. Excited by this new UI element, I immediately sat down to experiment with it to see how it can be used effectively as a modal?—?the most common use of it. While experimenting, I discovered a neat CSS trick on how to trap focus within the <dialog> element, a common accessibility requirement for modals, and a notoriously difficult one.

Disclaimer: The <dialog> demos in this article are tested on Chrome and Firefox browsers only. Safari has some weird issue where not all elements are focused while doing a normal keyboard navigation with Tab key!

What is focus trapping?

First, a quote from the W3C documentation regarding what should happen following a key press inside a dialog:


  • Moves focus to the next tab-able element inside the dialog.
  • If focus is on the last tab-able element inside the dialog, moves focus to the first tab-able element inside the dialog.

Shift + Tab

  • Moves focus to the previous tab-able element inside the dialog.
  • If focus is on the first tab-able element inside the dialog, moves focus to the last tab-able element inside the dialog.

To summarize, when inside a dialog, pressing Tab or Shift+Tab should cycle the focus within the dialog only—amongst the focusable elements inside the dialog.

This makes sense because when a dialog is open, a user is interacting only inside it and allowing the focus to escape outside the dialog would essentially be mixing contexts and possibly create a state where the user doesn’t know which element is in focus.

So, going back to the idea of a modal, our expectation would be that tabbing inside of the modal would only focus on elements inside of the modal. Anything outside of the context of the modal would be out of scope because the tab is only concerned with what is inside of it. This is what we mean by focus trapping.

An implementation with JavaScript

If we were to implement focus trapping inside a <dialog>, the most common approach would be to do the following when the dialog opens:

1. Grab all the focusable/tappable elements inside the dialog.
2. Listen for Tab and Shift+Tab keypresses and manually focus the next or previous element, respectively.
3. If the keypress happens on the first focusable element, then focus the last focusable element in the chain and vice versa.

This way, we create a loop on focus as the user presses Tab or Shift+Tab. See this W3C code snippet as an an example of how this might be approached with JavaScript. You’ll see it’s quite a bit of JavaScript.

Enter :focus-within

Back to my experiment with the new <dialog> element. When thinking about focus trapping, a CSS pseudo class (also very recent in browsers) immediately came to my mind?: :focus-within.

If you have not heard about that before, it represents an element that has received focus or contains an element that has received focus. So, for example, you have a <div> and inside of it is an input element. If you want to style that <div> when the contained input has focus, you can do it like so:

div:focus-within { border: 2px solid red; }

See the Pen :focus-within by Geoff Graham (@geoffgraham) on CodePen.

The CSS trick to focus trapping

Let’s exploit :focus-within and CSS transitions to implement a basic focus trap inside of a <dialog> element.

To summarise, here is how the trick works. When the focus is not within the dialog (and the dialog is open), we:

  1. trigger a CSS transition
  2. detect that transition completion in JavaScript
  3. focus the first element in the dialog

But, first let’s get set up. Here’s the basic dialog and opening functionality:

<button id="button">Open dialog</button> <dialog id="modal"> <form action=""> <label> <input type="text" /> Username </label> <label> <input type="password" /> Password </label> <input type="submit" value="Submit" /> </form> </dialog> button.onclick = () => { modal.showModal(); }

There we go. Clicking on the button should open our dialog. Just this much code required to make a basic working modal using the new <dialog> element!

See the Pen Dialog without focus trap by Kushagra Gour (@chinchang) on CodePen.

Note: As in the above example demo of dialog, you'll notice some extra polyfill code to make <dialog> work in browsers where it isn't supported.

If you opened the dialog in the example above and started tabbing several times, you may have already noticed the problem: the focus starts with elements in the dialog, but then leaves once the last element in the dialog has been passed.

This is the core of our trick. We somehow need to send the lost focus detected with :focus-within over to JavaScript so that we can send the focus back to the dialog. This is where CSS transitions come into play. A CSS transition is something that happens through CSS, but emits events in JavaScript too. In our case, we can trigger a transition on any property with a negligible (because it doesn't matter in our case) visual difference and listen for the transition completion in JavaScript.

Note that we need to trigger this transition when the dialog is open but doesn’t have focus inside it.

dialog { background-color: rgb(255, 255, 255); } dialog[open]:not(:focus-within) { background-color: rgb(255, 255, 254); transition: background-color 0.01s; }

Let’s see what that CSS is doing.

  1. We put a background-color of our choice on the dialog. This isn’t necessary, but ensures we have the same background color across browsers.
  2. The dialog[open]:not(:focus-within) selector applies when the dialog is open but doesn’t have focus on or inside it. This works because native <dialog> element puts an open attribute when it’s open.
  3. Inside this rule, we change the background-color by a minimum amount. This is the least change required to trigger a CSS animation and at the same time not causing any visual difference for the user (remember this is a dummy transition). Also, we set the transition property with a very small duration because we want it to finish as soon as possible and get detected in JavaScript.
A touch of JavaScript

Now, all we need to do is detect the end of our triggered CSS transition and focus back the first element inside the modal, like so:

modal.addEventListener('transitionend', (e) => { modal.querySelector('input').focus(); });

We attach a transitionend listener on the modal and inside the callback, we focus the first input inside the modal. Done!

See the Pen Dialog focus trapping with CSS by Kushagra Gour (@chinchang) on CodePen.


This is a quick experiment I did to create a working proof-of-concept of focus trapping with the :focus-within pseudo class. It has several limitations compared to dedicated JavaScript solutions to achieve this. Nevertheless, something is better than nothing!

Here are a couple of things this implementation lacks:

  1. According to W3C guidelines, the focus should cycle on the focusable element. But we are always focusing on the first input element. This is because without writing more JavaScript, we cannot know whether the focus was lost from the first or last element.
  2. We are always focusing back to the first input element. But there are many more focusable HTML elements that might be present before input or maybe there is not input element at all inside the modal. Again, full-fledged JavaScript solutions detect and maintain a list of all focusable elements and focus the right one.
Better (JavaScript) implementations of focus trapping
  1. As mentioned earlier, one working example is available inside the W3C documentation itself.
  2. Here is another implementation by Rodney Rehm that also listens for tab.
  3. Greg Kraus has a library that achieves this. His implementation maintains a list of selectors for all valid focusable elements.
  4. One more lightweight library to create accessible modals.

That is all for this experiment. If you liked this trick, you can follow me on Twitter where I share more articles and side projects of mine.

The post A CSS Approach to Trap Focus Inside of an Element appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.