Developer News

An Event Apart: Scenario-Driven Design Systems

LukeW - Sun, 04/01/2018 - 2:00pm

In her Scenario-Driven Design Systems presentation at An Event Apart in Seattle, Yesenia Perez-Cruz shared lessons learned building design systems for multiple brands/Web sites and how specific user-scenarios are key to making flexible solutions. Here's my notes from her talk:

  • Design systems have helped many organizations build better, more cohesive experiences faster. but what's really behind a design system? is it a set of components? a common language? or something more?
  • A good design system feels cohesive, unified, and connected. It achieves something.
  • Bad design systems fail when there's too much focus on elements and not enough focus on how common components work together to create an experience.
  • We need to start our design systems with user-scenarios, not with individual components.
Starting with Elements
  • Vox wanted a design systema nd common platform for their 8 brands and 350+ Web sites. They made a lot of assumptions in the beginning that didn't work. Primarily: a set of flexible, brand-agnostic modules with a theming system would give them the most range. Essentially, legos.
  • This approach was too focused on layout and the end result was that each of the sites felt too similar. Critical content and focus differences were missing. The end result did not not allow Vox to tell better stories faster, as it only defined common modules not ways to solve common user problems.
  • Vox learned they needed to start with something specific in order to develop a flexible system. You can’t start with individual components because successful design patterns don’t exist in a vacuum.
Starting with Purpose
  • The next iteration of Vox's design system started with people and content. What goals did the audience have? What range of content and tone needed to be supported? What was the editorial workflow of the people making content?
  • This requires user-scenarios driving design not hypothetical situations. We need to ground our design systems in tasks people and companies actually have not trying to account for "what if" ideas.
  • Instead of starting with an inventory of UI components, start with an inventory of core workflows/tasks, and then identify common patterns in these workflows. All patterns should solve a specific problem.
  • Identify core workflows and the patterns that need to support these workflows. Understand the role each pattern plays in a user’s journey. Define how the patterns work together to create a cohesive experience.
  • Thinking and organizing a design system in terms of workflows, makes it easier for teams to know which patterns to apply when faced with a user problem.
  • At Vox, a scenario-based design system allowed the team to turn 18 distinct templates into a unified structure. They identified common audience goals but supported variants driven by differences in content.
Supporting Variants
  • Variants can help components address specific user-scenarios by highlighting specific content that matters to audience goals. These content-specific components can be re-used across themes/brands.
  • Scenario-driven variations can help brands feel unique/deliberate vs. becoming too generic/unspecific.
  • Naming elements very specifically helps people agree on their function. This ensures each element supports the right level of customization & functionality.
  • How do we theme a design system? Brands need to support distinct visual designs that support the unique audience and content within a site.
  • When varying fonts across brands, you need a flexible type scale to ensure legibility across different font faces. Similarly, color variables can be used to manage different colors schemes across brands.
  • When should you support variations in your design system? Only add a layout if there’s a content need. Does it add value? Is it available to more than 3 brands? Is it a must-have for 1 brand?
  • When are variations in your design system a bad thing? Visual variation on components that serve the same function across brands and/or don’t do much to strengthen brand voice.
Finding a Balance
  • There's a constant push/pull between appropriate levels of consistency and customization. Finding the right middle ground is a constant process of iteration.
  • Successful design patterns don't exist in a vacuum. Instead of focusing on individual components, look at the ecosystem: the people, content, and complete design. Successful design systems solve specific problems and start with people & content.

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.

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 cssfilters.co.

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

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.

Input

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

: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.

Politics

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.

:focus-visible

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.)

monday.com 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 monday.com 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.

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>; } }

vs.

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;

and:

<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> {pokemon.map(name => <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 && results.map(index => <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 ? results.map(index => <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> {results.map(index => <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. object.property), 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:

Tab:

  • 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.

Limitations

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.

Sticky as a Local Fixed?

Css Tricks - Mon, 03/26/2018 - 3:13am

Lemme set the stage a bit here.

You have a website and, like most, it scrolls.

This website will have modals. You'll probably position: fixed the modal so that it's predictably positioned regardless of scrolling. It's possible the modal itself will scroll.

Notice the modal has a close button. We can position: absolute that in the upper-right corner, but if our modal scrolls, it's a problem.

We've lost the close button behind the scrolling.

Should be a job for more position: fixed, right? Not really, sadly, as there is no such thing as a local context for position: fixed.

Well... actually there kinda (weirdly) is. If the modal has any sort of CSS transform on it (and it might already if you center it using the ol' left: 50%; transform: translateX(-50%); trick) then the fixed position close button will come back home:

But... as the transform helped pull the close button back into place, you can see it behaves like position: absolute and not position: fixed. ¯\_(?)_/¯

There is a possibility here, though. The idea is that position: sticky is, in a sense, a locally scoped position: fixed. If we position the close button at the top: 0 anyway, it'll just stick there as the modal scrolls down.

I just thought this was an interesting possibility. Ultimately, to be honest, if I had modals I worried about scrolling, I'd probably have like a .modal-header container and a .modal-content container. The header would sit on top always and the container would be the thing that could scroll.

The post Sticky as a Local Fixed? appeared first on CSS-Tricks.

Why would I use a Webpack?

Css Tricks - Sat, 03/24/2018 - 1:45pm

Gonzalo García takes a crack at why webpack (not capitalized like npm) exists at all. No particular disagreements here, but here's my crack at it...

  • We use webpack because we need to import stuff from place;. This is a good pattern. We can use webpack to interpret those statements, as native support for them isn't what it needs to be yet, and it's not clear whether the native version will be smart for performance or not (probably not, at the scope of projects webpack is usually used for).
  • We use webpack because we know we need to concatenate and compress our JavaScript anyway, and managing load order isn't something you wanna handle manually.
  • We use webpack because of npm. Powerful features are a yarn or npm i away and so our projects are loaded with stuff to import.
  • We use webpack because we're sure it performs fancy magic that results in good performance-related things for our websites. We cross our fingers we have that right, and we've done our part right.
  • We use webpack because there is a hive mind in this industry and it leads to a lot of us hopping on the trains with the most people on them, and people are hanging out of the windows of the webpack train.

I'm very very (very) far from being a webpack expert, but I essentially get it, especially after the screencast Sean Larkin and I did right here, and I know enough my projects benefit from it.

Direct Link to ArticlePermalink

The post Why would I use a Webpack? appeared first on CSS-Tricks.

The spectrum of design roles in 2018

Css Tricks - Fri, 03/23/2018 - 12:45pm

Job titles is a regular topic around here. Occasionally heated, as job titles play a role in the hiring process (why are you asking me React questions for this UX design position role?). And complicated by the fact that there is no agreed-upon standards and the loads of people and companies who don't take them seriously (we just want people who do a good job, make your title whatever you want it to be). Complicated again when someone from the outside needs to look in.

Jasper Stephenson:

Recently, a colleague of mine named Mariko Sugita needed to hire a designer for a website she was creating. She’s an urbanist, and not particularly involved in the digital design field, so she asked the closest designer who happened to be on hand (me), “what kind of designers should I be looking for?”

Jasper takes a crack at it in this post.

Here's a roundup of other cracks at how to answer the same sort of question.

Direct Link to ArticlePermalink

The post The spectrum of design roles in 2018 appeared first on CSS-Tricks.

Figma Web API

Css Tricks - Fri, 03/23/2018 - 3:50am

Figma launched their Web Platform API which allows developers to build on top of and extend the features of their web-based design tool. They also published a quick post about the release that showcases how design teams at Uber and GitHub are starting to use the API but they also dig into a few public extensions that are available to use today.

AirBnB is also all over it. No surprise as they seem to be leading the industry in creating, extending, and integrating design tooling.

Our friends at Figma recently opened up the first layer of their API to the public. Their cloud-based, multiplayer-by-default design tool is the perfect environment for considering Design Intelligence as an agent that, much like a colleague, could truly exist alongside us.

We’ve been having fun playing with it for the past few months, building workflow tools we once only dreamed of.

Direct Link to ArticlePermalink

The post Figma Web API appeared first on CSS-Tricks.

Approaches to Deprecating Code in JavaScript

Css Tricks - Fri, 03/23/2018 - 3:43am

Recently, I had to dig into the topic of code deprecation in JavaScript. I feel like this topic gets less coverage even though it may a play key role in certain projects, especially when working in bigger teams or dealing with external APIs.

In JavaScript-land, I don't know of any true industry standards for deprecating JavaScript. It could be different per any team, library or vendor.

That’s why my goal here is to sum up my findings and thoughts on this topic, alongside some good practices when it’s time to mark a JavaScript method obsolete.

What does “deprecation” actually mean?

First, let’s start by clarifying that the deprecation is just a status applied to a software feature. It indicates that this feature should be avoided, typically because it has been superseded.

Deprecation may also indicate that the feature will be removed in the future. Features are deprecated—rather than immediately removed—in order to provide backward compatibility, and give programmers who have used the feature time to bring their code into compliance with the new standard.

Additionally, a deprecated feature suggests that there won’t be any further development from this point onward. It shouldn’t work any different than it did in a previous version (unless documentation explicitly states something else). So, generally, it should be the same as it was when the deprecation action happened.

It may or may not work in the latest version—no guarantees!

However, since there aren’t any true industry standards that are strictly followed inJavaScript-land, this could be slightly different per team, library or vendor.

When to deprecate code and when to delete it?

It’s important to note that a deprecated software feature or method is still a part of the software! Consider the "deprecated" label as just a status of the code. Whether the software feature will actually be removed in the future depends on what that particular software team decides.

In my opinion, large teams or projects relying on external APIs or libraries ought to deprecate first, then remove later (after a reasonable time, however you define that). At the very least, give at least one major version bump before actually removing the deprecated code so users have a chance to adjust to the change.

You might want to look at Semantic Versioning, a simple set of rules and requirements that dictate how version numbers are assigned and incremented. Given a version number MAJOR.MINOR.PATCH, increment the MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.

If your software is rapidly changing and evolving and you are deprecating a feature, try to communicate with your project manager if this feature is expected to be resurrected later. If you choose to deprecate, instead of delete, it might be a lot easier for you to revert should you need to.

For smaller teams or projects with internal methods and APIs, go ahead and remove first rather than deprecate. Sometimes it just doesn’t make sense to waste time and deprecation only increases the complexity just for the sake of following best practices.

How to mark a method obsolete

Here are five good practices I have found the most useful:

  1. Add a @deprecated JSDoc flag.
  2. Mention the version that the method was deprecated.
  3. Figure out a timeframe for when this method will be deleted, including which version it will take place. Otherwise, based on my experience, it stays forever &#x1f642;
  4. Use comments liberally to explain the implementation for the benefit of other developers or your future self. This is extremely useful if your use-case is writing a library that others use as a dependency for their work.
  5. Add a console warning message that indicates that the function is deprecated.

Here’s a more practical example where I use all five practices:

/** * A magic method that multiples digits. * * @deprecated [#1] since version 2.3 [#2]. * [#3] Will be deleted in version 3.0. * [#4] In case you need similar behavior, implement it on you own, * preferably in vanilla JavaScript * or use the multiplyTheSameNumber method instead, * if the same number needs to be multiplied multiple times, like so: * multiplyDigits([5, 5, 5]) === multiplyTheSameNumber(5, 3) * * @param {array} _digits - digits to multiply */ function multiplyDigits(_digits) { console.warn("Calling a depricated method!"); // [#5] // .... }

To avoid repetition in the console warnings or in case you plan to deprecate multiple methods and you have their replacements, it might be more convenient to use a helper:

/** * Creating a deprecated / obsolete behavior for methods in a library. * [Credits]{@link: https://stackoverflow.com/q/21726472/1333836} * * @param {function} replacementFunction * @param {string} oldFnName * @param {string} newFnName * @return {function} */ const Oboslete = function(replacementFunction, oldFnName, newFnName) { const wrapper = function() { console.warn("WARNING! Obsolete function called. Function '" + oldFnName + "' has been deprecated, please use the new '" + newFnName + "' function instead!"); replacementFunction.apply(this, arguments); } wrapper.prototype = replacementFunction.prototype; return wrapper; } Wrapping up

I’d suggest getting your team on the same page and inherit deprecation practices that make the most sense for your project or use case, whether it’s adopting the practices we’ve covered here or others.

Note that there are certain times when deletion makes more sense than deprecation. Sometimes, investing efforts to deprecate something simply aren’t worth it. Again, it’s totally up to you and what makes the most sense for your project.

Do you know other good practices when marking a method obsolete in JavaScript? Let me know in the comments!

Credits

The ideas I shared here were inspired by comments I found on Software Engineering Stack Exchange and on StackOverflow.

The post Approaches to Deprecating Code in JavaScript appeared first on CSS-Tricks.

Good ol’ Margin Collapsing

Css Tricks - Thu, 03/22/2018 - 3:48am

Here's a one-sentence blog post about margin collapsing: When two block elements are stacked on top of one another, the vertical space between them is the larger between the one on top's margin-bottom and the one on the bottom's margin-top.

It's a bit weird and ascii-shruggy. Couple caveats with them, as you might expect.

I find it fascinating how it makes for the perfect sort of mini blog post when people have an ah-ha moment about it. MDN even sees fit to have a dedicated page.

Adam Roberts in 2015:

Although the margin collapse behavior is at first a little unintuitive, it does make life easier in the case of multiple nested elements, where the behavior is often desirable.

Andrew Grant in 2015:

It's probably not the most intuitive aspect of CSS, but the takeaway here is that there is some logic at play and, once you have learned it, the mystery and confusion suddenly disappears!

Geoff Graham in 2015:

Do you see how collapsing margins can make things tricky? I personally encounter this on a frustratingly frequent basis when dealing with typography.

Magnus Benoni in 2016:

Margin collapsing can be frustrating to deal with, but knowing when and how it happens will make it easier for you to fix problems when they occur.

Ire Aderinokun in 2017:

Collapsible margins can be a pain if you don't properly understand when they occur. The first step to dealing with or avoiding them is [to] understand exactly which case of collapsible margins we are dealing with.

Adam Laki in 2018:

Margin collapse is something that mentioned in every CSS book’s first or second chapter. When I learned about the stylesheets in a long time ago, of course, I read about it.

Jonathan Harrell in 2018:

The concept of margin collapse is foundational to an understanding of the box model in CSS, but it is actually quite complex and potentially confusing. The spec describing how margin collapse works is thorough but difficult to understand.

I don't point all these out to say it's an over-blogged subject (nothing is), but that it's an interesting thread to follow. When so many people feel the need to explain something ultimately so small, there is something weird (probably bad) happening there.

No doubt this is why it's considered one of the mistakes in the design of CSS:

The top and bottom margins of a box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil.

Emphasis theirs and is, in fact, the only bold text in the entire list.

If you're looking to stop the behavior, you'll need to do something that probably has more side effects than it's worth, like float the elements. It's not quite as simple as kicking off a new Block Formatting Context, as that's what display: flow-root; does and that doesn't work.

You're probably better off just knowing about it and dealing with it as it comes up by systematically flowing margins in one direction, or getting weird.

The post Good ol’ Margin Collapsing appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.