Front End Web Development

“the closest thing web standards have to a golden rule”

Css Tricks - Wed, 02/13/2019 - 1:02pm

The internet's own Mat Marquis plucks this choice quote from the HTML Design Principals spec:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

And then he applies the idea to putting images on websites in 2019.

Direct Link to ArticlePermalink

The post “the closest thing web standards have to a golden rule” appeared first on CSS-Tricks.

??Avoiding those dang cannot read property of undefined errors

Css Tricks - Wed, 02/13/2019 - 6:30am

????Uncaught TypeError: Cannot read property 'foo' of undefined.? The dreaded error we all hit at some point in JavaScript development. Could be an empty state from an API that returns differently than you expected. Could be something else. We don’t know because the error itself is so general and broad.

??I recently had an issue where certain environment variables weren't being pulled in for one reason or another, causing all sorts of funkiness with that error staring me in the face. Whatever the cause, it can be a disastrous error if it’s left unaccounted for, so how can we prevent it in the first place?

??Let’s figure it out.

??Utility library

??If you are already using a utility library in your project, there is a good chance that it includes a function for preventing this error. _.get? in lodash? (docs) or R.path in Ramda? (docs) allow accessing the object safely.
??
??If you are already using a utility library, this is likely the simplest solution. If you are not using a utility library, read on!

??

Short-circuiting with &&

????One interesting fact about logical operators in JavaScript is that they don't always return a boolean. According to the spec, "the value produced by a &&? or ||? operator is not necessarily of type Boolean. The value produced will always be the value of one of the two operand expressions.”
??
????In the case of the &&? operator, the first expression will be used if it a "falsy" value. Otherwise, the second expression will be used. This means that the expression 0 && 1? will be evaluated as 0? (a falsy value), and the expression 2 && 3? will be evaluated as 3?. If multiple &&? expressions are chained together, they will evaluate to either the first falsy value or the last value. For example, 1 && 2 && 3 && null && 4? will evaluate to null?, and 1 && 2 && 3? will evaluate to 3?.

????How is this useful for safely accessing nested object properties? Logical operators in JavaScript will "short-circuit." In this case of &&?, this means that the expression will cease moving forward after it reaches its first falsy value.

????

??const foo = false && destroyAllHumans(); ??console.log(foo); // false, and humanity is safe

??In this example, destroyAllHumans is never called because the &&? operand stopped all evaluation after false?.

??This can be used to safely access nested properties.

??

??const meals = { ?? breakfast: null, // I skipped the most important meal of the day! :( ?? lunch: { ?? protein: 'Chicken', ?? greens: 'Spinach', ?? }, ?? dinner: { ?? protein: 'Soy', ?? greens: 'Kale', ?? }, ??}; ?? ??const breakfastProtein = meals.breakfast && meals.breakfast.protein; // null ??const lunchProtein = meals.lunch && meals.lunch.protein; // 'Chicken'

??Aside from its simplicity, one of the main advantages of this approach is its brevity when dealing with small chains. However, when accessing deeper objects, this can be quite verbose.

??

const favorites = { ?? video: { ?? movies: ['Casablanca', 'Citizen Kane', 'Gone With The Wind'], ?? shows: ['The Simpsons', 'Arrested Development'], ?? vlogs: null, ?? }, ?? audio: { ?? podcasts: ['Shop Talk Show', 'CodePen Radio'], ?? audiobooks: null, ?? }, ?? reading: null, // Just kidding -- I love to read ??}; ?? ??const favoriteMovie = favorites.video && favorites.video.movies && favorites.video.movies[0]; ??// Casablanca ??const favoriteVlog = favorites.video && favorites.video.vlogs && favorites.video.vlogs[0]; ??// null

??The more deeply nested an object is, the more unwieldy it gets.

??
??

The “Maybe Monad”

??Oliver Steele came up with this method and goes through it in much more detail in his blog post, "Monads on the Cheap I: The Maybe Monad." I will attempt to give a brief explanation here.

??

const favoriteBook = ((favorites.reading||{}).books||[])[0]; // undefined ??const favoriteAudiobook = ((favorites.audio||{}).audiobooks||[])[0]; // undefined ??const favoritePodcast = ((favorites.audio||{}).podcasts||[])[0]; // 'Shop Talk Show'

??Similar to the short-circuit example above, this method works by checking if a value is falsy. If it is, it will attempt to access the next property on an empty object. In the example above, favorites.reading? is null?, so the books? property is being accessed from an empty object. This will result in an undefined?, so the 0? will likewise be accessed from an empty array.

??The advantage of this method over the &&? method is that it avoids repetition of property names. On deeper objects, this can be quite a significant advantage. The primary disadvantage would be readability — it is not a common pattern, and may take a reader a moment to parse out how it is working.?

??

??try/catch

????try...catch? statements in JavaScript allow another method for safely accessing properties.

??

try { ?? console.log(favorites.reading.magazines[0]); ??} catch (error) { ?? console.log("No magazines have been favorited."); ??}

??Unfortunately, in JavaScript, try...catch? statements are not expressions. They do not evaluate to a value as they do in some languages. This prevents a concise try? statement as a way of setting a variable.

??One option is to use a let? variable that is defined in the block above the try...catch?.

??

let favoriteMagazine; ??try { ?? favoriteMagazine = favorites.reading.magazines[0]; ??} catch (error) { ?? favoriteMagazine = null; /* any default can be used */ ??};

??Although it’s verbose, this works for setting a single variable (that is, if the mutable variable doesn't scare you off). However, issues can arise if they’re done in bulk.

??

let favoriteMagazine, favoriteMovie, favoriteShow; ??try { ?? favoriteMovie = favorites.video.movies[0]; ?? favoriteShow = favorites.video.shows[0]; ?? favoriteMagazine = favorites.reading.magazines[0]; ??} catch (error) { ?? favoriteMagazine = null; ?? favoriteMovie = null; ?? favoriteShow = null; ??}; ?? ??console.log(favoriteMovie); // null ??console.log(favoriteShow); // null ??console.log(favoriteMagazine); // null

??If any of the attempts to access the property fails, this will cause all of them to fall back into their defaults.

??An alternative is to wrap the try...catch? in a reusable utility function.

??

const tryFn = (fn, fallback = null) => { ?? try { ?? return fn(); ?? } catch (error) { ?? return fallback; ?? } ??} ?? ??const favoriteBook = tryFn(() => favorites.reading.book[0]); // null ??const favoriteMovie = tryFn(() => favorites.video.movies[0]); // "Casablanca"

??By wrapping the access to the object in a function, you can delay the "unsafe" code and pass it into a try...catch?.

??A major advantage of this method is how natural it is to access the property. As long as properties are wrapped in a function, they are safely accessed. A default value can also be specified in the case of a non-existent path.

??Merge with a default object

??
By merging an object with a similarly shaped object of "defaults," we can ensure that the path that we are trying to access is safe.
??
??

const defaults = { ?? position: "static", ?? background: "transparent", ?? border: "none", ??}; ?? ??const settings = { ?? border: "1px solid blue", ??}; ?? ??const merged = { ...defaults, ...settings }; ?? ??console.log(merged); ??/* ?? { ?? position: "static", ?? background: "transparent", ?? border: "1px solid blue" ?? } ??*/

??
??Careful, though, because the entire nested object can be overwritten rather than a single property.
??
??

const defaults = { ?? font: { ?? family: "Helvetica", ?? size: "12px", ?? style: "normal", ?? }, ?? color: "black", ??}; ?? ??const settings = { ?? font: { ?? size: "16px", ?? } ??}; ?? ??const merged = { ?? ...defaults, ?? ...settings, ??}; ?? ??console.log(merged.font.size); // "16px" ??console.log(merged.font.style); // undefined

??Oh no! To fix this, we'll need to similarly copy each of the nested objects.

??

const merged = { ?? ...defaults, ?? ...settings, ?? font: { ?? ...defaults.font, ?? ...settings.font, ?? }, ??}; ?? ??console.log(merged.font.size); // "16px" ??console.log(merged.font.style); // "normal"

??Much better!

??This pattern is common with plugins or components that accept a large settings object with included defaults.

??A bonus about this approach is that, by writing a default object, we’re including documentation on how an object should look. Unfortunately, depending on the size and shape of the data, the "merging" can be littered with copying each nested object.

???

The future: optional chaining

??There is currently a TC39 proposal for a feature called "optional chaining." This new operator would look like this:

??console.log(favorites?.video?.shows[0]); // 'The Simpsons' ??console.log(favorites?.audio?.audiobooks[0]); // undefined

??The ?.? operator works by short-circuiting: if the left-hand side of the ?.? operator evaluates to null? or undefined?, the entire expression will evaluate to undefined? and the right-hand side will remain unevaluated.

??To have a custom default, we can use the ||? operator in the case of an undefined.

??

console.log(favorites?.audio?.audiobooks[0] || "The Hobbit");

??

Which method should you use?

??The answer, as you might have guessed, is that age-old answer… "it depends." If the optional chaining operator has been added to the language and has the necessary browser support, it is likely the best option. If you are not from the future, however, there are more considerations to take into account. Are you using a utility library? How deeply nested is your object? Do you need to specify defaults? Different cases may warrant a different approach.

The post ??Avoiding those dang cannot read property of undefined errors appeared first on CSS-Tricks.

A Site for Front-End Development Conferences (Built with 11ty on Netlify)

Css Tricks - Tue, 02/12/2019 - 12:48pm

I built a new little site! It's a site for listing upcoming conferences in the world of front-end web design and development. In years past (like 2017), Sarah Drasner took up this daunting job. We used a form for new conference submissions, but it was still a rather manual task of basically manually editing a blog post. I wanted to keep doing this, as I think it's valuable to have a simple reference page for conferences in our niche slice of the web, but I wanted the site to be able to live on year after year with lower maintenance-related technical debt.

So this is what I did!

I wanted to get it on GitHub.

So I put it there. Part of the beauty of GitHub is that it opens up the idea of collaboration through pull requests to really anyone in the world. You need to have a GitHub account, but that's free, and you need to understand Git at least on some minor level (which is a barrier that I'd like to resolve in time), but it invites more collaboration than something like just asking people to email you content and ideas.

I wanted the content in Markdown in the Repo.

The Front Matter format, which is Markdown with some data the the top, is such a useful and approachable format. You need almost zero knowledge, not even HTML, to be able to create/edit a file like this:

Having the actual conference data in the repo means that pull requests aren't just for design or features; more commonly, they will be for actual conference data. The work of making this site full of all the best conferences is the work of all of us, not just one of us.

At the time of this writing there have already been 30 closed pull requests.

I used 11ty to build the site.

11ty is almost fascinatingly simple. It looks in one directory for what it needs to process or move to another directory. It supports my favorite templating system out of the box: Nunjucks. Plus front matter Markdown like I mentioned above.

I was able to essentially design a card that displays the data we get from the Markdown files, and then build the homepage of the site by looping over those Markdown files and applying the templated card.

11ty is based on Node.js, so while I did have some learning-curve moments, it was comfortable for me to work in. There definitely is configuration for doing the things I wanted to be doing. For example, this is how I had to make a "collection" of conferences in order to loop over them:

config.addCollection("conferences", function(collection) { let allConferences = collection.getFilteredByGlob("site/conferences/*.md"); let futureConferences = allConferences.filter(conf => { return conf.data.date >= new Date(); }); return futureConferences; }); The site is hosted on Netlify.

One reason to use Netlify here is that it's incredibly easy. I made a site site in Netlify by connecting it to the GitHub repo. I told it how to build the site (it's a single command: eleventy) and where the built site files are (dist), and that's it. In fact, that's even part of the repo:

Now whenever I push to the master branch (or accept a pull request into master), the site automatically rebuilds and deploys. Just takes seconds. It's really amazing.

Better, for each pull request, Netlify makes sure everything is in order first:

My favorite is the deploy preview. It gives you an (obscure) URL that will literally last forever (immutable) and that serves as a look at the built version of this site with that pull request.

So, not only is it extremely easy to use Netlify, but I get a bunch of stuff for free, like the fact that the site is smokin' fast on their CDNs and such.

I'm also excited that I've barely tapped into Netlify's features here, so there is a lot of stuff I can dig into over time. And I intend to!

I use Zapier to re-build the site every day.

There is a bit of a time-sensitive nature to this site. The point of this site is to reference it for upcoming conferences. It's less interesting to see past conferences (although maybe we can have a browse-able archive in the future). I like the idea of ripping off past conferences for the homepage. If this was PHP (or whatever), we could do that at runtime, but this is a static site (on purpose). Doing something like this at build time is no big deal (see that code snippet above that only returns conferences past today's date). But we can't just waiting around for pull requests to re-build the site, nor do I want to make it a manual thing I need to do every day.

Fortunately, this is easy as pie with Zapier:

Phil Hawksworth took this to the extreme once and built a clock website that rebuilds every minute.

This site wasn't just an experiment. I'd like to keep it going! If you're part of running a conference, I'm quite sure it doesn't hurt to add it to add yours, just so long as it has an enforcable and actionable Code of Conduct, and is within the world of front-end web design and development.

The post A Site for Front-End Development Conferences (Built with 11ty on Netlify) appeared first on CSS-Tricks.

Quick! What’s the Difference Between Flexbox and Grid?

Css Tricks - Tue, 02/12/2019 - 12:22pm

Let's go rapid fire and try to answer this question with quick points rather than long explanations. There are a lot of similarities between flexbox and grid, starting with the fact that they are used for layout and much more powerful than any layout technique that came before them. They can stretch and shrink, they can center things, they can re-order things, they can align things... There are plenty of layout situations in which you could use either one to do what we need to do, and plenty of situations where one is more well-suited than the other. Let's focus on the differences rather than the similarities:

Flexbox can optionally wrap. If we allow a flex container to wrap, they will wrap down onto another row when the flex items fill a row. Where they line up on the next row is independent of what happenned on the first row, allowing for a masonry-like look.

Grid can also optionally wrap (if we allow auto filling) in the sense that items can fill a row and move to the new row (or auto place themselves), but as they do, they will fall along the same grid lines all the other elements do.

Flexbox on top, Grid on bottom

You could think of flexbox as "one dimensional." While flexbox can make rows and columns in the sense that it allows elements to wrap, there's no way to declaratively control where elements end up since the elements merely push along a single axis and then wrap or not wrap accordingly. They do as they do, if you will, along a one-dimensional plane and it's because of that single dimension that we can optionally do things, like align elements along a baseline — which is something grid is unable to do.

.parent { display: flex; flex-flow: row wrap; /* OK elements, go as far as you can on one line, then wrap as you see fit */ }

You could think of grid as "two dimensional" in that we can (if we want to) declare the sizing of rows and columns and then explicitly place things into both rows and columns as we choose.

.parent { display: grid; grid-template-columns: 1fr 3fr 1fr; /* Three columns, one three times as wide as the others */ grid-template-rows: 200px auto 100px; /* Three rows, two with explicit widths */ grid-template-areas: "header header header" ". main sidebar" "footer . ."; } /* Now, we can explicitly place items in the defined rows and columns. */ .child-1 { grid-area: header; } .child-2 { grid-area: main; } .child-3 { grid-area: sidebar; } .child-4 { grid-area: footer; } Flexbox on top, Grid on bottom

I'm not the world's biggest fan of the "1D" vs. "2D" differentiation of grid vs. flexbox, only because I find most of my day-to-day usage of grid is "1D" and it's great for that. I wouldn't want someone to think they have to use flexbox and not grid because grid is only when you need 2D. It is a strong distinction though that 2D layout is possible with grid though in ways it is not in flexbox.

Grid is mostly defined on the parent element. In flexbox, most of the layout (beyond the very basics) happen on the children.

/* The flex children do most of the work */ .flexbox { display: flex; > div { &:nth-child(1) { // logo flex: 0 0 100px; } &:nth-child(2) { // search flex: 1; max-width: 500px; } &:nth-child(3) { // avatar flex: 0 0 50px; margin-left: auto; } } } /* The grid parent does most of the work */ .grid { display: grid; grid-template-columns: 1fr auto minmax(100px, 1fr) 1fr; grid-template-rows: 100px repeat(3, auto) 100px; grid-gap: 10px; }

Grid is better at overlapping. Getting elements to overlap in flexbox requires looking at traditional stuff, like negative margins, transforms, or absolute positioning in order to break out of the flex behavior. With grid, we can place items on overlapping grid lines, or even right within the same exact grid cells.

Flexbox on top, Grid on bottom

Grid is sturdier. While the flexing of flexbox is sometimes its strength, the way a flex item is sized gets rather complicated. It's a combination of width, min-width, max-width, flex-basis, flex-grow, and flex-shrink, not to mention the content inside and things like white-space, as well as the other items in the same row. Grid has interesting space-occupying features, like fractional units, and the ability for content to break grids, though, generally speaking, we're setting up grid lines and placing items within them that plop right into place.

Flexbox can push things away. It's a rather unique feature of flexbox that you can, for example, put margin-right: auto; on an element and, if there is room, that element will push everything else as far away as it can go can.

Here are some of my favorite tweets on the subject:

flexbox looks like it does what you want
but grid is usually what you want

— Old Guard Rupert (@davatron5000) January 25, 2019

Grid makes actual columns and rows. Content will line up from one to the other, as you ask it to. Flexbox doesn’t. Not only in the second dimension (which is easiest to talk about), but also in the first dimension. Flexbox isn’t for most of the things we’ve been using it for.

— Jen Simmons (@jensimmons) January 26, 2019

How about this:#Flexbox is for alignment. #CSSGrid is for layout.

This is almost always how I wind up using them. It allows them to preserve their relationships to one another. It also allows each to be used for its strength, even though each can do the other thing.

— Brian Haferkamp (@BrianHaferkamp) January 25, 2019

If you start constraining all your flex items with a width, then more often than not it will be easier to use grid.

— Rachel Andrew (@rachelandrew) January 25, 2019

Here's another difference, but it's not a favorite way of describing them, just fun dumb knowledge:

flexbox takes 2 passes to finish
grid takes 3

so one could say, grid is slow and flexbox is fast lol

— Adam Argyle (@argyleink) January 25, 2019

For me Grid is there to great full layout..grids...with more control over how the whole are/page comes together, whereas flexbox helps me to position and align (whether it’s in a grid or not).

For me it’s about purpose.

— Mandy Michael (@Mandy_Kerr) January 25, 2019

The distinction between the two is often blurry, especially now that we also have `gap` for flexbox. Grid is best suited for a few specific use cases (2D obviously, but also things like overlapping elements) while flexbox usually shines in simpler yet common layout requirements.

— Benjamin De Cock (@bdc) January 25, 2019

Use grid when you already have the layout structure in mind, and flex when you just want everything to fit. Layout first vs content first.

— Beverly (@aszenitha) January 25, 2019

The post Quick! What’s the Difference Between Flexbox and Grid? appeared first on CSS-Tricks.

A Funny Thing Happened on the Way to the JavaScript

Css Tricks - Tue, 02/12/2019 - 5:07am

Around this time last year, I wrote an article about the JavaScript learning landscape. Within that article, you’ll find my grand plans to learn JavaScript — complete with a link to a CodePen Collection I started for tracking my progress, and it even got dozens of comments cheering me on.

Like most people, I was ambitious. It was a new year and I was excited to tackle a long-standing project. It was my development version of losing 30 pounds (which I also need to do). But, if you follow that link to the CodePen Collection, you’ll see that there’s nothing there. If you were to scour my hard drive or cloud storage, you’d see that there aren’t any JavaScript files or projects there, either.

Over the past year, I didn’t make any progress on one of my main goals. So, what the hell happened?

A Story as Old as Time

The internet is littered with similar tweets and blog posts. Inboxes are filled with TinyLetters of resolutions and there's no shortage of YouTubers teaching anyone who will listen how to have their best year ever. But very few people follow through on their goals. This might be even more true in the design and development world, what with the plethora of new technologies, languages, libraries, and tools that hit the scene on a regular basis.

These stories all follow a similar path:

  1. Person determines major goal
  2. Person tells friends (or who knows how many CSS-Tricks visitors)
  3. Person gets distracted, overwhelmed, disinterested, or all three
  4. Goal is completely forgotten about after X amount of time
  5. Person apologizes and makes up excuses for friends (or, again, who know how many CSS-Tricks visitors)

In my experience, it's not the goal-setting or telling everyone about said goal that's the problem. It's step three above. When goals go off the rails, at least for me, it's due to three main issues: distraction, stress, and lack of interest. Barring unforeseen life events, these three issues are responsible for all those unachieved goals that we struggle with.

In thinking about my goals for this year, I decided to start first with deconstructing why I couldn’t reach the one major goal I set for myself last year. So, let’s dig into those three issues and see if there’s a way to prevent any of them happening this time around.

Distraction

Distraction seems to be the big one here. We all have a lot going on. Between job and family responsibilities, other hobbies and hanging out with friends, it’s hard to fit in new projects. As necessary as they are, all those other interests and responsibilities are distractions when it comes to our goals.

The whole point of setting a goal is carving out time to work towards it. It’s about prioritizing the goal over other things. For me, I found myself letting all of those other distractions in life work their way into my day. It was all too easy to work through lunch instead of taking that time to tackle a chapter in a JavaScript book. I would get sucked into the latest Netflix series after the kids went to bed. I didn’t prioritize learning JavaScript and I had nothing to show for it at the end of the year.

Overcoming Distraction

The key here is to block out those distractions, which is easier said than done. We can’t simply ignore the needs of our families and careers, but we need to give ourselves time to focus without distractions. For me, I’m increasingly convinced that the solution is time blocking.

Time blocking is exactly what it sounds like: You block out specific periods of time on your calendar to focus on certain tasks. Time blocking allows you to prioritize what’s important. It doesn’t force you to sit down, crack open a book, or start coding, but it gives you the time to do it.
There are a ton of articles online that go into different time blocking methods, a few of which are below:

For me, I’m going to block out specific times throughout the week to focus on learning JavaScript in 2019. I’m trying to be realistic about how much time I can invest, weighing it against other obligations. Then I’m putting those time blocks on my shared family calendar to make it clear to everyone what I’m prioritizing. More importantly, I’m making it clear that this time is for focus, and to leave the other distractions at the door.

It can also be helpful to block smaller, but just as impactful, distractions on your phone and computer. Closing out browser tabs not related to your task, silencing notifications, and clearing your desk of otherwise distracting items should be part of the routine when you sit down to start working on your task. It’s easy to scroll through Twitter, Hacker News, or even CSS-Tricks and convince yourself that it’s time well spent (that last one usually is, though) but that time adds up and doesn’t always result in learning or growing your skills like you think it will. Cutting out those distractions and allowing yourself to focus on what you want to accomplish is a great way to, you know, actually accomplish your goals.

Stress

Last year’s post lays out a landscape full of interesting articles, books, podcasts, and courses. There is no lack of things to learn about and enough resources to keep anyone busy for way longer than just a year. And, when it comes to JavaScript, it seems like there’s always some new technique or framework that you need to learn.

Combine that with all of the ancillary topics you need to understand when learning JavaScript and you end up with one of those overwhelming developer roadmaps that Chris collected a while back.

I don’t care how smart you are, that’s intimidating as hell. Feeling overwhelmed on the web is common place. How do you think it feels as someone just starting out? Combined with all the responsibilities and distractions from the last section, and you have a killer recipe for burnout.

I had originally intended to work my way through Marijn Haverbeke’s Eloquent JavaScript as a first step towards learning the language. But I also mentioned all the podcasts, YouTube channels, and newsletters with which I was surrounding myself. The intention was to learn through immersion, but it quickly resulted in feeling stressed and overwhelmed. And when I felt overwhelmed, I quickly allowed all those distractions to pull my attention away from learning JavaScript.

Overcoming Stress

Just like when dealing with distraction, I think the key to dealing with stress is to focus on one or two things and cut out all the rest. Instead of fully immersing myself in the JavaScript world, I’m going to stick to just the book, work my way through that, and then find the next resource later down the road. I’m going to intentionally ignore as much of the JavaScript world as I can in order to get my bearings and only open myself up to the stress of the developer roadmap if, and when, I feel like I want to journey down that path.

Disinterest

Flipping through any programming book (at least for a beginner) causes most people’s eyes to glaze over. The code looks overly complex and it resembles a math textbook. I don’t know about you, but I hated math class and I found it hard to get excited about investing my free time in something that felt a lot like going back to high school.

But I know that learning JavaScript (and programming, in general) is a worthwhile pursuit and will let me tackle projects that I’ve long wanted to complete but haven’t had the chops to do. So, how can I get interested in what, at first glance, looks like such a boring task?

Overcoming Disinterest

I think the key here is to relate what I learn to some subject that I find fascinating.

I’ve been interested in data visualization for a long time. Blogs like Flowing Data are fascinating, and I’ve wanted to be able to create data visualizations of my own for years. And I know that JavaScript is increasingly a viable way to create those graphics. Tools like D3.js and p5.js are first-class frameworks for creating amazing visualizations — so why not learn the underlying language those tools use?

My plan to overcome disinterest is to work my way towards a project that I want to build. Go through all the basics, trudge through the muck, and then use the concepts learned along the way to understand more advanced tools, like D3.js.

Anytime you can align your learning to areas you find interesting, you’re more likely to be successful. I think that’s what was missing the first time around, so I’m setting up targets to aim for when learning JavaScript, things that will keep me interested enough to learn what I need to learn.

It’s a Hard Road

Learning is rarely easy. But, sometimes, it’s when it’s the hardest that it pays off the most.

I’m convinced that the more we can uncover our own mental roadblocks and deconstruct them, the better positioned we are to achieve our goals. For me, my mental roadblocks are distraction, stress, and disinterest. The three work together to keep me from my goals, but I’m putting plans into motion to overcome all three. Your roadblocks may differ, but you probably have ways of dealing with them, too.

I’d love to hear from everyone how they overcame their own challenges when learning a new skill. Leave a comment below telling me your story. Sharing it may help me, and others, finally achieve what we’ve always wanted, whether it’s learning JavaScript, digging into the latest framework, or running that marathon we’ve all been putting off for so long.

The post A Funny Thing Happened on the Way to the JavaScript appeared first on CSS-Tricks.

Where Do You Nest Your Sass Breakpoints?

Css Tricks - Mon, 02/11/2019 - 5:16am

I love nesting my @media query breakpoints. It's perhaps the most important feature of Sass to me. Maybe I pick a method and do it like this:

.element { display: grid; grid-template-columns: 100px 1fr; @include breakpoint(baby-bear) { display: block; } }

That's straightforward enough. But what if my element has several sub-elements and the breakpoint affects them as well? There are different approaches, and I'm never quite sure which one I should be doing.

I could duplicate the breakpoint for each child:

.parent { @include breakpoint(desktop) { } .child { @include breakpoint(desktop) { } } .child-2 { @include breakpoint(desktop) { } } }

The compiled CSS comes out to something like this:

@media screen and (min-width: 700px) { .parent { } } @media screen and (min-width: 700px) { .parent .child { } } @media screen and (min-width: 700px) { .parent .child-2 { } }

Or, I could duplicate the children under the first nested breakpoint:

.parent { @include breakpoint(desktop) { .child { } .child-2 { } } .child { } .child-2 { } }

That results in:

@media screen and (min-width: 700px) { .parent .child { } .parent .child-2 { } } .parent .child { } .parent .child-2 { }

Or I could do a combination of the two. Neither of them feels particularly great because of the duplication, but I'm not sure there is a perfect answer here. I err a little more on duplicating the media query, as it seems less error-prone than duplicating selectors.

The post Where Do You Nest Your Sass Breakpoints? appeared first on CSS-Tricks.

The ineffectiveness of lonely icons

Css Tricks - Mon, 02/11/2019 - 5:15am

Icons are great and all, but as we've been shown time and time again, they often don't do the job all by themselves. Even if you do a good job with the accessibility part and make sure there is accompanying text there for assistive technology, in an ironic twist, you might be confusing people who browse visually, like the situation Matt Wilcox describes with his mother in this linked article.

I'm a fan of this markup pattern, including the inline SVG as the preferred icon system:

<button> <svg class="icon icon-cart" viewBox="0 0 100 100" aria-hidden="true"> <!-- all your hot svg action, like: --> <path d=" ... " /> </svg> Add to Cart </button>

Or, if the button is really a link and not a JavaScript-powered action, I'll use an <a href=""> instead of a <button> wrapper.

Direct Link to ArticlePermalink

The post The ineffectiveness of lonely icons appeared first on CSS-Tricks.

Using Dotfiles for Managing Development and Many Other Magical Things

Css Tricks - Fri, 02/08/2019 - 5:29am

Howdy folks! &#x1f389; I'm Simon Owen, and over the years, I've loved being a part of and learning from the dotfiles community. I spend a lot of time teaching developers and running workshops. In those sessions, demonstrating how I set up my development environment is often one of things that folks appreciated the most.

Dotfiles are a key part of my development environment. Haven’t heard of them? Well, even if you have, it’s a good idea to walk through what they are and the benefits of using them.

Last year, I set myself a goal to create a screencast series. If you like this article and want to find out more, please subscribe to the mailing list and get the download link. If you really like it, you can also &#x1f984; donate here! &#x1f984;

A dot-what-file?

If you’re hearing about dotfiles for the first time, it’s totally fine to be confused about what they are and what they do. I recall that it took me a considerable amount of time before I realized a dotfile is simply a file that has a dot in front of the file name!

There are two common examples of dotfiles. First, the ones you might already be familiar with are those often found at the root of many open source projects — for example, .editorconfig contains code editor preferences to help maintain consistent coding styles for a project. You may also have seen .stylelintrc and .eslintrc floating around, which set CSS and JavaScript rules, respectively.

Second (and the ones we’re looking at today), are dotfiles that can live at the root level of a user directory (i.e. /Users/<username> ). One such dotfile is .aliases, which contains custom named commands that can speed up work in the Terminal. Another is .bash_prompt, which is used to change the $ in Terminal to something a little more fun. In my case, I set it so this dude pops up to make me smile when things get tough:

? ? ?_? ??

Hopefully, you’re already starting to get a good sense of how useful dotfiles can be. They’re sort of like hidden gems (literally, since they’re hidden from views by default) that unlock superpowers for your machine to help with development. We’re talking about automation, optimizations, and efficient workflows, among other things.

First, I want to give props to the dotfiles community

Before we dig into dotfiles, it’s worth calling out how great the community behind them is. When I first forked Paul Irish’s dotfile repo, there was a lot going on in there I didn’t understand. Mathias Bynens and Paul Irish helped me immensely by answering questions about the code and it was their willingness to help that served as one of the reasons I became drawn to both the concept and the community.

Sometimes, I’ll post something to the community that I’d like to automate, but can’t figure it out for the life of me. And, without fail, I’ll get a helpful reply. Case in point: Eric Czarny wrote an app for me to automate my Spectacle settings and Mathias also contributed a code snippet. How cool is that?!

Then there are things like macOS updates. The dotfiles community is often on top of this and provide useful advice on GitHub comments regarding anything that no longer works or other useful information. You can then amend your dotfiles accordingly, such as adding the following code that increases the sound quality for Bluetooth headphones/headsets:

defaults write com.apple.BluetoothAudioAgent "Apple Bitpool Min (editable)" -int 40 Digging into dotfiles

The code example above might look a bit familiar to you. It’s along the same lines as this often-used one to show hidden files:

defaults write com.apple.finder AppleShowAllFiles -bool true

...or this one to add spaces to the dock:

defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="spacer-tile";}'; killall Dock

These commands can be pasted directly into the Terminal. As you might expect, something like -bool true will change a boolean value from false to true and reset the command for later use.

If you’e like me and have a lot of these commands, then this is where the .macos (previously .osx) dotfile becomes especially useful. Instead of copying and pasting each command individually, we can automate and run all of them in one go.

Let’s walk through some examples

There are so many awesome things we can do in dotfiles. Here are some practical use cases that I rely on for my day-to-day work.

Setting aliases for default commands (.aliases)

Navigating between directories in the Terminal can be cumbersome and it’s easy to get lost in cd madness.

We can replace the standard “change directory" (cd) command with a custom command in the .aliases dotfile. For example, use this alias to ditch the cd prefix altogether when using the command cd .. to move up a directory in favor of .. by itself.

alias ..="cd .."

Sure, it’s only dropping two letters, but how much easier is that to remember?

We can do the same thing to make shortcuts to certain directories:

alias dl="cd ~/Downloads"

Or, create aliases for shorthand command tasks:

alias hs="hexo serve"

Oh, here’s another one! List only directories:

alias lsd="ls -lF ${colorflag} | grep --color=never '^d'" Make a custom bash prompt for a personal touch to the Terminal (.bash_prompt)

I referenced this a little earlier, but here’s how I turned my bash prompt ($) into a little dude that’s way more fun to look at it. This is done directly in the .bash_prompt dotfile.

PS1="? ? ?_? ??" Create Git shortcuts to speed up commits (.gitconfig)

We can make it a little more efficient to commit all changes at once in the .gitconfig dotfile. Using ca is a lot more concise than !git add -A && git commit -av .

ca = !git add -A && git commit -av

Another handy shortcut: find commits by commit message.

fm = "!f() { git log --pretty=format:'%C(yellow)%h %Cblue%ad %Creset%s%Cgreen [%cn] %Cred%d' --decorate --date=short --grep=$1; }; f" Automate common Homebrew tasks (brew.sh)

Use Homebrew for package management? Although not strictly a dotfile (it doesn’t have a dot before the file name), Homebrew gives us the brew.sh shell script file. This file automates the installation and management of Apps and Tools:

brew install git brew install tree brew cask install google-chrome brew cask install iterm2 brew cask install sublime-text Protect your Git credentials (.extra)

Hide information you don't want to share publicly in one file in a private repo and bring it in for you alone. For example, a good idea for this file is anything that’s specific to you, such as your Git credentials. This will prevent people from cloning, running your dotfiles, then committing as you!

# Git credentials # Not in the repository, to prevent people from accidentally committing under my name GIT_AUTHOR_NAME="Simon Owen" GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" git config --global user.name "$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="<ADD-YOUR-EMAIL-HERE>" GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" git config --global user.email "$GIT_AUTHOR_EMAIL" Write custom functions for tasks (.functions)

Dotfiles are more than shortcuts and aliases. We can also make custom functions in .functions that do more advanced lifting. For example, create a new directory and change directory to it:

function mkd() { mkdir -p "$@" && cd "$_"; }

Or, we can open a given location in Finder with a one-letter command (o):

function o() { if [ $#-eq 0 ]; then open .; else open "$@"; fi; } Specify your $PATH and keep private (.path)

$PATH allows the running of executable files. Instead of navigating to each path manually in Terminal, here we can set the file paths so they can run the executable files directly. It might be the case that this file contains sensitive information. As such, this file is often kept in a private repo.

Here’s an example adding ~/utils to the $PATH:

export PATH="$HOME/utils:$PATH" Force Vim to use a particular theme (.vimrc)

Editor config files are great for ensuring consistent formatting across projects, but we can also tell a Vim editor to use a specific theme in a .vimrc file:

" Use the Solarized Dark theme set background=dark colorscheme solarized let g:solarized_termtrans=1 Bonus: Helpful Terminal recipes for macOS

OK, so here’s a little bit of a bonus for Mac users that isn’t related to dotfiles, but are things we can do in the Terminal to give macOS superpowers to do pretty awesome things that make day-to-day use a little easier and more pleasant.

First off, we can show hidden files by default in the Finder so dotfiles are visible all the time by typing this into the Terminal:

defaults write com.apple.finder AppleShowAllFiles -bool true

Find the way that scrollbars toggle on and off in Finder jarring? Let’s make them visible at all times:

defaults write NSGlobalDomain AppleShowScrollBars -string "Always"

By default, macOS checks for software updates once per week. But maybe we want to check once a day or at some other interval:

defaults write com.apple.SoftwareUpdate ScheduleFrequency -int 1

You know how holding down on a keyboard key repeats that character? Well, it repeats at a determined speed that we can supercharge to blazingly fast:

defaults write NSGlobalDomain KeyRepeat -int 0

Some people love the way macOS includes a box shadow when taking a screenshot of a window. Others don’t. Here’s how to turn it off:

defaults write com.apple.screencapture disable-shadow -bool true

And, in this example, we can automate the size of icons in the Dock:

defaults write com.apple.dock tilesize -int 36

This is only the tip of the iceberg! In my screencast series I go over more than one hundred of them.

Conclusion

Web development is increasingly more complicated as time goes on. We all have ways of making our development workflow a little easier and comfortable based on personal preferences.

You may be a seasoned developer and aware of such things as Node, npm, and Git but still find yourself stuck in a Terminal window with a bunch of errors. Or, you might be starting out and find these, and other tools, complex and tough to grasp.

Either way, hopefully knowing more about dotfiles and what they’re capable of doing gives you a new weapon in your arsenal to make your development environment tailored to you, speed up your workflow and give your machine added superpowers!

As a reminder, my screencast series will give you more tips and tricks, plus a good idea of how to get your development environment set up. This is the first in the series. Going forwards, I'm going to look at expanding on it, so please let me know if there's anything else you'd like me to cover!

The post Using Dotfiles for Managing Development and Many Other Magical Things appeared first on CSS-Tricks.

Revisiting the abbr element

Css Tricks - Thu, 02/07/2019 - 10:58am

An irresistible HTML element deep dive from Ire Aderinokun, this time on the <abbr title=""> element for abbreviations. You can kinda just use it (JUI) and it works fine, but if you're hoping to make a tooltip for them (which works on touchscreens as well), then it's much more complicated.

The end result is leaving the semantic HTML alone and progressively enhancing with ~50 lines of JavaScript that adds interactive wrapper elements and event handlers.

I feel like this is the perfect sort of thing to be made into a web component that could/should be widely distributed for use. Maybe a <a11y-abbr> component or something. Can you have web components extend other native HTML elements though? If not, I guess it's kinda falling back to what is essentially a <span>, so maybe that's not ideal.

Dare I say it, this is also the kind of thing where React can excel. For example, I use Reach Router, and by default, when creating links (<Link>s that turn into <a>s), they get the proper aria-current attribute when it's the current page. That's good accessibility you're getting for free because the library was good enough to get that detail right. As much as libraries like React get pointed at for problematic accessibility, there is a lot of potential for accessibility improvements through abstraction. Sort of like the way Brad Frost has been enforcing accessibility best practices in React components.

Direct Link to ArticlePermalink

The post Revisiting the abbr element appeared first on CSS-Tricks.

Come to An Event Apart in 2019

Css Tricks - Thu, 02/07/2019 - 8:56am

The 2019 season for An Event Apart (the premiere web and interaction design conference) is about to kick off!

  1. Seattle - March 4–6, 2019
  2. Boston - May 6–8, 2019
  3. Washington DC - July 29–31, 2019
  4. Chicago - August 26–28, 2019
  5. Denver - October 28–30, 2019
  6. San Francisco - December 9–11, 2019

I'll be there in Seattle for the kickoff, giving a talk about how to think like a front-end developer. I've been working on it for ages, and I think I have a talk ready that helps set the stage for where we are at in the world of front-end development, through the lens of tons of other front-end developers I admire in this industry. I hope it'll be an entertaining romp through all their minds and how they think.

Just check out this Seattle lineup!

This is like my dream lineup. Except that jerk who kicks off Day 2.

  1. Jeffrey Zeldman
    The Zen of Whitespace: Slow Design for an Anxious World
  2. Margot Bloomstein
    Designing for Slow Experiences
  3. Sarah Parmenter
    Designing for Personalities
  4. Eric Meyer
    Generation Style
  5. Rachel Andrew
    Making Things Better: Redefining the Technical Possibilities of CSS
  6. Jen Simmons
    Designing Intrinsic Layouts
  7. Chris Coyier (me!!!)
    How to Think Like a Front-End Developer
  8. Una Kravets
    From Ideation to Iteration: Design Thinking for Work and for Life
  9. Scott Jehl
    Move Fast and Don’t Break Things
  10. Luke Wroblewski
    Mobile Planet
  11. Beth Dean
    Unsolved Problems
  12. Dan Mall
    Putting the ‘Design’ in Design Systems
  13. Jeremy Keith
    Going Offline
  14. Sarah Drasner
    Animation on the Bleeding Edge
  15. Val Head
    Making Motion Inclusive
  16. Derek Featherstone
    Inclusive, by Design
  17. Gerry McGovern
    The Customer-Obsessed Professional

Another neat little feature of the 2019 lineup is a screening of the documentary Rams that after lunch on Day 2. Like movie night. For us designer types. During the day. It's gonna be awesome.

See y'all there, I hope!

The post Come to An Event Apart in 2019 appeared first on CSS-Tricks.

Where Do You Learn HTML & CSS in 2019?

Css Tricks - Thu, 02/07/2019 - 5:59am

The topic of how accessible it is for newbies and seasoned developers alike to learn CSS has been gaining steam as the complexity of the tools around it has become skewed more toward traditional programming. Rachel Andrew has much more to say about this in her post, HTML, CSS and our vanishing industry entry points. Robin also has thoughts on where and how to learn CSS in the modern age.

The question of how and where to learn CSS is a highly reasonable thing to ask. The answer depends on all sorts of things: how serious you are, your current foundation, what other resources are available to you, what you hope to do with what you learn, and how much time you have, among probably a zillion other things.

Let me dump a bunch of possible answers here and you can apply all those “well, that depends” caveats as you see fit.


Books




Our Guide



Other Guides



Web Courses



School



CodePen



Build



Combo

You could read a book.

There are a ton of books out there that cover HTML and CSS (and often together). They probably all do a fine job. There’s no need to chronicle all the choices here. These two are my personal recommendations. You probably don't even need both.

Jon Duckett's is incredibly well-designed and approachable:

amzn_assoc_tracking_id = "csstricks-20"; amzn_assoc_ad_mode = "manual"; amzn_assoc_ad_type = "smart"; amzn_assoc_marketplace = "amazon"; amzn_assoc_region = "US"; amzn_assoc_design = "enhanced_links"; amzn_assoc_asins = "1118871642"; amzn_assoc_placement = "adunit"; amzn_assoc_linkid = "bb95f12e1b39017003194cc0206c7266";

Jennifer Robbins' covers a bit more ground and is designed to be useful for either personal reading or classroom learning.

amzn_assoc_tracking_id = "csstricks-20"; amzn_assoc_ad_mode = "manual"; amzn_assoc_ad_type = "smart"; amzn_assoc_marketplace = "amazon"; amzn_assoc_region = "US"; amzn_assoc_design = "enhanced_links"; amzn_assoc_asins = "1491960205"; amzn_assoc_placement = "adunit"; amzn_assoc_linkid = "f0709f0b76c052fa5eeacc12376cdede";

You could read through all the posts in our Beginner's Guide.

We have a guide (a collection of articles, videos, and links) called Just Starting Out with CSS & HTML. I hope there is stuff in there that can help kickstart or augment your early learning because that’s the intent.

You could go through other free online guides.

freeCodeCamp is probably the biggest and best out there. Definitely check them out.

Oliver James has a wonderful online course called Internetting is Hard (But it doesn't have to be).

We designed HTML & CSS Is Hard to be the only introduction to HTML and CSS that you’ll ever need. If you put in the effort to read every section and write every code snippet, this tutorial has the potential to replace hundreds or even thousand of dollars worth of online courses and live training.

Prefer video? Jessica Hische and Russ Maschmeyer's Don't Fear the Internet is a super eight-part series that gets you going with HTML & CSS — it even delves into the all-important topic of typography.

Khan Academy has an Intro to HTML/CSS: Making webpages course that’s packaged in a super cool format. It's like video in that you get to hear the instructor talk you through the learning, but what you see is a real live text editor and real live output. Sometimes the teacher is controlling the code, and then sometimes it breaks for challenges in which you take over and edit the code yourself.

Eric Tirado has an Intro to HTML course on Scrimba, which is also a neat platform in that Eric's voice guides you through the course, but visually it's a combination of slides with a real code editor and preview.

You could find and take a paid online course.

I often join gyms because the accountability of paying for something gets me to do it. I know I can do situps, pushups, and go for a jog for free, but the gym membership makes a thing of it. Well, same could be said about paying for a course on HTML and CSS.

These are broad generalizations, but good places to start:

You could go to a code school or coding bootcamp

If you wanna put even more skin in the game, you could consider literally going to school. If you don't have a college degree, that's an option, although you'll be looking at a broad education rather than a ticket to leveling up your web design and development skills alone. I'm a fan of that just for the general mind-broadening it involves.

But assuming you're going to go to a coding-specific school...

There are probably dozens — if not hundreds — more, so this is more to inform you of the possibility of schooling. You don't even have to go to a physical school since plenty of these offer online courses, too (but with the advantage of live instruction and cohorts). For example, LambdaSchool has the novelty of being free to start and paid later in the form of letting them take a portion of your salary after you get a job in the industry.

You could practice on CodePen.

Not every second of your learning should be strictly following some course laid out by a book, class, or teacher. It wouldn’t even be that way if you tried. You might as well embrace that. If something tickles your muse, go play! I hope CodePen is a rewarding place to do that, making it both easy and useful, while providing a place to connect with other folks in the field.

You could build a personal site and learn what you need to get it done.

That's how absolutely countless developers have cut their teeth, including me. I wanted a personal website years ago, and I struggled through getting a self-hosted WordPress site online so I could have full control over everything and bend it to my will. Once you have an actual website online, and you know at least some people are seeing it, it gives you all the motivation in the world to keep going and evolve further.

The way you actually learn is going to be a combination of all this stuff.

People are obsessed with asking musicians if they’re self-taught. Like, if they are, their amazingness triples because it means their creative genius was delivered by a lightning bolt at birth. They don't need anyone else to learn; they merely look at those guitar strings and know what to do.

And if they were taught by a teacher, then, well, that's all out the door. If they are good at all, then it's because the teacher delivered that to them.

Total nonsense.

People learn anything — music and web development included — inside a hurricane of influences. Let’s stick with music for a second. Learning to play comes in many forms. You learn by listening to music an awful lot. You can do fundamental practice, like finger exercises and going up and down scales. You can learn to transpose chords on a chalkboard. You can watch YouTube all day and night. You can sign up for online courses. You can go to local jams to watch and play along. You can join a band. You can take lessons from someone advertising on Craigslist. You can go to a local music school. You can read books about music.

You get the idea.

You can and probably will do all of that. With learning web design and development, getting anywhere will involve all sorts of ways. There’s no silver bullet. It takes bashing on it lots of different ways. There’s no requirement to sprinkle money on it, but you do need multiple angles, time, and motivation.

Go forth and build websites, the ol' ShopTalk mantra!

The post Where Do You Learn HTML & CSS in 2019? appeared first on CSS-Tricks.

HTML, CSS and our vanishing industry entry points

Css Tricks - Thu, 02/07/2019 - 5:58am

Rachel Andrew:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

That’s the real entry point here and yes, in 2019 they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.

Speaking of entry points, I compiled a bunch of ideas for how and where to learn HTML and CSS for the present day.

Direct Link to ArticlePermalink

The post HTML, CSS and our vanishing industry entry points appeared first on CSS-Tricks.

Animate a Blob of Text with SVG and Text Clipping

Css Tricks - Wed, 02/06/2019 - 5:36am

I came across this neat little animation in a designer newsletter — unfortunately, I lost track of the source, so please give a shout out if you recognize it! In it, a block of text appears to bleed into view with a swirl of colors, then goes out the same way it came in. It’s a slick effect and one I wanted to recreate in code.

The approach I took was to use SVG text as a clip path for an SVG background. We must use SVG text because CSS currently only allows us to animate the background with text clipping if the background is a GIF, which we’re not going to do.

Our first task is to create a background of different SVG shapes. Oval-y blobs work pretty well. The thing to make sure of is to match the size the artboard/canvas in whatever illustration app you’re using to the same dimension as the viewBox you want the final work to be. (In Inkscape, this option is under the Scale section of Document Properties.)

The goal is to cover most of the artboard with a variety of shapes. I've found that it looks best if some of the shapes overlap.

Next, we’ll create some text in a <clipPath>, group the objects that make up the background inside a <g> element, and apply a CSS clip-path on that group. Altogether it looks something like this:

<svg viewbox="0 0 700 225"> <clipPath id="textClip" class="filled-heading"> <text y="70">We are</text> <text y="140">Creators</text> <text y="210">+Innovators</text> </clipPath> <g id="background" clip-path="url(#textClip)"> <path d="m449.78..." /> </g> </svg>

At this point, all we get is some plain text because we haven’t gotten around to the background animation quite yet.

So what about that animation? We can use a relatively simple CSS animation like this:

/* Animate the background shapes */ #background path { animation: pulse 4s cubic-bezier(0.455, 0.030, 0.515, 0.955) infinite; /* Necessary to keep the SVG objects in place while scaling */ transform-origin: 50% 50%; transform-box: fill-box; } @keyframes pulse { /* Rotating it along with the scale makes it a little bit more fancy */ 0%, 100% { transform: scale(0) rotate(33deg); } 35%, 65% { transform: scale(1) rotate(0deg); } }

So far, so good.

?transform-box: fill-box; is not supported in Internet Explorer or Edge at this point, so if you need to support those browsers, you’ll need to use a JavaScript workaround, like this one.

See the Pen
Animated blob SVG text clipping effect - Pt. 1
by Zach Saucier (@Zeaklous)
on CodePen.

We could start painting things in by hard-coding color values using a text or vector editor, but it's more fun to color the shapes dynamically. Something like this:

// Define an array of colors const colors = ['#f5a147','#51cad8','#112b39']; // Select the SVG paths var blobs = document.querySelectorAll("path"); // Randomly apply colors to the SVG fill property blobs.forEach(blob => { blob.style.fill = colors[Math.floor(Math.random() * colors.length)]; });

In order to change the text values for each iteration, we need to first add them to the SVG clip path.

<clipPath id="text" class="filled-heading"> <text y="70">We are</text> <text y="140">Creators</text> <text y="210">+Innovators</text> <text y="70">We are</text> <text y="140">Movers</text> <text y="210">+Shakers</text> <text y="70">We are</text> <text y="140">Stylish</text> <text y="210">+Techy</text> </clipPath>

Then we can either use CSS or JavaScript to reveal the lines of text in our preferred order. Unfortunately, we can't surround each section of <text> using a <g> element because <g> elements don't work inside of a clipPath. For this post, we’re going to split things up into three CSS animations, one for each group of three paths:

/* Selects paths 1-3 */ #textClip text:nth-of-type(n + 1):nth-of-type(-n + 3) { animation: showFirst 12s infinite; } /* Selects paths 4-6 */ #textClip text:nth-of-type(n + 4):nth-of-type(-n + 6) { animation: showSecond 12s infinite; } /* Selects paths 7-9 */ #textClip text:nth-of-type(n + 7):nth-of-type(-n + 9) { animation: showThird 12s infinite; } @keyframes showFirst { 0%, 33% { opacity: 1; } 33.0001%, 100% { opacity: 0; } } @keyframes showSecond { 33.0001%, 66% { opacity: 1; } 0%, 33%, 66.0001%, 100% { opacity: 0; } } @keyframes showThird { 66.0001%, 99.999% { opacity: 1; } 0%, 66%, 100% { opacity: 0; } }

That does the trick!

See the Pen
Animated blob SVG text clipping effect - Pt. 2
by Zach Saucier (@Zeaklous)
on CodePen.

At this point, we can have a little fun. For example, we can swap backgrounds for a different effect. I used Inkscape's star tool with three to four points to generate some random shapes (using Inkscape’s random parameter) and then colored them using a palette from one of the many color scheme generators (I used Palx) to produce this version:

See the Pen
Animated blob SVG text clipping effect - Pt. 3
by Zach Saucier (@Zeaklous)
on CodePen.

The backgrounds don't even need to fill up the entire background, depending on the effect that we want to create. For example, we could duplicate the text using a element and fill in the text using that as seen in this demo.

Or we could mix it up by rotating the background blobs like this:

See the Pen
Animated blob SVG text clipping effect - Pt. 5
by Zach Saucier (@Zeaklous)
on CodePen.

To make the colors change for every new set of words, we could use either a CSS or JavaScript for the animation. I used JavaScript (and moved the CSS animation that was hiding the text lines to the JavaScript):

See the Pen
Animated blob SVG text clipping effect - Pt. 6
by Zach Saucier (@Zeaklous)
on CodePen.

To center the text horizontally, add x="50%" text-anchor="middle" to each <text> element (Demo). Centering it vertically would take more manual calculation since we’re working with a multi-line format.

One of the nice things about this approach is that, since it uses SVG, it is responsive by default!

P.S. After I made this approach and was looking for the original GIF author, I came across another recreation by Martí Fenosa doing the same effect using a different approach. Check his demo out as well because it’s clever!

The post Animate a Blob of Text with SVG and Text Clipping appeared first on CSS-Tricks.

Gradians and Turns: the quiet heroes of CSS angles

Css Tricks - Wed, 02/06/2019 - 5:34am

I love coming across little overlooked CSS gems, like the gradien (grad) and turn (turn) units that Ken Bellows uncovers in his post explaining them. I don't know, maybe y'all are already aware of them, but they're certainly new to me.

They're additional options for dealing with angles, where degrees (deg) and radians (rad) are more commonly known. I'm partial to degrees anytime I'm working with rotations. But now that I know there's an easier way to express a half rotation by using 0.5turn instead of 180deg, I can see myself reaching for turns much more often.

When you're designing an animation or thinking about how to add some rotation to your design, how are you thinking about it? You probably aren't thinking in numbers. ... You don't usually think in degrees or radians. You think in terms of full turns and portions of turns. At least, I do.

After looking at his table of comparisons, I take the point:

Degrees Radians Gradians Turns My Fav Unit 30deg 0.52rad 33.33grad 0.08turn Gradians 45deg 0.79rad 50grad 0.13turn Gradians 60deg 1.04rad 66.67grad 0.17turn Gradians 90deg 1.57rad 100grad 0.25turn Turns 180deg 3.14rad 200grad 0.5turn Turns 360deg 6.28rad 400grad 1turn Turns 720deg 12.56rad 800grad 2turn Turns 1080deg 25.12rad 1200grad 3turn Turns

Hear, hear! And since these units are supported back to IE 9, seems like something fun to try out.

(Hat tip to Rachel Andrew for sharing this in her awesome CSS Layout News email.)

Direct Link to ArticlePermalink

The post Gradians and Turns: the quiet heroes of CSS angles appeared first on CSS-Tricks.

Using the Little-Known CSS element() Function to Create a Minimap Navigator

Css Tricks - Tue, 02/05/2019 - 9:04am

W3C’s CSS Working Group often gives us brilliant CSS features to experiment with. Sometimes we come across something so cool that sticks a grin on our face, but it vanishes right away because we think, “that’s great, but what do I do with it?” The element() function was like that for me. It’s a CSS function that takes an element on the page and presents it as an image to be displayed on screen. Impressive, but quixotic.

Below is a simple example of how it works. It’s currently only supported in Firefox, which I know is a bummer. But stick with me and see how useful it can be.

<div id="ele"> <p>Hello World! how're you?<br>I'm not doing that<br>great. Got a cold &#x1F637;</p> </div> <div id="eleImg"></div> #eleImg { background: -moz-element(#ele) no-repeat center / contain; /* vendor prefixed */ }

The element() function (with browser prefix) takes the id value of the element it’ll translate into an image. The output looks identical to the appearance of the given element on screen.

When I think of element()’s output, I think of the word preview. I think that’s the type of use case that gets the most out of it: where we can preview an element before it’s shown on the page. For example, the next slide in a slideshow, the hidden tab, or the next photo in a gallery. Or... a minimap!

A minimap is a mini-sized preview of a long document or page, usually shown at on one side of the screen or another and used to navigate to a corresponding point on that document.

You might have seen it in code editors like Sublime Text.

The minimap is there on the right.

CSS element() is useful in making the “preview” part of the minimap.

Down below is the demo for the minimap, and we will walk through its code after that. However, I recommend you see the full-page demo because minimaps are really useful for long documents on large screens.

If you’re using a smartphone, remember that, according to the theory of relativity, minimaps will get super mini in mini screens; and no, that’s not really what the theory of relativity actually says, but you get my point.

See the Pen Minimap with CSS element() & HTML input range by Preethi Sam (@rpsthecoder) on CodePen.

If you’re designing the minimap for the whole page, like for a single page website, you can use the document body element for the image. Otherwise, targeting the main content element, like the article in my demo, also works.

<div id="minimap"></div> <div id="article"> <!-- content --> </div> #minimap { background: rgba(254,213,70,.1) -moz-element(#article) no-repeat center / contain; position: fixed; right: 10px; top: 10px; /* more style */ }

For the minimap’s background image, we feed the id of the article as the parameter of element() and, like with most background images, it’s styled to not repeat (no-repeat) and fit inside (contain) and at center of the box (center) where it’s displayed.

The minimap is also fixed to the screen at top right of the viewport.

Once the background is ready, we can add a slider on top of it and it will serve to operate the minimap scrolling. For the slider, I went with input: range, the original, uncomplicated, and plain HTML slider.

<div id="minimap"> <input id="minimap-range" type="range" max="100" value="0"> </div> #minimap-range { /* Rotating the default horizontal slider to vertical */ transform: translateY(-100%) rotate(90deg); transform-origin: bottom left; background-color: transparent; /* more style */ } #minimap-range::-moz-range-thumb { background-color: dodgerblue; cursor: pointer; /* more style */ } #minimap-range::-moz-range-track{ background-color: transparent; }

Not entirely uncomplicated because it did need some tweaking. I turned the slider upright, to match the minimap, and applied some style to its pseudo elements (specifically, the thumb and track) to replace their default styles. Again, we’re only concerned about Firefox at the moment since we’re dealing with limited support.

All that’s left is to couple the slider’s value to a corresponding scroll point on the page when the value is changed by the user. That takes a sprinkle of JavaScript, which looks like this:

onload = () => { const minimapRange = document.querySelector("#minimap-range"); const minimap = document.querySelector("#minimap"); const article = document.querySelector("#article"); const $ = getComputedStyle.bind(); // Get the minimap range width multiplied by the article height, then divide by the article width, all in pixels. minimapRange.style.width = minimap.style.height = parseInt($(minimapRange).width) * parseInt($(article).height) / parseInt($(article).width) + "px"; // When the range changes, scroll to the relative percentage of the article height minimapRange.onchange = evt => scrollTo(0, parseInt($(article).height) * (evt.target.value / 100)); };

The dollar sign ($) is merely an alias for getComputedStyle(), which is the method to get the CSS values of an element.

It’s worth noting that the width of the minimap is already set in the CSS, so we really only need to calculate its height. So, we‘re dealing with the height of the minimap and the width of the slider because, remember, the slider is actually rotated up.

Here’s how the equation in the script was determined, starting with the variables:

  • x1 = height of minimap (as well as the width of the slider inside it)
  • y1 = width of minimap
  • x2 = height of article
  • y2 = width of article
x1/y1 = x2/y2 x1 = y1 * x2/y2 height of minimap = width of minimap * height of article / width of article

And, when the value of the slider changes (minimapRange.onchange), that’s when the ScrollTo() method is called to scroll the page to its corresponding value on the article. &#x1f4a5;

Fallbacks! We need fallbacks!

Obviously, there are going to be plenty of times when element() is not supported if we were to use this at the moment, so we might want to hide the minimap in those cases.

We check for feature support in CSS:

@supports (background: element(#article)) or (background: -moz-element(#article)){ /* fallback style */ }

...or in JavaScript:

if(!CSS.supports('(background: element(#article)) or (background: -moz-element(#article))')){ /* fallback code */ }

If you don’t mind the background image being absent, then you can still keep the slider and apply a different style on it.

There are other slick ways to make minimaps that are floating out in the wild (and have more browser support). Here’s a great Pen by Shaw:

See the Pen
Mini-map Progress Tracker & Scroll Control
by Shaw (@shshaw)
on CodePen.

There are also tools like pagemap and xivimap that can help. The element() function is currently specced in W3C’s CSS Image Values and Replaced Content Module Level 4. Defintely worth a read to fully grasp the intention and thought behind it.

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

DesktopChromeOperaFirefoxIEEdgeSafariNoNo4*NoNoNoMobile / TabletiOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid FirefoxNoNoNoNoNo64*

Psst! Did you try selecting the article text in the demo? See what happens on the minimap. &#x1f609;

The post Using the Little-Known CSS element() Function to Create a Minimap Navigator appeared first on CSS-Tricks.

Bandwidth or Latency: When to Optimise for Which

Css Tricks - Tue, 02/05/2019 - 8:57am

Harry Roberts:

A good rule of thumb to remember is that, for regular web browsing, improvements in latency would be more beneficial than improvements in bandwidth, and that improvements in bandwidth are noticed more when dealing with larger files.

Direct Link to ArticlePermalink

The post Bandwidth or Latency: When to Optimise for Which appeared first on CSS-Tricks.

What Hooks Mean for Vue

Css Tricks - Mon, 02/04/2019 - 7:23am

Not to be confused with Lifecycle Hooks, Hooks were introduced in React in v16.7.0-alpha, and a proof of concept was released for Vue a few days after. Even though it was proposed by React, it’s actually an important composition mechanism that has benefits across JavaScript framework ecosystems, so we’ll spend a little time today discussing what this means.

Mainly, Hooks offer a more explicit way to think of reusable patterns — one that avoids rewrites to the components themselves and allows disparate pieces of the stateful logic to seamlessly work together.

The initial problem

In terms of React, the problem was this: classes were the most common form of components when expressing the concept of state. Stateless functional components were also quite popular, but due to the fact that they could only really render, their use was limited to presentational tasks.

Classes in and of themselves present some issues. For example, as React became more ubiquitous, stumbling blocks for newcomers did as well. In order to understand React, one had to understand classes, too. Binding made code verbose and thus less legible, and an understanding of this in JavaScript was required. There are also some optimization stumbling blocks that classes present, discussed here.

In terms of the reuse of logic, it was common to use patterns like render props and higher-order components, but we’d find ourselves in similar “pyramid of doom” — style implementation hell where nesting became so heavily over-utilized that components could be difficult to maintain. This led me to ranting drunkenly at Dan Abramov, and nobody wants that.

Hooks address these concerns by allowing us to define a component's stateful logic using only function calls. These function calls become more compose-able, reusable, and allows us to express composition in functions while still accessing and maintaining state. When hooks were announced in React, people were excited — you can see some of the benefits illustrated here, with regards to how they reduce code and repetition:

Took @dan_abramov's code from #ReactConf2018 and visualised it so you could see the benefits that React Hooks bring us. pic.twitter.com/dKyOQsG0Gd

— Pavel Prichodko (@prchdk) October 29, 2018

In terms of maintenance, simplicity is key, and Hooks provide a single, functional way of approaching shared logic with the potential for a smaller amount of code.

Why Hooks in Vue?

You may read through this and wonder what Hooks have to offer in Vue. It seems like a problem that doesn’t need solving. After all, Vue doesn’t predominantly use classes. Vue offers stateless functional components (should you need them), but why would we need to carry state in a functional component? We have mixins for composition where we can reuse the same logic for multiple components. Problem solved.

I thought the same thing, but after talking to Evan You, he pointed out a major use case I missed: mixins can’t consume and use state from one to another, but Hooks can. This means that if we need chain encapsulated logic, it’s now possible with Hooks.

Hooks achieve what mixins do, but avoid two main problems that come with mixins:

  • They allows us to pass state from one to the other.
  • They make it explicit where logic is coming from.

If we’re using more than one mixin, it’s not clear which property was provided by which mixin. With Hooks, the return value of the function documents the value being consumed.

So, how does that work in Vue? We mentioned before that, when working with Hooks, logic is expressed in function calls that become reusable. In Vue, this means that we can group a data call, a method call, or a computed call into another custom function, and make them freely compose-able. Data, methods, and computed now become available in functional components.

Example

Let’s go over a really simple hook so that we can understand the building blocks before we move on to an example of composition in Hooks.

useWat?

OK, here’s were we have, what you might call, a crossover event between React and Vue. The use prefix is a React convention, so if you look up Hooks in React, you’ll find things like useState, useEffect, etc. More info here.

In Evan’s live demo, you can see where he’s accessing useState and useEffect for a render function.

If you’re not familiar with render functions in Vue, it might be helpful to take a peek at that.

But when we’re working with Vue-style Hooks, we’ll have — you guessed it — things like: useData, useComputed, etc.

So, in order for us look at how we'd use Hooks in Vue, I created a sample app for us to explore.

Demo Site

GitHub Repo

In the src/hooks folder, I've created a hook that prevents scrolling on a useMounted hook and reenables it on useDestroyed. This helps me pause the page when we're opening a dialog to view content, and allows scrolling again when we're done viewing the dialog. This is good functionality to abstract because it would probably be useful several times throughout an application.

import { useDestroyed, useMounted } from "vue-hooks"; export function preventscroll() { const preventDefault = (e) => { e = e || window.event; if (e.preventDefault) e.preventDefault(); e.returnValue = false; } // keycodes for left, up, right, down const keys = { 37: 1, 38: 1, 39: 1, 40: 1 }; const preventDefaultForScrollKeys = (e) => { if (keys[e.keyCode]) { preventDefault(e); return false; } } useMounted(() => { if (window.addEventListener) // older FF window.addEventListener('DOMMouseScroll', preventDefault, false); window.onwheel = preventDefault; // modern standard window.onmousewheel = document.onmousewheel = preventDefault; // older browsers, IE window.touchmove = preventDefault; // mobile window.touchstart = preventDefault; // mobile document.onkeydown = preventDefaultForScrollKeys; }); useDestroyed(() => { if (window.removeEventListener) window.removeEventListener('DOMMouseScroll', preventDefault, false); //firefox window.addEventListener('DOMMouseScroll', (e) => { e.stopPropagation(); }, true); window.onmousewheel = document.onmousewheel = null; window.onwheel = null; window.touchmove = null; window.touchstart = null; document.onkeydown = null; }); }

And then we can call it in a Vue component like this, in AppDetails.vue:

<script> import { preventscroll } from "./../hooks/preventscroll.js"; ... export default { ... hooks() { preventscroll(); } } </script>

We're using it in that component, but now we can use the same functionality throughout the application!

Two Hooks, understanding each other

We mentioned before that one of the primary differences between hooks and mixins is that hooks can actually pass values from one to another. Let's look at that with a simple, albeit slightly contrived, example.

Let's say in our application we need to do calculations in one hook that will be reused elsewhere, and something else that needs to use that calculation. In our example, we have a hook that takes the window width and passes it into an animation to let it know to only fire when we're on larger screens.

In the first hook:

import { useData, useMounted } from 'vue-hooks'; export function windowwidth() { const data = useData({ width: 0 }) useMounted(() => { data.width = window.innerWidth }) // this is something we can consume with the other hook return { data } }

Then, in the second we use this to create a conditional that fires the animation logic:

// the data comes from the other hook export function logolettering(data) { useMounted(function () { // this is the width that we stored in data from the previous hook if (data.data.width > 1200) { // we can use refs if they are called in the useMounted hook const logoname = this.$refs.logoname; Splitting({ target: logoname, by: "chars" }); TweenMax.staggerFromTo(".char", 5, { opacity: 0, transformOrigin: "50% 50% -30px", cycle: { color: ["red", "purple", "teal"], rotationY(i) { return i * 50 } } }, ...

Then, in the component itself, we'll pass one into the other:

<script> import { logolettering } from "./../hooks/logolettering.js"; import { windowwidth } from "./../hooks/windowwidth.js"; export default { hooks() { logolettering(windowwidth()); } }; </script>

Now we can compose logic with Hooks throughout our application! Again, this is a contrived example for the purposes of demonstration, but you can see how useful this might be for large scale applications to keep things in smaller, reusable functions.

Future plans

Vue Hooks are already available to use today with Vue 2.x, but are still experimental. We’re planning on integrating Hooks into Vue 3, but will likely deviate from React’s API in our own implementation. We find React Hooks to be very inspiring and are thinking about how to introduce its benefits to Vue developers. We want to do it in a way that complements Vue's idiomatic usage, so there's still a lot of experimentation to do.

You can get started by checking out the repo here. Hooks will likely become a replacement for mixins, so although the feature still in its early stages, it’s probably a concept that would be beneficial to explore in the meantime.

(Sincere thanks to Evan You and Dan Abramov for proofing this article.)

The post What Hooks Mean for Vue appeared first on CSS-Tricks.

More Like position: tricky;

Css Tricks - Mon, 02/04/2019 - 5:20am

I rather like position: sticky;. It has practical use cases. I think of things like keeping a table of contents in a sidebar of a long article, but as a fairly simple implementation and without risk of overlapping things in awkward ways. But Elad Shechter is right here: it's not used that much — at least partially — and probably because it's a bit weird to understand.

I like how Elad explains it with a "Sticky Item" and a "Sticky Container." The container needs to be large enough that scrolling is relevant and for the stickiness to do anything at all.

There are other gotchas, too. I feel like every time I try position: sticky; in a real context, I have about a 30% chance of it working. There always seems to be some parent/child relationship thing that I can't quite work out to prevent overlaps. Or, there is some parent element with overflow: hidden;, which, for reasons unbeknownst to me, breaks this.

Direct Link to ArticlePermalink

The post More Like position: tricky; appeared first on CSS-Tricks.

React’s Experimental Suspense API Will Rock for Fallback UI During Data Fetches

Css Tricks - Sat, 02/02/2019 - 11:56am

Most web applications built today receive data from an API. When fetching that data, we have to take certain situations into consideration where the data might not have been received. Perhaps it was a lost connection. Maybe it was the endpoint was changed. Who knows. Whatever the issue, it's the end user who winds up with a big bag of nothing on the front end.

So we ought to account for that!

The common way of handling this is to have something like an isLoading state in the app. The value of isLoading is dependent on the data we want to receive. For example, it could be a simple boolean where a returned true (meaning we're still waiting on the data), we display a loading spinner to indicate that the app is churning. Otherwise, wee'll show the data.

Oh god, no!
&#x1f4f7; Credit: Jian Wei

While this isn‘t entirely bad, the awesome folks working on React have implemented (and are continuing to work on) a baked-in solution to handle this using a feature called Suspense.

Suspense sorta does what its name implies

You may have guessed it from the name, but Suspense tells a component to hold off from rendering until a condition has been met. Just like we discussed with isLoading, the rendering of the data is postponed until the API fetches the data and isLoading is set to false. Think of it like a component is standing in an elevator waiting for the right floor before stepping out.

At the moment, Suspense can only be used to conditionally load components that use React.lazy() to render dynamically, without a page reload. So, say we have a map that takes a bit of time to load when the user selects a location. We can wrap that map component with Suspense and call something like the Apple beachball of death to display while we're waiting on the map. then, once the map loads, we kick the ball away.

// Import the Map component const Map = React.lazy(() => import('./Map')); function AwesomeComponent() [ return ( // Show the <Beachball> component until the <Map> is ready <React.Suspense fallback={<Beachball />}> <div> <Map /> </div> </React.Suspense> ); }

Right on. Pretty straightforward so far, I hope.

But what if we want the fallback beachball, not for a component that has loaded, but when waiting for data to be returned from an API. Well, that's a situation Suspense seems perfectly suited for, but unfortunately, does not handle that quite yet. But it will.

In the meantime, we can put an experimental feature called react-cache (the package previously known as simple-cache-provider) to demonstrate how Suspense ought to work with API fetching down the road.

Let's use Suspense with API data anyway

OK, enough suspense (sorry, couldn‘t resist). Let's get to a working example where we define and display a component as a fallback while we're waiting for an API to spit data back at us.

Remember, react-cache is experimental. When I say experimental, I mean just that. Even the package description urges us to refrain from using it in production.

Here's what we're going to build: a list of users fetched from an API.

Get Source Code

Alright, let's begin!

First, spin up a new project

Let's start by generating a new React application using create-react-app.

## Could be any project name create-react-app csstricks-react-suspense

This will bootstrap your React application. Because the Suspense API is still a work in progress, we will make use of a different React version. Open the package.json file in the project's root directory, edit the React and React-DOM version numbers, and add the simple-cache-provider package (we'll look into that later). Here's what that looks like:

"dependencies": { "react": "16.4.0-alpha.0911da3", "react-dom": "16.4.0-alpha.0911da3", "simple-cache-provider": "0.3.0-alpha.0911da3" }

Install the packages by running yarn install.

In this tutorial, we will build the functionality to fetch data from an API. We can use the createResource() function from simple-cache-provider to do that in the src/fetcher.js file:

import { createResource } from 'simple-cache-provider'; const sleep = (duration) => { return new Promise((resolve) => { setTimeout(() => { resolve() }, duration) }) } const loadProfiles = createResource(async () => { await sleep(3000) const res = await fetch(`https://randomuser.me/api/?results=15`); return await res.json(); }); export default loadProfiles

So, here's what's happening there. The sleep() function blocks the execution context for a specific duration, which will be passed as an argument. The sleep() function is then called in the loadProfiles() function to stimulate a delay of three seconds (3,000ms). By using createResource() to make the API call, we either return the resolved value (which is the data we are expecting from the API) or throw a promise.

Next, we will create a higher-order component called withCache that enable caching on the component it wraps. We'll do that in a new file called, creatively, withCache.js. Go ahead and place that in the project's src directory.

import React from 'react'; import { SimpleCache } from 'simple-cache-provider'; const withCache = (Component) => { return props => ( <SimpleCache.Consumer> {cache => <Component cache={cache} {...props} />} </SimpleCache.Consumer> ); } export default withCache;

This higher-order component uses SimpleCache from the simple-cache-provider package to enable the caching of a wrapped component. We'll make use of this when we create our next component, I promise. In the meantime, create another new file in src called Profile.js — this is where we'll map through the results we get from the API.

import React, { Fragment } from 'react'; import loadProfiles from './fetcher' import withCache from './withCache' // Just a little styling const cardWidth = { width: '20rem' } const Profile = withCache((props) => { const data = loadProfiles(props.cache); return ( <Fragment> { data.results.map(item => ( <div key={item.login.uuid} className="card" style={cardWidth}> <div> <img src={item.picture.thumbnail} /> </div> <p>{item.email}</p> </div> )) } </Fragment> ) }); export default Profile

What we have here is a Profile component that's wrapped in withCache the higher-order component we created earlier. Now, whatever we get back from the API (which is the resolved promise) is saved as a value to the data variable, which we've defined as the props for the profile data that will be passed to the components with cache (props.cache).

To handle the loading state of the app before the data is returned from the API, we'll implement a placeholder component which will render before the API responds with the data we want.

Here's what we want the placeholder to do: render a fallback UI (which can be a loading spinner, beach ball or what have you) before the API responds, and when the API responds, show the data. We also want to implement a delay (delayMs ) which will come in handy for scenarios where there's almost no need to show the loading spinner. For example; if the data comes back in less than two seconds, then maybe a loader is a bit silly.

The placeholder component will look like this;

const Placeholder = ({ delayMs, fallback, children }) => { return ( <Timeout ms={delayMs}> {didTimeout => { return didTimeout ? fallback : children; }} </Timeout> ); }

delayMs, fallback and children will be passed to the Placeholder component from the App component which we will see shortly. The Timeout component returns a boolean value which we can use to either return the fallback UI or the children of the Placeholder component (the Profile component in this case).

Here's the final markup of our App, piecing together all of the components we've covered, plus some decorative markup from Bootstrap to create a full page layout.

class App extends React.Component { render() { return ( <React.Fragment> // Bootstrap Containers and Jumbotron <div className="App container-fluid"> <div className="jumbotron"> <h1>CSS-Tricks React Suspense</h1> </div> <div className="container"> <div> // Placeholder contains Suspense and wraps what needs the fallback UI <Placeholder delayMs={1000} fallback={ <div className="row"> <div className="col-md"> <div className="div__loading"> <Loader /> </div> </div> </div> } > <div className="row"> // This is what will render once the data loads <Profile /> </div> </Placeholder> </div> </div> </div> </React.Fragment> ); } } That's a wrap

Pretty neat, right? It's great that we're in the process of getting true fallback UI support right out of the React box, without crafty tricks or extra libraries. Totally makes sense given that React is designed to manage states and loading being a common state to handle.

Remember, as awesome as Suspense is (and it is really awesome), it is important to note that it's still in experimental phase, making it impractical in a production application. But, since there are ways to put it to use today, we can still play around with it in a development environment all we want, so experiment away!

Folks who have been working on and with Suspense have been writing up their thoughts and experience. Here are a few worth checking out:

The post React’s Experimental Suspense API Will Rock for Fallback UI During Data Fetches appeared first on CSS-Tricks.

Well, Typetura seems fun

Css Tricks - Fri, 02/01/2019 - 11:17am

I came across this update from Scott Kellum's and Sal Hernandez's project Typetura via my Medium feed this morning, and what a delight?!

(Also, wow, I really have been out of the game for a minute.)

Typetura.js is a fluid design solution, for any property, based on any input. It’s not for just typography across screen sizes. Transition between anything — width, height, scroll position, cursor position, and more.https://t.co/EoouX0PkGC

— typetura (@typetura) January 18, 2019

This is quite exciting! Typetura wants to deal with some of the main problems that come up when utilizing fluid type in your CSS.

> Typetura is a fluid typesetting tool. Use the slider at the top of the screen to select the breakpoint you want to style, then use the panel on the left of the screen to style your page.https://t.co/6cjgdEylwY

— CSS-Tricks (@css) November 22, 2018

Typetura was created to make fluid typography mainstream. To do this there were two problems to solve. First, develop an implementation that is feature rich and easy to implement with CSS. Second, create a design tool that designers can use to illustrate how they want fluid typography to look.

I love a tool that tries to remove friction and make technologies easier to use.

To ensure the implementation was easy to use and understand, Typetura needed a simple, declarative syntax in vanilla CSS. This means no complicated math or Sass tricks.

Design software is constructed around fixed art boards, but there needs to be a way for designers to communicate how designs transition between sizes... Typetura is a tool that enables designers to work with a fluid canvas.

You can also
remix on @glitchhttps://t.co/o3yr7Hsbki
edit on @CodePenhttps://t.co/k4Oy1OLT71
or read on @Mediumhttps://t.co/WcgzHCgBrf

— typetura (@typetura) January 31, 2019

Direct Link to ArticlePermalink

The post Well, Typetura seems fun appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.