Web Standards

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? 😉), 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.

?Deliver exceptional customer experiences in your product

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

(This is a sponsored post.)

?Pendo delivers the only complete platform for product teams that helps companies create great products. The Pendo Product Experience Platform enables product teams to understand product usage, collect user feedback, measure NPS, assist users in their apps and promote new features in product - all without requiring any engineering resources. This unique combination of capabilities is all built on a common infrastructure of product data and results in improved customer satisfaction, reduced churn, and increased revenue.

Pendo is the proven choice of innovative product leaders at Salesforce, Proofpoint, Optimizely, Citrix, BMC and many more leading companies.

Request a demo of Pendo today.?

Direct Link to ArticlePermalink

The post ?Deliver exceptional customer experiences in your product appeared first on CSS-Tricks.

Putting Things in Context With React

Css Tricks - Wed, 03/21/2018 - 6:25am

Context is currently an experimental API for React - but soon to be a first class citizen! There are a lot of reasons it is interesting but perhaps the most is that it allows for parent components to pass data implicitly to their children, no matter how deep the component tree is. In other words, data can be added to a parent component and then any child can tap into it.

See the Pen React Context Lights by Neal Fennimore (@nealfennimore) on CodePen.

While this is often the use case for using something like Redux, it’s nice to use if you do not need complex data management. Think about that! We create a custom downstream of data, deciding which props are passed and at which levels. Pretty cool.

Context is great in areas of where you have a lot of components that depend on a single piece of data, but are deep within the component tree. Explicitly passing each prop to each individual component can often be overwhelming and it is a lot easier just to use context here.

For example, let’s consider how we would normally pass props down the tree. In this case, we’re passing the color red using props on each component in order to move it on down the stream.

class Parent extends React.Component { render(){ return <Child color="red" />; } } class Child extends React.Component { render(){ return <GrandChild color={this.props.color} /> } } class GrandChild extends React.Component { render(){ return ( <div style={{color: this.props.color}}> Yep, I'm the GrandChild </div> ); } }

What if we never wanted the Child component to have the prop in the first place? Context saves us having to go through the Child component with color and pass it directly from the Parent to the GrandChild:

class Parent extends React.Component { // Allow children to use context getChildContext() { return { color: 'red' }; } render(){ return <Child />; } } Parent.childContextTypes = { color: PropTypes.string }; class Child extends React.Component { render() { // Props is removed and context flows through to GrandChild return <GrandChild /> } } class GrandChild extends React.Component { render() { return ( <div style={{color: this.context.color}}> Yep, I'm still the GrandChild </div> ); } } // Expose color to the GrandChild GrandChild.contextTypes = { color: PropTypes.string };

While slightly more verbose, the upside is exposing the color anywhere down in the component tree. Well, sometimes…

There’s Some Gotchas

You can’t always have your cake and eat it too, and context in it’s current form is no exception. There are a few underlying issues that you’ll more than likely come into contact with if you end up using context for all but the simplest cases.

Context is great for being used on an initial render. Updating context on the fly? Not so much. A common issue with context is that context changes are not always reflected in a component.

Let’s dissect these gotchas in more detail.

Gotcha 1: Using Pure Components

Context is hard when using PureComponent since by default it does not perform any shallow diffing by default with context. Shallow diffing with PureComponent is testing for whether the values of the object are strictly equal. If they're not, then (and only then) will the component update. But since context is not checked, well... nothing happens.

See the Pen React Context Lights with PureComponents by Neal Fennimore (@nealfennimore) on CodePen.

Gotcha 2: Should Component Update? Maybe.

Context also does not update if a component’s shouldComponentUpdate returns false. If you have a custom shouldComponentUpdate method, then you’ll also need to take context into consideration. To enable updates with context, we could update each individual component with a custom shouldComponentUpdate that looks something like this.

import shallowEqual from 'fbjs/lib/shallowEqual'; class ComponentThatNeedsColorContext extends React.PureComponent { // nextContext will show color as soon as we apply ComponentThatNeedsColorContext.contextTypes // NOTE: Doing the below will show a console error come react v16.1.1 shouldComponentUpdate(nextProps, nextState, nextContext){ return !shallowEqual(this.props, nextProps) || !shallowEqual(this.state, nextState) || !shallowEqual(this.context, nextContext); } } ComponentThatNeedsColorContext.contextTypes = { color: PropTypes.string };

However, this does not solve the issue of an intermediary PureComponent between the parent and the child blocking context updates. This means that every PureComponent between the parent and child would need to have contextTypes defined on it, and they would also need to have an updated shouldComponentUpdate method. And at this point, that's a lot of work for very little gain.

Better Approaches to the Gotchas

Fortunately, we have some ways to work around the gotchas.

Approach 1: Use a Higher Order Component

A Higher Order Component can read from context and pass the needed values on to the next component as a prop.

import React from 'react'; const withColor = (WrappedComponent) => { class ColorHOC extends React.Component { render() { const { color } = this.context; return <WrappedComponent style={{color: color}} {...this.props} /> } } ColorHOC.contextTypes = { color: React.PropTypes.string }; return ColorHOC; }; export const Button = (props)=> <button {...props}>Button</button> // ColoredButton will render with whatever color is currently in context with a style prop export const ColoredButton = withColor( Button );

See the Pen React Context Lights with HOC by Neal Fennimore (@nealfennimore) on CodePen.

Approach 2: Use Render Props

Render Props allow us to use props to share code between two components.

class App extends React.Component { getChildContext() { return { color: 'red' } } render() { return <Button /> } } App.childContextTypes = { color: React.PropTypes.string } // Hook 'Color' into 'App' context class Color extends React.Component { render() { return this.props.render(this.context.color); } } Color.contextTypes = { color: React.PropTypes.string } class Button extends React.Component { render() { return ( <button type="button"> {/* Return colored text within Button */} <Color render={ color => ( <Text color={color} text="Button Text" /> ) } /> </button> ) } } class Text extends React.Component { render(){ return ( {this.props.text} ) } } Text.propTypes = { text: React.PropTypes.string, color: React.PropTypes.string, }</Color></button> Approach 3: Dependency Injection

A third way we can work around these gotchas is to use Dependency Injection to limit the context API and allow components to subscribe as needed.

The New Context

The new way of using context, which is currently slated for the next minor release of React (16.3), has the benefits of being more readable and easier to write without the “gotchas” from previous versions. We now have a new method called createContext, which defines a new context and returns both a Provider and Consumer.

The Provider establishes a context that all sub-components can hook into. It’s hooked in via Consumer which uses a render prop. The first argument of that render prop function, is the value which we have given to the Provider. By updating the value within the Provider, all consumers will update to reflect the new value.

As a side benefit with using the new context, we no longer have to use childContextTypes, getChildContext, and contextTypes.

const ColorContext = React.createContext('color'); class ColorProvider extends React.Component { render(){ return ( <ColorContext.Provider value={'red'}> { this.props.children } </ColorContext.Provider> ) } } class Parent extends React.Component { render(){ // Wrap 'Child' with our color provider return ( <ColorProvider> <Child /> </ColorProvider> ); } } class Child extends React.Component { render(){ return <GrandChild /> } } class GrandChild extends React.Component { render(){ // Consume our context and pass the color into the style attribute return ( <ColorContext.Consumer> {/* 'color' is the value from our Provider */} { color => ( <div style={{color: color}}> Yep, I'm still the GrandChild </div> ) } </ColorContext.Consumer> ); } } Separate Contexts

Since we have more granular control in how we expose context and to what components are allowed to use it, we can individually wrap components with different contexts, even if they live within the same component. We can see this in the next example, whereby using the LightProvider twice, we can give two components a separate context.

See the Pen React Context Lights with new Context by Neal Fennimore (@nealfennimore) on CodePen.

Conclusion

Context is a powerful API, but it's also very easy to use incorrectly. There are also a few caveats to using it, and it can be very hard to figure out issues when components go awry. While Higher-Order Components and dependency injection offer alternatives for most cases, context can be used beneficially in isolated portions of your code base.

With the next context though, we no longer have to worry about the gotchas we had with the previous version. It removes having to define contextTypes on individual components and opens up the potential for defining new contexts in a reusable manner.

The post Putting Things in Context With React appeared first on CSS-Tricks.

Going From Dumb Little Idea to Real Website in Like 10 Minutes

Css Tricks - Tue, 03/20/2018 - 3:43am

I live in Bend, Oregon. I woke up with the dumbest idea ever that there should be a little food truck map website and it should be called Vend, Oregon. It's not my finest idea, but hey, I'm full of those. Fortunately, we don't have to spend all day on this.

1) Figure out what's going to go on this dumb little website

Fortunately, all the hard work was already done. One of our local rags already created a list of them. They allude to a map multiple times, but it's hard to dig it up. In searching around a bit, I found this which does have an embedded Google Map.

Perhaps this can be useful then! Let's blow up this map and embed it properly!

2) Make the dumb site

Fortunately, Google Maps are embeddable. Let's just slap their embed code in an HTML document:

<body> <iframe src="https://www.google.com/maps/d/embed?mid=1bg2tr60F_w395jAY-WW8JGbwSCM" width="640" height="480"></iframe> </body>

And have it cover the entire page:

html, body { margin: 0; height: 100%; overflow: hidden; } iframe { postion: absolute; top: 0; left: 0; width: 100%; height: 100%; border: 0; }

Let's use CodePen Projects for this, as that'll get us another step closer to having this live.

The extra files there are just a Bend logo I fired through RealFaviconGenerator. 3) Buy the dumb domain name

This is the point where you really start to question the idea. But, go ahead and pull the trigger anyway. The internet needs you.

4) It's dumb, but it it might as well be HTTPS

One big reason to use CloudFlare is you get HTTPS even on their free plan. Might as well take advantage of that. This means pointing the nameservers from your domain registrar over to CloudFlare.

5) Deploy the CodePen Project

You can deploy the site right out of CodePen Projects.

Note that you get some IP addresses there. Add those as A Records right in CloudFlare and you're done!

6) Bask in your dumb idea

Swear to god, 10 minutes from start to finish.

The post Going From Dumb Little Idea to Real Website in Like 10 Minutes appeared first on CSS-Tricks.

Linkbait 39

QuirksBlog - Tue, 03/20/2018 - 1:31am

More like a link-late, but here it finally is.

  • Tim Kadlec takes a look at how fast AMP really is, spurred on by Ferdy Christiant’s research that we featured earlier. Tim concludes that the main performance benefit comes from AMP pages being served from Google’s CDN. Other than that AMP pages are mildly more performant than non-AMP pages, mostly because it arranges some optimizations and resource loading for you. The cost, however, is a slightly slower Start Render time, because the scripts that arrange all those optimizations and loading have to run before the AMP page is ready to be shown.

    Right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

  • Steve Yegge shares his thoughts on the current state of Android. While Google still retains control over Android itself, it may be losing its grip on important auxiliaries:

    We’ve seen that there are at least three coordinated types of attack happening in different dimensions: The developer ecosystem (React Native and friends), the store (Amazon’s app store and Cyanogen’s rumored successor), and the lightweight in-app marketplaces (Facebook and WeChat, so far). Google’s reactions to each of these threats so far have been… well, let’s just say they’re still on top. For now.

    Does that matter? Yes, for tech shops it does.

    If you think there’s any risk at all that Google might lose control of Android, then your best bet is to use a cross-platform framework, because it hedges your bet via improved portability.

    React Native, in other words. If it can survive the current storm aimed against Facebook — but it probably can, because it can always be spun off.
  • Why I quit Google is an interesting article about self-defeating “objective” promotion criteria at Google.
  • Steve Faulkner clarifies how the HTML/CSS DOM, which can be changed by, among others, the flexbox order property, isn’t reflected in the browser’s accessibility tree. This is a reaction to last time’s discussion about CSS variable use for table sorting.
  • Chris Coyier shows how to make notched boxes in kind-of Battlestar Galactica style. Nice.
  • Excellent article on dealing with huge collections of DOM nodes — think tables with 1,000 rows. Vanilla JavaScript remains by far the best option performance-wise. Also, don’t bother optimising your core JavaScript loops and stuff — instead, optimise DOM handling. Clear DOM subtrees through innerHTML. On the other hand, don’t destroy nodes you may need later on — re-building them is way more expensive than keeping them around in memory.
    And no, this is nothing new. Ten years ago I would have given the same advice. But it’s good to know that the old rules are still being supported by the current data.
  • Food for thought:

    I’m beginning to think JS may be bifurcating into two largely disjoint communities. The “sw engineers” comfortable with pre-deployment tool chains and the “explorers” who want "live programming" tools

    I’m not 100% sure what Allen means by live programmers, and when I wanted to ask them I hit on my own definition and tweeted that instead.
    I think that the big split in JavaScript land is between those who firmly keep their eyes on browsers as our development platforms, and those who want to abstract away browsers.
    And yes, I think the first group is right and the second one is wrong, and that the second one will run into problems due to not understanding the platforms it’s creating software for.
  • This article calls the front-end/back-end division an antipattern. While I disagree with that premise, most of the article treats how back-enders look down on front-enders, and why that attitude should end — which is something I agree with.

    Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.

    To be clear, I’m not saying that we all need to be experts in everything. [...] While it is perfectly valid to dislike a particular technology, such as CSS, the industry's culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.

    Such as CSS. Thar’s a problem I’ll have to get back to one of these days.
    Pointing out that front-end can be as complex as back-end, and doing so in a back-ender-friendly way, is a good idea. Still, the article manages to ignore browsers as a developer platform entirely, despite the fact that mentioning them would have made its point even stronger. But maybe back-enders don’t want to hear about browsers because they’re terrified of them.
  • According to Tobie Langel contributing to OSS has ROI roughly equal to using OSS. Twenty years ago large companies were leery of using it; now they're leery of contributing to open source. So we have to convince them.
  • Insights and data, baby! The StackOverflow developer survey and the Design Census have been released. These surveys always yield interesting data.
  • Seems like an awful place to work for the health-unconscious such as myself.
  • Chronicles of Crime is a board game that incorporates an app, VR, and QR codes. Apps and VR have been done before in board games — the wonderful Alchemists was the poster child for apps in games — but as far as I know nobody yet combined them (i.e. let the app do more than just show VR), and nobody yet added QR codes, which are supposed to be a dying technology.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

The 3 Big Differences Between UX And UI Design

Usability Geek - Mon, 03/19/2018 - 11:17am
The debates over the definitions of UX and UI have been going on for almost as long as the terms have been around. UX stands for User Experience, and UI stands for User Interface. Clear as mud? That...
Categories: Web Standards

The Vue Cookbook

Css Tricks - Mon, 03/19/2018 - 8:59am

I'm extremely excited to announce that the Vue Cookbook is officially in beta! For the past few months, the Vue team has been writing, and editing and accepting PRs from the community to build a new section of our docs called the Cookbook. Each recipe stands on its own, meaning that recipes can focus on one specific aspect of Vue or something that integrates with Vue, and do a small deep dive into that subject. We can then include more complex examples, combining features in interesting ways.

One of my favorite parts of the cookbook is the Alternative Patterns section of each recipe. Usually when people write blog posts or document something, they're also selling you on the concept that they're explaining. In the cookbook, we strive to consider that we're all building different kinds of applications and websites, and thus a variety of choices will be valid, given divergent scenarios. The cookbook spends a little time in each recipe weighing the tradeoffs, and considering when one might need another path.

For advanced features, we assume some ecosystem knowledge. For example, if you want to use single-file components in Webpack, we don’t explain how to configure the non-Vue parts of the Webpack config. In the cookbook, we have the space to explore these ecosystem libraries in more depth—at least to the extent that is universally useful for Vue developers.

This section will continue to be in development! We have more recipes that we're writing, we're still accepting PRs, and the more community involvement, the richer a resource it becomes! I hope you enjoy it and find it useful.

Direct Link to ArticlePermalink

The post The Vue Cookbook appeared first on CSS-Tricks.

React State From the Ground Up

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

As you begin to learn React, you will be faced with understanding what state is. State is hugely important in React, and perhaps a big reason you’ve looked into using React in the first place. Let’s take a stab at understanding what state is and how it works.

What is State?

State, in React, is a plain JavaScript object that allows you keep track of a component’s data. The state of a component can change. A change to the state of a component depends on the functionality of the application. Changes can be based on user response, new messages from server-side, network response, or anything.

Component state is expected to be private to the component and controlled by the same component. To make changes to a component's state, you have to make them inside the component — the initialization and updating of the component's state.

Class Components

States is only available to components that are called class components. The main reason why you will want to use class components over their counterpart, functional components, is that class components can have state. Let's see the difference. Functional components are JavaScript functions, like this:

const App = (props) => { return ( <div> { this.props } </div> ) }

If the functionality you need from your component is as simple as the one above, then a functional component is the perfect fit. A class component will look a lot more complex than that.

class App extends React.Component { constructor(props) { super(props) this.state = { username: 'johndoe' } } render() { const { username } = this.state return( <div> { username } </div> ) } }

Above, I am setting the state of the component's username to a string.

The Constructor

According to the official documentation, the constructor is the right place to initialize state. Initializing state is done by setting this.state to an object, like you can see above. Remember: state is a plain JavaScript object. The initial state of the App component has been set to a state object which contains the key username, and its value johndoe using this.state = { username: 'johndoe' }.

Initializing a component state can get as complex as what you can see here:

constructor(props) { super(props) this.state = { currentTime: 0, status: false, btnOne: false, todoList: [], name: 'John Doe' } } Accessing State

An initialized state can be accessed in the render() method, as I did above.

render() { const { username } = this.state return( <div> { username } </div> ) }

An alternative to the above snippet is:

render() { return( <div> { this.state.username } </div> ) }

The difference is that I extracted the username from state in the first example, but it can also be written as const status = this.state.username. Thanks to ES6 destructuring, I do not have to go that route. Do not get confused when you see things like this. It is important to know that I am not reassigning state when I did that. The initial setup of state was done in the constructor, and should not be done again - never update your component state directly.

A state can be accessed using this.state.property-name. Do not forget that aside from the point where you initialized your state, the next time you are to make use of this.state is when you want to access the state.

Updating State

The only permissible way to update a component's state is by using setState(). Let's see how this works practically.

First, I will start with creating the method that gets called to update the component's username. This method should receive an argument, and it is expected to use that argument to update the state.

handleInputChange(username) { this.setState({username}) }

Once again, you can see that I am passing in an object to setState(). With that done, I will need to pass this function to the event handler that gets called when the value of an input box is changed. The event handler will give the context of the event that was triggered which makes it possible to obtain the value entered in the input box using event.target.value. This is the argument passed to handleInputChange() method. So, the render method should look like this.

render() { const { username } = this.state return ( <div> <div> <input type="text" value={this.state.username} onChange={event => this.handleInputChange(event.target.value)} /> </div> <p>Your username is, {username}</p> </div> ) }

Each time setState() is called, a request is sent to React to update the DOM using the newly updated state. Having this mindset makes you understand that state update can be delayed.

Your component should look like this;

class App extends React.Component { constructor(props) { super(props) this.state = { username: 'johndoe' } } handleInputChange(username) { this.setState({username}) } render() { const { username } = this.state return ( <div> <div> <input type="text" value={this.state.username} onChange={event => this.handleInputChange(event.target.value)} /> </div> <p>Your username is, {username}</p> </div> ) } } Passing State as Props

A state can be passed as props from a parent to the child component. To see this in action, let's create a new component for creating a To Do List. This component will have an input field to enter daily tasks and the tasks will be passed as props to the child component.

Try to create the parent component on your own, using the lessons you have learned thus far.

Let's start with creating the initial state of the component.

class App extends React.Component { constructor(props) { super(props) this.state = { todoList: [] } } render() { return() } }

The component's state has its todoList set to an empty array. In the render() method, I want to return a form for submitting tasks.

render() { const { todoList } = this.state return ( <div> <h2>Enter your to-do</h2> <form onSubmit={this.handleSubmit}> <label>Todo Item</label> <input type="text" name="todoitem" /> <button type="submit">Submit</button> </form> </div > ) }

Each time a new item is entered and the submit button is clicked, the method handleSubmit gets called. This method will be used to update the state of the component. The way I want to update it is by using concat to add the new value in the todoList array. Doing so will set the value for todoList inside the setState() method. Here's how that should look:

handleSubmit = (event) => { event.preventDefault() const value = (event.target.elements.todoitem.value) this.setState(({todoList}) => ({ todoList: todoList.concat(value) })) }

The event context is obtained each time the submit button is clicked. We use event.preventDefault() to stop the default action of submission which would reload the page. The value entered in the input field is assigned a variable called value, which is then passed an argument when todoList.concat() is called. React updates the state of todoList by adding the new value to the initial empty array. This new array becomes the current state of todoList. When another item is added, the cycle repeats.

The goal here is to pass the individual item to a child component as props. For this tutorial, we'll call it the TodoItem component. Add the code snippet below inside the parent div which you have in render() method.

<div> <h2>Your todo lists include:</h2> { todoList.map(i => <TodoItem item={i} /> )} </div>

You're using map to loop through the todoList array, which means the individual item is then passed to the TodoItem component as props. To make use of this, you need to have a TodoItem component that receives props and renders it on the DOM. I will show you how to do this using functional and class components.

Written as a functional component:

const TodoItem = (props) => { return ( <div> {props.item} </div> ) }

For the class component, it would be:

class TodoItem extends React.Component { constructor(props) { super(props) } render() { const {item} = this.props return ( <div> {item} </div> ) } }

If there is no need to manage state in this component, you are better off using functional component.

Leveling Up

You will be handling state very often while developing React application. With all the areas covered above, you should have the confidence of being able to dive into the advanced part of state management in React. To dig deeper, I recommend React's official documentation on State and Lifecycle as well as Uber's React Guide on Props vs State.

The post React State From the Ground Up appeared first on CSS-Tricks.

Microsoft Edge Variable Fonts Demo

Css Tricks - Fri, 03/16/2018 - 7:23am

The Edge team put together a thorough demo of variable fonts, showcasing them in all of their shape-shifting and adaptive glory. Equally interesting as the demo itself is a history of web typography and where variable fonts fit in the grand scheme of things.

This demo pairs well with v-fonts.com, which is an interactive collection of variable fonts that allows you to play around with the variable features each font provides.

Direct Link to ArticlePermalink

The post Microsoft Edge Variable Fonts Demo appeared first on CSS-Tricks.

A simple resource for finding and trying variable fonts

Css Tricks - Fri, 03/16/2018 - 7:23am

This is a website designed to showcase fonts that support OpenType Variations and let you drag a whole bunch of sliders around to manipulate a typeface’s width, height, and any other settings that the type designer might’ve added to the design.

I think the striking thing about this project is that I had no idea just how many variable fonts were out there in the wild until now.

Direct Link to ArticlePermalink

The post A simple resource for finding and trying variable fonts appeared first on CSS-Tricks.

Theming With Variables: Globals and Locals

Css Tricks - Fri, 03/16/2018 - 4:04am

Cliff Pyles contributed to this post.

Setting CSS variables to theme a design system can be tricky: if they are too scoped, the system will lose consistency. If they are too global, you lose granularity.

Maybe we can fix both issues. I’d like to try to boil design system variables down to two types: Global and Component variables. Global variables will give us consistency across components. Component variables will give us granularity and isolation. Let me show you how to do it by taking a fairly simple component as an example.

Heads up, I’ll be using CSS variables for this article but the concept applies to preprocessor variables as well.

Global-scoped variables

System-wide variables are general concepts defined to keep consistency across your components.

Starting with an .alert component as an example, let’s say we want to keep consistency for all of our spaces on margins and paddings. We can first define global spacers:

:root { --spacer-sm: .5rem; --spacer-md: 1rem; --spacer-lg: 2rem; }

And then use on our components:

/* Defines the btn component */ .btn { padding: var(--spacer-sm) var(--spacer-md); } /* Defines the alert component */ .alert { padding: var(--spacer-sm) var(--spacer-md); }

The main benefits of this approach are:

  • It generates a single source of truth for spacers, and a single point for the author using our system to customize it.
  • It achieves consistency since every component follows the same spacing.
  • It produces a common point of reference for designers and developers to work from. As long as the designers follow the same spacing restrictions, the translation to code is seamless.

But it also presents a few problems:

  • The system loses modularity by generating a dependency tree. Since components depend on global variables, they are no longer isolated.
  • It doesn’t allow authors to customize a single component without overwriting the CSS. For example, to change the padding of the alert without generating a system wide shift, they’d have to overwrite the alert component:
.alert { padding-left: 1rem; padding-right: 1rem; }

Chris Coyier explains the idea of theming with global variables using custom elements in this article.

Component-scoped variables

As Robin Rendle explain in his article, component variables are scoped to each module. If we generate the alert with these variables, we’d get:

.alert { --alert-color: #222; color: var(--alert-color); border-color: var(--alert-color); }

The main advantages are:

  • It creates a modular system with isolated components.
  • Authors get granular control over components without overwriting them. They’d just redefine the value of the variable.

There is no way to keep consistency across components or to make a system wide change following this method.

Let’s see how we can get the best of both worlds!

The two-tier theming system

The solution is a two-layer theming system where global variables always inform component variables. Each one of those layers follow a set of very specific rules.

First tier: Global variables

The main reason to have global variables is to maintain consistency, and they adhere to these rules:

  • They are prefixed with the word global and follow the formula --global--concept--modifier--state--PropertyCamelCase
    • a concept is something like a spacer or main-title
    • a state is something like hover, or expanded
    • a modifier is something like sm, or lg
    • and a PropertyCamelCase is something like BackgroundColor or FontSize
  • They are concepts, never tied to an element or component
    • this is wrong: --global-h1-font-size
    • this is right: --global--main-title--FontSize

For example, a global variable setup would look like:

:root { /* --global--concept--size */ --global--spacer--sm: .5rem; --global--spacer--md: 1rem; --global--spacer--lg: 2rem; /* --global--concept--PropertyCamelCase */ --global--main-title--FontSize: 2rem; --global--secondary-title--FontSize: 1.8rem; --global--body--FontSize: 1rem; /* --global--state--PropertyCamelCase */ --global--hover--BackgroundColor: #ccc; } Second tier: Component variables

The second layer is scoped to theme-able component properties and follow these rules:

  • Assuming we are writing BEM, they follow this formula: --block__element--modifier--state--PropertyCamelCase
    • The block__element--modifier the selector name is something like alert__actions or alert--primary
    • a state is something like hover or active
    • and if you are not writing BEM class names the same principles apply, just replace the block__element--modifier with your classname
  • The value of component scoped variables is always defined by a global variable
  • A component variable always has a default value as a fallback in case the component doesn’t have the dependency on the global variables

For example:

.alert { /* Component scoped variables are always defined by global variables */ --alert--Padding: var(--global--spacer--md); --alert--primary--BackgroundColor: var(--global--primary-color); --alert__title--FontSize: var(--global--secondary-title--FontSize); /* --block--PropertyCamelCase */ padding: var(--alert--Padding, 1rem); /* Sets the fallback to 1rem. */ } /* --block--state--PropertyCamelCase */ .alert--primary { background-color: var(--alert--primary--BackgroundColor, #ccc); } /* --block__element--PropertyCamelCase */ .alert__title { font-size: var(--alert__title--FontSize, 1.8rem); }

You’ll notice that we are defining locally-scoped variables with global variables. This is key for the system to work since it allows authors to theme the system as a whole. For example, if they want to change the primary color across all components they just need to redefine --global--primary-color.

On the other hand each component variable has a default value so a component can stand on its own, it doesn’t depend on anything and authors can use it in isolation.

This setup allows for consistency across components, it generates a common language between designers and developers since we can set the same global variables in Sketch as bumpers for designers, and it gives granular control to authors.

Why does this system work?

In an ideal world, we as creators of a design system, expect "authors" or users of our system to implement it without modifications, but of course, the world is not ideal and that never happens.

If we allow authors to easily theme the system without having to overwrite CSS, we’ll not only make their lives easier but also reduce the risk of breaking modules. At the end of the day, a maintainable system is a good system.

The two-tier theming system generates modular and isolated components where authors have the possibility to customize them at a global and at a component level. For example:

:root { /* Changes the secondary title size across the system */ --global--secondary-title--FontSize: 2rem; } .alert { /* Changes the padding on the alert only */ --alert--Padding: 3rem; } What values should became variables?

CSS variables open windows to the code. The more we allow authors in, the more vulnerable the system is to implementation issues.

To keep consistency, set global variables for everything except layout values; you wouldn’t want authors to break the layout. And as a general rule, I’d recommend allowing access to components for everything you are willing to give support.

For the next version of PatternFly, an open source design system I work on, we’ll allow customization for almost everything that’s not layout related: colors, spacer, typography treatment, shadows, etc.

Putting everything together

To show this concept in action I’ve created a CodePen project:

Global variables are nestled in _global-variables.scss. They are the base to keep consistency across the system and will allow the author to make global changes.

There are two components: alert and button. They are isolated and modular entities with scoped variables that allow authors to fine tune components.

Remember that authors will use our system as a dependency in their project. By letting them modify the look and feel of the system through CSS variables, we are creating a solid code base that’s easier to maintain for the creators of the system and better to implement, modify, and upgrade to authors using the system.

For example, if an author wants to:

  • change the primary color to pink across the system;
  • change the danger color to orange just on the buttons;
  • and change the padding left to 2.3rem only on the alert...

...then this is how it’s done:

:root { // Changes the primary color on both the alert and the button --global--primary--Color: hotpink; } .button { // Changes the danger color on the button only without affecting the alert --button--danger--BackgroundColor: orange; --button--danger--hover--BorderColor: darkgoldenrod; } .alert { // Changes the padding left on the alert only without affecting the button --alert--PaddingLeft: 2.3rem; }

The design system code base is intact and it’s just a better dependency to have.

I am aware that this is just one way to do it and I am sure there are other ways to successfully set up variables on a system. Please let me know what you think on the comments or send me a tweet. I’d love to hear about what you are doing and learn from it.

The post Theming With Variables: Globals and Locals appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.