Web Standards

WordCamp US 2018

Css Tricks - Fri, 01/04/2019 - 4:43am

I recently attended and had the chance to speak at WordCamp US 2018 in Nashville. I had a great time. I love conferences that bring people together around a tight theme because it's very likely you'll have something to talk about with every person there. Plus, I rather like WordPress and its community. The vibe was very centered around Gutenberg, as it was released in WordPress 5.0 just as the conference started.

Matt's State of the Word gets into all that:

I took the opportunity to give a brand new talk I've been working on I've called, “Thinking Like a Front-End Developer”:

There were loads of wonderful people there and loads of wonderful talks. Here's a playlist!

The post WordCamp US 2018 appeared first on CSS-Tricks.

The Elements of UI Engineering

Css Tricks - Fri, 01/04/2019 - 4:42am

I really enjoyed this post by Dan Abramov. He defines his work as a UI engineer and I especially like what he writes about his learning experience:

My biggest learning breakthroughs weren’t about a particular technology. Rather, I learned the most when I struggled to solve a particular UI problem. Sometimes, I would later discover libraries or patterns that helped me. In other cases, I’d come up with my own solutions (both good and bad ones).

It’s this combination of understanding the problems, experimenting with the solutions, and applying different strategies that led to the most rewarding learning experiences in my life. This post focuses on just the problems.

He then breaks those problems down into a dozen different areas: consistency, responsiveness, latency, navigation, staleness, entropy, priority, accessibility, internationalization, delivery, resilience, and abstraction. This is a pretty good list of what a front-end developer has to be concerned about on a day-to-day basis, but I also feel like this is perhaps the best description of what I believe my own skills are besides being “the person who cares about component design and CSS.”

I also love what Dan has to say about accessibility:

Inaccessible websites are not a niche problem. For example, in UK disability affects 1 in 5 people. (Here’s a nice infographic.) I’ve felt this personally too. Though I’m only 26, I struggle to read websites with thin fonts and low contrast. I try to use the trackpad less often, and I dread the day I’ll have to navigate poorly implemented websites by keyboard. We need to make our apps not horrible to people with difficulties — and the good news is that there’s a lot of low-hanging fruit. It starts with education and tooling. But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought?

This is a good reminder that front-end development is not a problem to be solved, except I reckon Dan’s post is more helpful and less snarky than my take on it.

Anywho, we all want accessible interfaces so that every browser can access our work making use of beautiful and consistent mobile interactions, instantaneous performance, and a design system teams can utilize to click-clack components together with little-to-no effort. But these things are only possible if others recognize that UI and front-end development are a worthy fields.

Direct Link to ArticlePermalink

The post The Elements of UI Engineering appeared first on CSS-Tricks.

Multi-Line Inline Gradient

Css Tricks - Thu, 01/03/2019 - 5:17am

Came across this thread:

CSS superfriends! Have you seen examples of how to do multi-line padded text like this article on @css (https://t.co/2j8p4jmaT4), but with a gradient that doesn't reset for each line? pic.twitter.com/MVPdAjxt1W

— Dan Mall (@danmall) December 3, 2018

My first thought process was:

But it turns out we need a litttttle extra trickery to make it happen.

If a solid color is fine, then some padding combined with box-decoration-break should get the basic framework:

See the Pen Multiline Padding with box-decoration-break by Chris Coyier (@chriscoyier) on CodePen.

But a gradient on there is gonna get weird on multiple lines:

See the Pen Multiline Padding with box-decoration-break by Chris Coyier (@chriscoyier) on CodePen.

I'm gonna credit Matthias Ott, from that thread, with what looks like the perfect answer to me:

See the Pen Multiline background gradient with mix-blend-mode by Matthias Ott (@matthiasott) on CodePen.

The trick there is to set up the padded multi-line background just how you want it with pure white text and a black background. Then, a pseudo-element is set over the whole area with the gradient in the black area. Throw in mix-blend-mode: lighten; to make the gradient only appear on the black area. Nice one.

The post Multi-Line Inline Gradient appeared first on CSS-Tricks.

Jetpack

Css Tricks - Thu, 01/03/2019 - 5:14am

My favorite way to think about Jetpack is that it's a WordPress plugin that brings a whole heap of features to your site. I've documented the features that we use here on CSS-Tricks, which isn't even all of them (yet).

Some of Jetpack features are essentially connecting it to the powers of WordPress.com. For example, of course, WordPress.com has some amazing way to optimize and serve images. They can build a service that millions of sites on WordPress.com can benefit from, which really benefits everyone, including them, because optimized images reduce bandwidth costs. Then Jetpack steps in and can offer that same power to you on your self-hosted WordPress site. Here's a video I did showing how that works.

Other features are things like real-time backups of your site to VaultPress, which is incredibly important to me knowing I have every bit of this site backed up and under my control.

Because your site now lives within your WordPress.com dashboard, you get features there. I quite like the analytics dashboards, which seem more accessible to me than trying to poke around Google Analytics.

Another one I really like is the ability to manage WordPress plugins from there. I'm happing doing that in the admin of my own site as well, but from here, I can tell certain plugins to auto-update, which just saves me the minor hassle of doing it myself.

The post Jetpack appeared first on CSS-Tricks.

Quicklink

Css Tricks - Thu, 01/03/2019 - 4:59am

We're in the future now so, of course, we're working on ways to speed up the web with fancy new tactics above and beyond the typical make-pages-slimmer-and-cached-like-crazy techniques.

One tactic, from years ago, was InstantClick:

Before visitors click on a link, they hover over that link. Between these two events, 200 ms to 300 ms usually pass by (test yourself here). InstantClick makes use of that time to preload the page, so that the page is already there when you click.

Clever, but not as advanced as what can be done in these modern times. For instance, InstantClick doesn't take into account the fact that someone might not want to preload stuff they didn't explicitly ask for, especially if they are on a slow network.

Addy Osmani wrote up a document calling this "predictive fetching":

... given an arbitrary entry-page, a solution could calculate the likelihood a user will visit a given next page or set of pages and prefetch resources for them while the user is still viewing their current page. This has the possibility of improving page-load performance for subsequent page visits as there's a strong chance a page will already be in the user's cache.

Just think: we could feed analytics data into the mix and let machine learning chew away at it. Addy also points to other prior attempts, like Gatsby's Link and a WordPress plugin.

Another contender is Quicklink by Google:

Quicklink attempts to make navigations to subsequent pages load faster. It:

  • Detects links within the viewport (using Intersection Observer)
  • Waits until the browser is idle (using requestIdleCallback)
  • Checks if the user isn't on a slow connection (using navigator.connection.effectiveType) or has data-saver enabled (using navigator.connection.saveData)
  • Prefetches URLs to the links (using <link rel=prefetch> or XHR). Provides some control over the request priority (can switch to fetch() if supported).

No machine learning or analytics usage there, but perhaps the most clever yet. I really like the spirit of prefetching only when there is a high enough likelihood of usage; the browser is idle anyway, and the network can handle it.

Direct Link to ArticlePermalink

The post Quicklink appeared first on CSS-Tricks.

Storing and Using the Last Known Route in Vue

Css Tricks - Wed, 01/02/2019 - 5:19am

There are situations where keeping a reference to the last route a user visited can come in handy. For example, let’s say we’re working with a multi-step form and the user proceeds from one step to the next. It would be ideal to have the route of that previous step in hand so we know where the user left off, in the event that they navigate away and come back later to complete the form later.

We’re going to cover how to store the last known route and then fetch it when we need it. We’ll be working in Vue in this example and put vue-router to use for routing and localStorage to keep the information about last visited route.

Here’s an example of what we’ll be working with:

First, let’s outline the route structure

Our example has a grand total of three routes:

  • /home
  • /hello
  • /goodbye

Each route needs to be assigned a name property, so let’s add that to our router.js file:

// router.js import Vue from "vue"; import Router from "vue-router"; import Hello from "@/components/Hello"; import Goodbye from "@/components/Goodbye"; import { HELLO_URL, GOODBYE_URL } from "@/consts"; Vue.use(Router); const router = new Router({ mode: "history", routes: [ { path: "/", name: "home" }, { path: HELLO_URL, name: "hello", component: Hello }, { path: GOODBYE_URL, name: "goodbye", component: Goodbye } ] }); export default router; Next, let’s go over the requirements

We know the first requirement is to store the last visited route in localStorage. And, secondly, we need to be able to retrieve it. But what conditions should the route be fetched and applied? That gives us two additional requirements.

  • the user enters the main route (/home), navigates away from it, then wants to return to it.
  • the user has been inactive for a specific time period, the session expires, and we want to return the user to the last screen they were on after restarting the session.

These four requirements are what we need to meet in order to proceed with the redirection.

Now let’s jump into the code.

Requirement 1: Save the last route name in localStorage

We want to keep the reference to our last visited route in localStorage. For example, if a user is at /checkout and then leaves the site, we want to save that so the purchase can be completed later.

To do that, we want to save the route name when the user enters any new route. We’ll use a navigation guard called afterEach that’s fired each time the route transition is finished. It provides a to object which is the target Route Object. In that hook, we can extract the name of that route and save it in localStorage using a setItem method.

// router.js const router = new Router( ... ); router.afterEach(to => { localStorage.setItem(LS_ROUTE_KEY, to.name); }); ... export default router; Requirement 2: Fetch the last route name from localStorage and redirect

Now that the name of the last route is saved, we need to be able to fetch it and trigger a redirect to it when it’s needed. We want to check if we should redirect before we enter a new route, so we will use another navigation guard called beforeEach. This guard receives three arguments:

  • to: the target route object
  • from: the current route navigated from
  • next: the function that must be called in the guard to resolve the hook

In that guard, we read the name of the last visited route by using a localStorage.getItem() method. Then, we determine if the user should be redirected. At this point, we check that the target route (to) is our main route (/home) and if we do indeed have a last route in localStorage.

If those conditions are met, we fire the next method that contains the name of the last visited route. That, in turn, will trigger a redirect to that route.

If any condition fails, then we’ll fire next without any arguments. That will move the user on to the next hook in the pipeline and proceed with ordinary routing without redirection.

// router.js const router = new Router( ... ); router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const shouldRedirect = Boolean( to.name === "home" && lastRouteName ); if (shouldRedirect) next({ name: lastRouteName }); else next(); }); ... export default router;

That covers two out of four requirements! Let’s proceed with requirement number three.

Requirement 3: The first visit condition

Now, we need to check if the user is visiting the main route for the first time (coming from a different source) or is navigating there from another route within the application. We can do that by adding a flag that is set to true when the Router is created and set it to false after first transition is finished.

// router.js const router = new Router( ... ); let isFirstTransition = true; router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const shouldRedirect = Boolean( to.name === "home" && && lastRouteName && isFirstTransition ); if (shouldRedirect) next({ name: lastRouteName }); else next(); isFirstTransition = false; }); ... export default router;

OK, there is one more requirement we need to meet: we want to redirect the user to the last known route if the user has been inactive for longer that a specific period of time.

Requirement 4: The activity time condition

Again, we will use localStorage to keep the information about user’s last visited route.

In the beforeEach guard, we will get the route from localStorage and check if the time passed from that moment is within our threshold (defined by hasBeenActiveRecently). Then, in our shouldRedirect, we’ll determine whether a route redirect should happen or not.

We also need to save that information, which we will do in the afterEach guard.

// router.js const router = new Router( ... ); let isFirstTransition = true; router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const lastActivityAt = localStorage.getItem(LS_LAST_ACTIVITY_AT_KEY); const hasBeenActiveRecently = Boolean( lastActivityAt && Date.now() - Number(lastActivityAt) < MAX_TIME_TO_RETURN ); const shouldRedirect = Boolean( to.name === "home" && && lastRouteName && isFirstTransition && hasBeenActiveRecently ); if (shouldRedirect) next({ name: lastRouteName }); else next(); isFirstTransition = false; }); router.afterEach(to => { localStorage.setItem(LS_ROUTE_KEY, to.name); localStorage.setItem(LS_LAST_ACTIVITY_AT_KEY, Date.now()); }); ... export default router; We met the requirements!

That’s it! We covered all four of requirements, namely:

  • We store the last visited route in localStorage
  • We have a method to retrieve the last visited route from localStorage
  • We redirect a user back to the main route if they’re coming into the application on an initial visit
  • We provide the user with a redirect to the last known route within a certain time period

Of course, we can extend this further by adding more complexity to the app and new conditions to the shouldRedirect variable, but this gives us more than we need to have an understanding of how to keep the last visited route persistent and retrieve it when it’s needed.

The post Storing and Using the Last Known Route in Vue appeared first on CSS-Tricks.

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.