Front End Web Development

Run useEffect Only Once

Css Tricks - Tue, 07/30/2019 - 4:12am

React has a built-in hook called useEffect. Hooks are used in function components. The Class component comparison to useEffect are the methods componentDidMount, componentDidUpdate, and componentWillUnmount.

useEffect will run when the component renders, which might be more times than you think. I feel like I've had this come up a dozen times in the past few weeks, so it seems worthy of a quick blog post.

import React, { useEffect } from 'react'; function App() { useEffect(() => { // Run! Like go get some data from an API. }); return ( <div> {/* Do something with data. */} </div> ); }

In a totally isolated example like that, it's likely the useEffect will run only once. But in a more complex app with props flying around and such, it's certainly not guaranteed. The problem with that is that if you're doing something like fetching data from an API, you might end up double-fetching which is inefficient and unnecessary.

The trick is that useEffect takes a second parameter.

The second param is an array of variables that the component will check to make sure changed before re-rendering. You could put whatever bits of props and state you want in here to check against.

Or, put nothing:

import React, { useEffect } from 'react'; function App() { useEffect(() => { // Run! Like go get some data from an API. }, []); return ( <div> {/* Do something with data. */} </div> ); }

That will ensure the useEffect only runs once.

Note from the docs:

If you use this optimization, make sure the array includes all values from the component scope (such as props and state) that change over time and that are used by the effect. Otherwise, your code will reference stale values from previous renders.

The post Run useEffect Only Once appeared first on CSS-Tricks.

Lessons Learned from a Year of Testing the Web Platform

Css Tricks - Mon, 07/29/2019 - 1:18pm

Mike Pennisi:

The web-platform-tests project is a massive suite of tests (over one million in total) which verify that software (mostly web browsers) correctly implement web technologies. It’s as important as it is ambitious: the health of the web depends on a plurality of interoperable implementations.

Although Bocoup has been contributing to the web-platform-tests, or “WPT,” for many years, it wasn’t until late in 2017 that we began collecting test results from web browsers and publishing them to wpt.fyi

Talk about doing God's work.

The rest of the article is about the incredible pain of scaling a test suite that big. Ultimately Azure Pipelines was helpful.

Direct Link to ArticlePermalink

The post Lessons Learned from a Year of Testing the Web Platform appeared first on CSS-Tricks.

Getting design system customization just right

Css Tricks - Mon, 07/29/2019 - 4:32am

I had a little rant in me a few months ago about design systems: "Who Are Design Systems For?" My main point was that there are so many public and open source ones out there that choosing one can feel like choosing new furniture for your house. You just measure up what you need and what you like and pick one. But it just isn't that simple. Some are made for you, some makers want you to use them, and some just ain't.

A more measured take from Koen Vendrik (consistently, the same Koen who just made a cool Jest browser tool):

... it’s important that you first define who a design system is for and what people should be able to do with it. When you have decided this, and start looking at the implementation for the level of flexibility you require, keep in mind that it’s okay to do something that’s different from what’s already out there. It’s easy to create a lot of flexibility or none at all, the trick is to get it just right.

The levels:

  • Zero customizability. Sometimes this is the point: enforcing consistency and making it easy to use (no config).
  • Build your own (BYO) theme. The other end of the spectrum: do whatever you want, fully cusomizable.
  • Guided theme building. This is baby bear. Like changing preprocessor values to change colors, but it can get fancier.

Direct Link to ArticlePermalink

The post Getting design system customization just right appeared first on CSS-Tricks.

The Guardian digital design system

Css Tricks - Mon, 07/29/2019 - 4:32am

Here’s a fascinating look at The Guardian’s design system with a step-by-step breakdown of what's gone into it and what options are available to designers and developers. It shows us how the team treats colors, typography, layouts, and visual cues like rules and borders.

I’ve been struggling to think about how to describe design systems internally to folks and this is giving me a ton of inspiration right now. I like that this website has all the benefits of a video (great tone and lovely visuals) with all the benefits of a UI kit (by showing what options are available to folks).

This also loosely ties back into something Chris has been discussing lately, which is being mindful of knowing who a design system is for. Some are meant for internal use and others, some are meant for internal use but are openly available for people like contractors, and others are meant for varying degrees of external use. Here, The Guadian is not explicit about who their design system is for, but the description of it gives a pretty good hint:

A guide to digital design at the Guardian

So please, enjoy looking at this well-documented, highly interactive and gorgeous design system. At the same time, remember it's made for a specific use case and may not line up with all the needs of your project or organization. It sure is inspirational to look at, one way or the other!

Direct Link to ArticlePermalink

The post The Guardian digital design system appeared first on CSS-Tricks.

The first fashion books, Renaissance pixel fonts and the invention of graph paper

Typography - Sat, 07/27/2019 - 3:11am

Fashion is a global, multi-billion dollar industry. From haute couture to $5 tees, it is inescapable — at least for those of us who wear clothes, that is. It is supported and promoted by vast publishing enterprises of glossy magazines and books and million-dollar advertising budgets. And although, arguably, we might say that fashion got […]

The post The first fashion books, Renaissance pixel fonts and the invention of graph paper appeared first on I Love Typography.

Telling the Story of Graphic Design

Css Tricks - Fri, 07/26/2019 - 5:02am

Let me just frame this for you: we're going to take a piece of production UI from a Sketch file, break it down into pieces of information and then build it up into a story we tell our friends. Our friends might be hearing, or seeing, or touching the story so we are going to interpret and translate the same information for different people. We're going to interpret the colors and the typography and even the sizes, and express them in different ways. And we really want everyone to pay attention. This story mustn't be boring or frustrating; it's got to be easy to follow, understand and remember. And it's got to, got to, make sense, from beginning to end.

I've asked my colleague Katie to choose a component she has designed in Sketch. I'll go through and mark it up (we mainly use SCSS, Twig and Craft but the templating language is not very important), then she will respond briefly. Hopefully I'll get most of it right, and then one or two things wrong, so we can look at how things get lost during handoff.

In white label or framework type front-end, the focus is on building pieces that are as flexible and adaptable as possible, as content and style-agnostic as possible (within the scope of the product), because you simply will never know where the code is going and for what, ultimately it is being used. But recently I moved to a web design agency, which has a complete inversion of this focus. It is particular. It is bespoke. It's all about really deeply engaging with the particular client you have and the particular clients they have, and designing something that suits them, as a tailor would.

Working so closely with a graphic designer like Katie, with highly finished pixel-spaced UI, instead of directly from wireframes or stories is an adjustment and an education, but there are still lots of things I can bring to the table. Chiefly: document design.

Document design, which admittedly is just the old semantic web with an accessibility hat on, is really looking at graphic design, engaging with it as a system of communication, and translating the underlying purpose of the colors/type/layout into an accessible, linearizable, and traversable DOM. It's HTML, kids. It's just HTML. You'd think we all knew it by now… but look around you. You'd be wrong!

Katie has slung me a Sketch file chock full of artboards, and she's pretty great at writing out what she wants so I don't have to think too hard:

Event card

First I look through the whole UI file and figure out what is actually a card on this site — it turns out there are six or seven components that use this paradigm. Let's make some observations:

Zoom out on section of artboards Another card, classes this time.
  • A card is a block of meta data about a page on the site.
  • It has an image/media and metadata — it's a media object.
  • It's shown in a group of objects.
  • That group is always typed (there's no view where there are search results and news articles and classes are all mixed up).
  • Each object has a single link to a page and no other actions.
  • Each object has a call to action (Book, etc.).
  • Each object may have times, categories, badges, and calls to action.
  • Each object must have media, title, and link.

So a card is the major way my user is going to find their way around this site. They are going to be clicking through guided pathways where they get a set of cards they can choose from, based on top pages like "what's on" or "classes." They're not getting options on this card. It's not really an interactive element — it's a guide, an index card, that sets her onto her path: in this case a purchase path where she books a ticket for a show at this arts centre.

Before going on, let me just frame this for you:

Imagine you were looking at a flyer for a show and discussing it on the phone. If you actually wanted to go to this show in real life. What would you do? You wouldn't just read the flyer out, would you? That's the text. And it might have all kinds of random stuff on it if you started literally at the top. You wouldn't start with "Twentieth Century Fox" or "Buy Hot Dog Get Cola Free" or "Comedy Drama Musical Family Friendly." (I would actually hang up on you if you did!) And you wouldn't simply describe the color or fonts. That's the CSS. You'd talk through the information on the flyer. You'd say, "It's The Greatest Showman and it's on Tuesday, starts at 7:30. It's at the Odeon on Oxford Street by the tram." Right?

This is the document. Keep that person on the phone in your mind.

Count, group, and name

So let's say we'll deliver a card as the inside of a list item. We want a group and that group should be countable. We've already named the page with an <h1> so we'll introduce and describe the group with a heading, an <h2>. First we'll name it, then we'll deliver it, so someone using a screen reader can:

  1. Get the list signaled in the headings overview.
  2. Get a count up front of the number of items on a page.
  3. Know they can skip to the next list item to get the next card.
  4. Know they can skip the group at any point and go to the next page — the pagination is the very next element and it will be labelled as a landmark.

See the Pen
Cards delivered as a countable list with descriptive heading
by limograf (@Sally_McGrath)
on CodePen.

Anchor

In this particular case, I'm gonna wrap this whole card in an anchor element (<a>). There's only one link on the card and I want to front load that information so someone can click as soon as they know it's the right card, instead of having to search forward for the action. A big clickable area is nice too, though of course that can be taken too far and make an interface a sort of booby trap! But these cards are not too enormous and I can see they have a nice gutter around them, so there's a rest space that will reduce accidental clicking for people with more limited dexterity.

Title Event card "title" element

Then we'll jump down a heading level and mark up the name of each show as a heading, an <h3>. The designer has made this type the focus and we will too. Some people browse super fast by jumping to the next heading, then next heading, so I'm not going to put any important information before the heading — they'll jump right over it. I will put the image there, though, as I know in this case, I can't get meaningful image descriptions from the API so those images are hidden and have empty alt attributes. Now the user can guess (correctly in my case) that the developer is actually describing the content in some meaningful way and might flip back to headings overview (list headings level 3) and just get a list of the shows.

Now let's deliver our metadata. Let's list it:

  • Badge
  • Date/Time
  • Categories
Badge Event card "badge" element

This seems to be something the venue adds to a card to highlight it. As a developer, I can't immediately see why a user would look for this, but it's emphasized strongly by the designer, so I'll make sure it stays in. Katie has moved the badge up out of the flow, but I know that with a headings jump our user could miss it. So I'll just put the wording directly after the title, I think. I'll either put it first or last, so make it easier to account for in a non-visual browse and not be too crazy paving in a tabbing, visual browse.

<p class="c-card__badge"><abbr title="Harrow Arts Centre">HAC</abbr> Highlight.</p>

...But on second thought, I won't put an <abbr> after all. It's the brand color, so it's really a statement of ownership by this venue, and we've already said HAC a million times by now, so the user knows where they are.

<p class="c-card__badge">HAC Highlight </p>

See the Pen
Badge
by limograf (@Sally_McGrath)
on CodePen.

A quick aside: the 'badging' is very specific to this organisation. They want to show people clearly and quickly which events they've programmed themselves, and which are run by other organizations who've hired their venue. Date/Time Event card "date/time" element

Now date and time. Katie is keying me in to this decision point by styling the dates in bold. Dates are important. I'm going to pop it in an <h4>, because I'm thinking it looks like someone might be quickly scanning a page of events looking for the matinee, for example, or looking for a news article published on a particular day. I don't always put dates into headings, especially if there are millions on a page, but I do always make sure they're in a <time> element with a complete value so the <time>Thu</time> or <time>Mon</time> Katie has specified is read out as comprehensible English words "Thursday" instead of garblage. I could also have used hidden completion or <abbr> with a title.

Categories/ Tags Event card "categories/tags" element

Next come the categories, and I'm putting them after badge and date. This section is next in the visual order reading top-to-bottom, left-to-right, of course, but it also seems to be deprioritized: it's been pushed down on the left and the type is smaller. This works for our linear storytelling. As a rule, we don't want people to sit through repeated or more general content (cinema, cinema, cinema) to get to unique or more specific content (Monday, Tuesday, Wednesday). Remember, we are inside our card: we know it has already been sorted in a few general ways (news, show, class, etc), so it's likely to have a lot of repeated pieces. We want to ensure that the user will go from specific to general if we can.

There is a primary category that is sorted first and then some other categories sometimes. I won't deliver this as a countable list as there's mostly just one category, and loads of lists of one item is not much use. But I will put a little tag beforehand because otherwise, it's a slightly impenetrable announcement. MOVEMENT! SPOKEN WORD! (I mean, you can work it out retrospectively, but we always try to name things first and then show them, in linear order. This isn't Memento.) I used to use title="" fairly heavily but I've gotten complaints about the tooltip so I route around. Note the use of colon or full stop to give us a "breath." That's a nice bit of polish.

<p class="c-card__tags h-text--label> <span class="h-accessibility">Categories: </span> {% for category in categories.all() %} <span class="c-card__tag c-tag">{{category}}{% if not loop.last %} / {% endif %}</span> {% endfor %}</p>

Also I'm hard-coding in my spaces to make sure the categories never run together into complete garblage even with text compression or spaceless rendering turned on somewhere down the pipeline. (This can happen with screen readers and spans and it's rather alarming!)

There's a piece of this design I will do in the CSS but haven't really pulled into the document design: the color-coding on primary category. I am not describing the color to the reader as it seems arbitrary, not evocative. If there were some subtextual element to the color coding beyond tagging categories (if horticultural classes were green, say), then I might bring it through, but in this case it's a non-verbal key to a category, so we don't want it in our verbal key.

I'm sorting the primary category to the front of the category paragraph, but I'm not labeling it as primary. This is because there's a sorting filter before this list that sorts on primary category, and it's my surmise that it would be easier and less annoying to select a category from that dropdown than to read through each card saying Categories Primary Category Music Secondary Categories Dance. I could be wrong about that! Striking a balance between useful and too much labeling is sometimes a bit tricky. You have to consider the page context. We may be building components but our user is on a page.

See the Pen
Dummies in page context
by limograf (@Sally_McGrath)
on CodePen.

Action Event card "action" element

Last, the action. The direction to the user, to Book, or Learn More, or whatever it is, has been styled as a button. It's not actually a button, it's just a direction, so I'll mark it up as a span in this case. I definitely want this to come last in the linear document. It's a call to action and also a signal that we've reached the end of this card. The action is the exit point in both cases: if the user acts, we go to the target entry; if they do not, we go to the next card. We definitely never want any data to come after the action, as they might have left by then.

See the Pen
Card
by limograf (@Sally_McGrath)
on CodePen.

My conclusion

This markup, which counts, groups, and names data, delivers linear and non-linear interactions. The page makes sense if you read it top to bottom, makes sense if you read parts of it out of context, and helps you jump around.

Katie, over to you... Katie Parry, designer

What an ace article! Really interesting. (I particularly like that "Mon," "Tue," etc. on cards are read as "Monday," "Tuesday"... smart!)

One thing that struck me is that using assistive tech means users get information served to them in a "set" order that we've decided. So, unless there's a filter, someone browsing for dance events, for example, has to sit/tab through a title, badge, dates, and maybe several other categories to find out whether an event's for them or not. Bit tiresome. But that's not something you've got wrong — it's just how the internet works. Something for me to think about in the future.

Most of our clients are arts and cultural venues that need to sell tickets for events so I design a lot of event cards. They're one of the very first things I'll work on when designing a site. (Before even settling on a type hierarchy for the rest of the site.)

Thinking visually, here's how I'd describe the general conventions of an event card:

  • It must look like a list – so people understand how to use it.
  • It needs to provide enough information for folks to decide if they're interested or not. (The minimum information is likely an image, title, date, and link.)
  • It needs to include a clear call to action — usually a link to find out more information.
  • It needs to be easily scannable, visually.

Making information visually scannable is a pretty straightforward case of ensuring every information type (e.g. image, title, date, category, link) is sitting in the same place on every card and follows a clear hierarchy.

I focus a lot on typography in my work anyway but clearly: titles are styled to be highly prominent; dates are styled the same as each other but are different from titles; categories look different again – so that folks can easily pick-out the information they're interested in from simply scanning the page. I'm composing the card for the user, saying, "Hey, look here's the event's name, this is when it's on — and here's where you go to get your tickets!"

The type styles – and particularly the spacing between them – are doing a lot of work, so I will point out here that the spacings are not quite right in the code sample:

Spacing between the title and dates, dates and button, and button and piping don't match the design.

This is important. Users need to be able to scan information quickly as they aren't all looking for the same thing in order to make the decision to go to an event. Too much or too little space between elements can be distracting.

Here, let me tighten that up for you:

See the Pen
Card with accurate spacings
by limograf (@Sally_McGrath)
on CodePen.

Perfect!

Some people just want a general mooch at what's coming up at their local venue. Others may have seen an advert for a specific show that tickles their fancy, and want to buy tickets. There are people who love music but don't care for theatre who just want a list of gigs; nothing else. And some folks who feel like going out at the weekend but aren't that fussed about what it is they go to. So, I design cards to be easy to scan — because most users aren't at all reading from top to bottom.

Despite the conventions I just laid out, cards certainly don't all look the same — or work in the same way — across projects.

There is always a tension in web design between making an interface familiar to the user and original to the client. Custom typefaces and color palettes do a lot here, but the other piece of it is through discovery.

I spend time reading-up about a client, including who their audience is by reading what they say on review sites and social media, as well as working directly with the client. Listening to people talk through how they work, what feedback they get from their audience/users often uncovers some interesting little nuggets which influence a design. Developers aren't typically involved much in discovery, which is something I'd like to change, but for now, I need to make it super-clear to Sally what's special about this event card for each new project. I write many, many (many) notes on Sketch files, but find they can tend to get lost, so sometimes we have a spreadsheet defining particular functionality.

And soon a data populator instead! :P

See the Pen
Cards in page context, scraped from production
by limograf (@Sally_McGrath)
on CodePen.

The post Telling the Story of Graphic Design appeared first on CSS-Tricks.

Datalist is for suggesting values without enforcing values

Css Tricks - Fri, 07/26/2019 - 5:02am

Have you ever had a form that needed to accept a short, arbitrary bit of text? Like a name or whatever. That's exactly what <input type="text"> is for. There are lots of different input types (and modes!), and picking the right one is a great idea.

But this little story is about something else and applies to any of them.

What if the text needs to be arbitrary (like "What's your favorite color?") so people can type in whatever, but you also want to be helpful. Perhaps there are a handful of really popular answers. Wouldn't it be nice if people could just select one? Not a <select>, but a hybrid between an input and a dropdown. Hold on though. Don't make your own custom React element just yet.

That's what <datalist> is for. I just used it successfully the other day so I figured I'd blog it because blogging is cool.

Here are the basics:

See the Pen
Basic datalist usage
by Chris Coyier (@chriscoyier)
on CodePen.

The use case I was dealing with needed:

  1. One <input type="text"> for a username
  2. One <input type="text"> for a "flag" (an aribtrary string representing a permission)

I probably wouldn't do a <datalist> for every username in a database. I don't think there is a limit, but this is sitting in your HTML, so I'd say it works best at maybe 100 options or less.

But for that second one, we only had maybe 3-4 unique flags we were dealing with at the time, so a datalist for those made perfect sense. You can type in whatever you want, but this UI helps you select the most common choices. So dang useful. Maybe this could be useful for something like a gender input, where there is a list of options you can choose, but it doesn't enforce you actually choose one of them.

Even lesser known than the fact that <datalist> exists? The fact that it works for all sorts of inputs besides just text, like date, range, and even color.

The post Datalist is for suggesting values without enforcing values appeared first on CSS-Tricks.

Weekly news: Truncating muti-line text, calc() in custom property values, Contextual Alternates

Css Tricks - Thu, 07/25/2019 - 5:12pm

In this week's roundup, WebKit's method for truncating multi-line text gets some love, a note on calculations using custom properties, and a new OpenType feature that prevents typographic logjams.

Truncating mutli-line text

The CSS -webkit-line-clamp property for truncating multi-line text is now widely supported (see my usage guide). If you use Autoprefixer, update it to the latest version (9.6.1). Previous versions would remove -webkit-box-orient: vertical, which caused this CSS feature to stop working.

Note that Autoprefixer doesn't generate any prefixes for you in this case. You need to use the following four declarations exactly (all are required):

.line-clamp { overflow: hidden; display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 3; /* or any other integer */ }

(via Autoprefixer)

Calculations in CSS custom property values

In CSS, it is currently not possible to pre-calculate custom property values (spec). The computed value of a custom property is its specified value (with variables substituted); therefore, relative values in calc() expressions are not "absolutized" (e.g., em values are not computed to pixel values).

:root { --large: calc(1em + 10px); } blockquote { font-size: var(--large); }

It may appear that the calculation in the above example is performed on the root element, specifically that the relative value 1em is computed and added to the absolute value 10px. Under default conditions (where 1em equals 16px on the root element), the computed value of --large would be 26px.

But that's not what's happening here. The computed value of --large is its specified value, calc(1em + 10px). This value is inherited and substituted into the value of the font-size property on the <blockquote> element.

blockquote { /* the declaration after variable substitution */ font-size: calc(1em + 10px); }

Finally, the calculation is performed and the relative 1em value absolute-ized in the scope of the <blockquote> element — not the root element where the calc() expression is declared.

(via Tab Atkins Jr.)

Contextual Alternates

The "Contextual Alternates" OpenType feature ensures that characters don't overlap or collide when ligatures are turned off. You can check if your font supports this feature on wakamaifondue.com and enable it (if necessary) via the CSS font-variant-ligatures: contextual declaration.

(via Jason Pamental)

Announcing daily news on webplatform.news

I have started posting daily news for web developers on webplatform.news. Visit every day!

The post Weekly news: Truncating muti-line text, calc() in custom property values, Contextual Alternates appeared first on CSS-Tricks.

My Favorite Netlify Features

Css Tricks - Thu, 07/25/2019 - 11:49am

&#x1f44b; Hey folks! Silvestar pitched this post to us because he is genuinely enthusiastic about JAMstack and all of the opportunities it opens up for front-end development. We wanted to call that out because, although some of the points in here might come across as sponsored content and Netlify is indeed a CSS-Tricks sponsor, it’s completely independent of Netlify.

Being a JAMstack developer in 2019 makes me feel like I am living in a wonderland. All these modern frameworks, tools, and services make our lives as JAMstack developers quite enjoyable. In fact, Chris would say they give us superpowers.

Yet, there is one particular platform that stands out with its formidable products and features — Netlify. You’re probably pretty well familiar with Netlify if you read CSS-Tricks regularly. There’s a slew of articles on it. There are even two CSS-Tricks microsites that use it.

This article is more of a love letter to Netlify and all of the great things it does. I decided to sit down and list my most favorite things about it. So that’s what I’d like to share with you here. Hopefully, this gives you a good idea not only what Netlify is capable of doing, but helps you get the most out of it as well.

You can customize your site’s Netlify subdomain.

When creating a new project on Netlify, you start by either:

  • choosing a repository from a Git provider, or
  • uploading a folder.

The project should be ready in a matter of minutes, and you could start configuring it for your needs right away. Start by choosing the site name.

The site name determines the default URL for your site. Only alphanumeric characters and hyphens are allowed.

Netlify randomly creates a default name for a new project. If you don’t like the name, choose your own and make it one that would be much easier for you to remember.

The "Site information" section of the Netlify dashboard.

For example, my site name is silvestarcodes, and I could access my site by visiting silvestarcodes.netlify.com.

You can manage all your DNS on Netlify.

If you are setting up an actual site, you would want to add a custom domain. From the domain management panel, go to the custom domains section, click on the "Add custom domain" button, enter your domain, and click the "Verify" button.

Now you have two options:

  1. Point your DNS records to Netlify load balancer IP address
  2. Let Netlify handle your DNS records

For the first option, you could read the full instructions in the official documentation for custom domains.

For the second option, you should add or update the nameservers on your domain registrar. If you didn’t buy the domain already, you could register it right from the dashboard.

Netlify has a service for provisioning DNS records called Netlify DNS.

Once you have configured the custom domain, you could handle your DNS records from the Netlify dashboard.

The "DNS" section of the Netlify dashboard.

If you want to set up a dev subdomain for your dev branch to preview development changes for your site, you could do it automatically. From the Domain Management section in the Settings section of your site, select the dev branch and Netlify would add a new subdomain dev for you automagically. Now you could see the previews by visiting dev subdomain.

The "Subdomains" section of the Netlify dashboard.

You could configure a subdomain for a different website. To achieve this, create a new Netlify site, enter a new subdomain as a custom domain, and Netlify would automatically add the records for you.

As an icing on the DNS management cake, Netlify lets you create Let’s Encrypt certificates for your domain automatically... for free.

You can inject snippets into pages, which is sort of like a Tag Manager.

Snippet injection is another excellent feature. I am using it mostly for inserting analytics, but you could use it for adding meta tags for responsive behavior, favicon tags, or Webmention.io tags.

The "Snippet injection" section of the Netlify dashboard.

When inserting snippets, you could choose to append the code fragment at the end of the <head> block, or at the end of the <body> block.

Every deploy has its own URL forever.

Netlify creates a unique preview link for every successful build. That means you could easily compare revisions made to your site. For example, here is the link to my website from January this year, and here is the link from January last year. Notice the style and content changes.

In his talk, Phil Hawksworth calls this feature immutable, atomic deploys.

They are immutable deployments that live on forever.
— Phil Hawksworth

I found this feature useful when completing tasks and sending the preview links to the clients. If there is a person in charge of handling Git-related tasks, like publishing to production, these preview links could be convenient to understand what to expect during the merge. You could even set up the preview builds for every pull request.

Netlify allows for the cleanest and most responsible A/B testing you can do.

If you ever wanted to run A/B tests on your site, you would find that Netlify makes running A/B tests quite straightforward. Split testing on Netlify allows you to display different versions of your website from different Git branches without any hackery.

The "Split testing" section of the Netlify dashboard.

Start by adding and publishing a separate branch with desired changes. From “Split testing” panel, select which branches to test, set a split percentage, and start the test. You could even set a variable in analytics code to track which branch is currently displayed. You might need to active branch deploys if you didn't do this already.

Netlify’s Split Testing lets you divide traffic to your site between different deploys, straight from our CDN network, without losing any download performance, and without installing any third party JavaScript library.
Netlify documentation

I have been using A/B testing on my site for a few different features so far:

  • Testing different versions of contact forms
  • Displaying different versions of banners
  • Tracking user behavior, like heatmaps

If you want to track split testing information, you could set up the process environment variable for this purpose. You could learn more about it in the official documentation. The best part? Most A/B testing services use client-side JavaScript to do it, which is unreliable and not great for performance. Doing it at the load balancer level like this is so much better.

There are lots of options for notifications, like email and Slack.

If you want to receive a notification when something happens with your Netlify project, you could choose from a wide variety of notification options. I prefer getting an email for every successful or failed build.

The "Notifications" section of the Netlify dashboard.

If you are using Gmail, you could notice "See the changes live" link for every successful build when hovering your message in Gmail inbox. That means you could open a preview link without opening the email. There are other links like "See full deploy logs" when your build have any issues or "Check usage details" when your plan is near its limits. How awesome is that?

Netlify email notifications include a preview link.

If you want to set up a hook for third-party services, all you need is a URL (JWS secret token is optional). Slack hooks are built-in with Netlify and could be set up within seconds if you know your Slack incoming webhook URL.

Conclusion

All of the features mentioned above are part of the free Netlify plan. I cannot even imagine the effort invested in providing a seamless experience as it is now. But Netlify doesn’t stop there. They are introducing more and more new and shiny features, like Netlify Dev CLI for local development and deploy cancelations. Netlify has established as an undoubtedly game-changing platform in modern web development of static websites, and it is a big part of the growth and popularity of static sites.

The post My Favorite Netlify Features appeared first on CSS-Tricks.

Responsive Iframes

Css Tricks - Thu, 07/25/2019 - 9:00am

Say you wanted to put the CSS-Tricks website in an <iframe>. You'd do that like this:

<iframe src="https://css-tricks.com"></iframe>

Without any other styling, you'd get a rectangle that is 300x150 pixels in size. That's not even in the User Agent stylesheet, it's just some magical thing about iframes (and objects). That's almost certainly not what you want, so you'll often see width and height attributes right on the iframe itself (YouTube does this).

<iframe width="560" height="315" src="https://css-tricks.com"></iframe>

Those attributes are good to have. It's a start toward reserving some space for the iframe that is a lot closer to how it's going to end up. Remember, layout jank is bad. But we've got more work to do since those are fixed numbers, rather than a responsive-friendly setup.

The best trick for responsive iframes, for now, is making an aspect ratio box. First you need a parent element with relative positioning. The iframe is the child element inside it, which you apply absolute positioning to in order to fill the area. The tricky part is that the parent element becomes the perfect height by creating a pseudo-element to push it to that height based on the aspect ratio. The whole point of it is that pushing the element to the correct size is a nicer system than forcing a certain height. In the scenario where the content inside is taller than what the aspect ratio accounts for, it can still grow rather than overflow.

I'll just put a complete demo right here (that works for images too):

See the Pen
Responsive Iframe
by Chris Coyier (@chriscoyier)
on CodePen.

Every time we're dealing with aspect ratios, it makes me think of a future with better handling for it. There is the experimental intrinsicsize attribute that I could imagine being quite nice for iframes in addition to images. Plus there is the hopefully-will-exist-soon aspect-ratio in CSS and the idea that it could default to use the width and height attributes on the element, which I hope would extend to iframes.

The post Responsive Iframes appeared first on CSS-Tricks.

How Google PageSpeed Works: Improve Your Score and Search Engine Ranking

Css Tricks - Thu, 07/25/2019 - 5:03am

This article is from my friend Ben who runs Calibre, a tool for monitoring the performance of websites. We use Calibre here on CSS-Tricks to keep an eye on things. In fact, I just popped over there to take a look and was notified of some little mistakes that slipped by, and I fixed them. Recommended!

In this article, we uncover how PageSpeed calculates it’s critical speed score.

It’s no secret that speed has become a crucial factor in increasing revenue and lowering abandonment rates. Now that Google uses page speed as a ranking factor, many organizations have become laser-focused on performance.

Last year, Google made two significant changes to their search indexing and ranking algorithms:

From this, we’re able to state two truths:

  • The speed of your site on mobile will affect your overall SEO ranking.
  • If your pages load slowly, it will reduce your ad quality score, and ads will cost more.

Google wrote:

Faster sites don’t just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings.

To understand how these changes affect us from a performance perspective, we need to grasp the underlying technology. PageSpeed 5.0 is a complete overhaul of previous editions. It’s now being powered by Lighthouse and CrUX (Chrome User Experience Report).

This upgrade also brings a new scoring algorithm that makes it far more challenging to receive a high PageSpeed score.

What changed in PageSpeed 5.0?

Before 5.0, PageSpeed ran a series of heuristics against a given page. If the page has large, uncompressed images, PageSpeed would suggest image compression. Cache-Headers missing? Add them.

These heuristics were coupled with a set of guidelines that would likely result in better performance, if followed, but were merely superficial and didn’t actually analyze the load and render experience that real visitors face.

In PageSpeed 5.0, pages are loaded in a real Chrome browser that is controlled by Lighthouse. Lighthouse records metrics from the browser, applies a scoring model to them, and presents an overall performance score. Guidelines for improvement are suggested based on how specific metrics score.

Like PageSpeed, Lighthouse also has a performance score. In PageSpeed 5.0, the performance score is taken from Lighthouse directly. PageSpeed’s speed score is now the same as Lighthouse’s Performance score.

Now that we know where the PageSpeed score comes from, let’s dive into how it’s calculated, and how we can make meaningful improvements.

What is Google Lighthouse?

Lighthouse is an open source project run by a dedicated team from Google Chrome. Over the past couple of years, it has become the go-to free performance analysis tool.

Lighthouse uses Chrome’s Remote Debugging Protocol to read network request information, measure JavaScript performance, observe accessibility standards and measure user-focused timing metrics like First Contentful Paint, Time to Interactive or Speed Index.

If you’re interested in a high-level overview of Lighthouse architecture, read this guide from the official repository.

How Lighthouse calculates the Performance Score

During performance tests, Lighthouse records many metrics focused on what a user sees and experiences. There are six metrics used to create the overall performance score. They are:

  • Time to Interactive (TTI)
  • Speed Index
  • First Contentful Paint (FCP)
  • First CPU Idle
  • First Meaningful Paint (FMP)
  • Estimated Input Latency

Lighthouse will apply a 0 – 100 scoring model to each of these metrics. This process works by obtaining mobile 75th and 95th percentiles from HTTP Archive, then applying a log normal function.

Following the algorithm and reference data used to calculate Time to Interactive, we can see that if a page managed to become "interactive" in 2.1 seconds, the Time to Interactive metric score would be 92/100.

Once each metric is scored, it’s assigned a weighting which is used as a modifier in calculating the overall performance score. The weightings are as follows:

Metric Weighting Time to Interactive (TTI) 5 Speed Index 4 First Contentful Paint 3 First CPU Idle 2 First Meaningful Paint 1 Estimated Input Latency 0

These weightings refer to the impact of each metric in regards to mobile user experience.

In the future, this may also be enhanced by the inclusion of user-observed data from the Chrome User Experience Report dataset.

You may be wondering how the weighting of each metric affects the overall performance score. The Lighthouse team have created a useful Google Spreadsheet calculator explaining this process:

Using the example above, if we change (time to) interactive from 5 seconds to 17 seconds (the global average mobile TTI), our score drops to 56% (aka 56 out of 100).

Whereas, if we change First Contentful Paint to 17 seconds, we’d score 62%.

TTI is the most impactful metric to your performance score. Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.

Moving the needle on TTI

At a high level, there are two significant factors that hugely influence TTI:

  • The amount of JavaScript delivered to the page
  • The run time of JavaScript tasks on the main thread

Our Time to Interactive guide explains how TTI works in great detail, but if you’re looking for some quick no-research wins, we’d suggest: Reducing the amount of JavaScript

Where possible, remove unused JavaScript code or focus on only delivering a script that will be run by the current page. That might mean removing old polyfills or replacing third-party libraries with smaller, more modern alternatives.

It’s important to remember that the cost of JavaScript is not only the time it takes to download it. The browser needs to decompress, parse, compile and eventually execute it, which takes non-trivial time, especially in mobile devices.

Effective measures for reducing the amount of scripts from your pages include:

  • Reviewing and removing polyfills that are no longer required for your audience.
  • Understanding the cost of each third-party JavaScript library. Use webpack-bundle-analyser or source-map-explorer to visualise the how large each library is.
  • Modern JavaScript tooling (like webpack) can break-up large JavaScript applications into a series of small bundles that are automatically loaded as a user navigates. This approach is known as code splitting and is extremely effective in improving TTI.
  • Service workers that will cache the bytecode result of a parsed and compiled script. If you’re able to make use of this, visitors will pay a one-time performance cost for parse and compilation. After that, it’ll be mitigated by cache.
Monitoring Time to Interactive

To successfully uncover significant differences in user experience, we suggest using a performance monitoring system (like Calibre!) that allows for testing a minimum of two devices; a fast desktop and a low-mid range mobile phone.

That way, you’ll have the data for both the best and worst case of what your customers experience. It’s time to come to terms that your customers aren’t using the same powerful hardware as you.

In-depth manual profiling

To get the best results in profiling JavaScript performance, test pages using intentionally slow mobile devices. If you have an old phone in a desk drawer, this is a great second-life for it.

An excellent substitute for using a real device is to use Chrome DevTools hardware emulation mode. We’ve written an extensive performance profiling guide to help you get started with runtime performance.

What about the other metrics?

Speed Index, First Contentful Paint and First Meaningful Paint are all browser-paint-based metrics. They’re influenced by similar factors and can often be improved at the same time.

It’s objectively easier to improve these metrics as they are calculated by how quickly a page renders. Following the Lighthouse Performance audit rules closely will result in these metrics improving.

If you aren’t already preloading your fonts or optimizing for critical requests, that is an excellent place to start a performance journey. Our article titled "The Critical Request" explains in great detail how the browser fetches and renders critical resources used to render your pages.

Tracking your progress and making meaningful improvements

Google's newly updated search console, Lighthouse and PageSpeed Insights, are a great way to get initial visibility into the performance of your pages but fall short for teams that need to continuously track and improve the performance of their pages.

Continuous performance monitoring is essential to ensuring speed improvements last, and teams get instantly notified when regressions happen. Manual testing introduces unexpected variability in results and makes testing from different regions as well as on various devices nearly impossible without a dedicated lab environment.

Speed has become a crucial factor for SEO rankings, especially now that nearly 50% of web traffic comes from mobile devices.

To avoid losing your search positioning, ensure you're using an up-to-date performance suite to track key pages. (Pssst, we built Calibre to be your performance companion. It has Lighthouse built-in. Hundreds of teams from around the globe are using it every day.)

Related Articles

The post How Google PageSpeed Works: Improve Your Score and Search Engine Ranking appeared first on CSS-Tricks.

What I Like About Vue

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

Dave Rupert digs into some of his favorite Vue features and one particular issue that he has with React:

I’ve come to realize one thing I don’t particularly like about React is jumping into a file, reading the top for the state, jumping to the bottom to find the render function, then following the method calls up to a series other sub-rendering functions only to find the component I’m looking for is in another castle. That cognitive load is taxing for me.

I wrote about this very problem recently in our newsletter where I argued that finding my way around a React component is difficult. I feel like I have to spend more energy than necessary figuring out how a component works because React encourages me to write code in a certain way.

On the other hand, Dave, says that Vue matches his mental model when authoring components:

<template> // Start with a foundation of good HTML markup </template> <script> // Add interaction with JavaScript </script> <style> // Add styling as necessary. </style>

And this certainly matches the way I think about things, too.

Direct Link to ArticlePermalink

The post What I Like About Vue appeared first on CSS-Tricks.

Zdog

Css Tricks - Wed, 07/24/2019 - 8:04am

David DeSandro has loads of super cool JavaScript libraries he's created over the years. His latest is Zdog, a "round, flat, designer-friendly pseudo-3D engine for canvas & SVG." It's only been about a month since he dropped it (although, like any good library, it's been simmering) and it has been pretty incredible to watch it capture the imagination of loads of designers and developers.

I'm shouting out Zdog here because I think it's worth y'all checking out. There is something about the API and how easy it becomes to draw in a 3D space that is clicking with folks. It might just click with you! Having a little moment like that is what web dev is all about ;).

See the Pen
Zdog Spaceship
by Ryan Mulligan (@hexagoncircle)
on CodePen.

The Official Site

(And GitHub repo.)

See the Pen
Ztocat
by Jessica Paoli (@skullface)
on CodePen.

CodePen Collections

Here is a collection from Dave that gathers community-built examples:

And here's is a Collection from Dave himself of demos he created while building the library.

See the Pen
Zdog and Goo
by Chris Gannon (@chrisgannon)
on CodePen.

There is a lot of cool stuff all around the web with Zdog, like this idea of plotting data with it from Zach:

Plus a font!!

See the Pen
Zfont Advanced Demo
by James Daniel (@rakujira)
on CodePen.

CodePen Topic

We created a Topic on CodePen to help explore the library and find examples as well.

We also covered it over on the CodePen Blog when the library dropped because it was so dang exciting.

(By the way, if you have a good idea for a "Topic" on CodePen, let me know! The main thing we need is a good strong Collection of "starter" Pens to help people understand concepts and use the library, plus a Collection of strong, complete examples. I have some cool swag and stuff I could send your way if you're into the idea of helping.)

The post Zdog appeared first on CSS-Tricks.

Don’t comma-separate :focus-within if you need deep browser support

Css Tricks - Wed, 07/24/2019 - 8:04am

I really like :focus-within. It's a super useful selector that allows you to essentially select a parent element when any of its children are in focus.

Say you wanted to reveal some extra stuff when a <div> is hovered...

div:hover .extra-stuff { /* reveal it */ }

That's not particularly keyboard-friendly. But if something in .extra-stuff is tab-able anyway (meaning it can be focused), that means you could write it like this to make it a bit more accessible:

div:hover .extra-stuff, div:focus-within .extra-stuff { /* reveal it */ }

That's nice, but it causes a tricky problem.

Browsers ignore entire selectors if it doesn't understand any part of them. So, if you're dealing with a browser that doesn't support :focus-within then it would ignore the CSS example above, meaning you've also lost the :hover state.

Instead:

div:hover .extra-stuff { /* reveal it */ } div:focus-within .extra-stuff { /* reveal it */ }

That is safer. But it's repetitive. If you have a preprocessor like Sass...

@mixin reveal { .extra-stuff { transform: translateY(0); } } div:hover { @include reveal; } div:focus-within { @include reveal; }

See the Pen
Mixing for :focus-within without comma-separating
by Chris Coyier (@chriscoyier)
on CodePen.

I'd say it's a pretty good use-case for having native CSS mixins.

The post Don’t comma-separate :focus-within if you need deep browser support appeared first on CSS-Tricks.

Unsuck It

Css Tricks - Tue, 07/23/2019 - 10:37am

Julia Carrie Wong and Matthew Cantor's How to speak Silicon Valley: 53 essential tech-bro terms explained was pretty hilarious. A little something in there to offend everyone.

Speaking of kinda douchey words, I'm reminded of one of my favorite sites on the internet: Unsuck It. Not only does it call out a ton of terms for being, uh, sucky, but suggests unsucky alternatives.

Bubble Up

Thank you for pointing out that issue. I’ll be sure to bubble that up.

Unsucked: Tell someone with more authority.

Powwow

Oh, yes! That’s very important to me. Let’s have a powwow about this first thing tomorrow.

Unsucked: Yet more unthinking appropriation of Native American culture. Meeting.

Solutioneering

Unsucked: Thinking.

On a somewhat related note, there's the ol' swoop and poop which is also a thing.

Direct Link to ArticlePermalink

The post Unsuck It appeared first on CSS-Tricks.

Pseudo Code

Css Tricks - Tue, 07/23/2019 - 4:39am

Yonatan Doron wrote a post on Medium not long ago called "Art of Code — Why you should write more Pseudo Code." Love that title, as a fan of pseudo code myself. That is, writing "code" that describes something you want to do or communicate, but that isn't of any particular language and doesn't use any correct APIs or anything.

Taking this time to write commented pseudo code helps organize our thoughts and our motivation and plan the desired outcome code ahead. By doing so, one moment later when we venture through to start hacking we would always have this map or skeleton of our thoughts that can help us regain focus and increase our productiveness

Jeremy Keith once likened it to writing a script:

When the user submits a form, then show a modal dialogue with an acknowledgment.” I then encouraged them to write a script …but I don’t mean a script in the JavaScript sense; I mean a script in the screenwriting or theatre sense. Line by line, write out each step that you want to accomplish. Once you’ve done that, translate each line of your English (or Portuguese) script into JavaScript.

I've seen educators use this technique time and time again. But it isn't just for teachers to use and students to learn from — it's for anyone's benefit. I find myself doing pseudo code before I write real code, sure, but I also leave it in place sometimes in code comments. Most commonly, I do it in Notion documents or in Slack conversations to get across a point.

Even simple ideas:

if env.dev stop email delivery

Anything with logic and branching or step-by-step bits benefits highly from it. Notice that code isn't valid code. It's not valid in any language I can think of. Sometimes, I'll throw in some random parenthesis or a semicolon out of muscle memory. Who cares? It's just about communicating an idea to myself or someone else.

if (grid is supported) use grid else lay out things in a basic row with flexbox

It's natural. Chances are, they won't care about the syntax either, they'll just get the idea.

on form submit validate if errors show errors; else submit to api; if api success show ui success; else show ui fail;

(After writing these out, it made me think of uilang. Check out how the plain language code blocks work there.)

Yonatan's article was missing real-world pseudo code examples, so I asked around. Check out all these great examples!

My whole notebook is a pseudo...

These transfer to comments before I start coding so I know what I’m doing & what I’ve done later pic.twitter.com/9vfJYfweDh

— Ruth John (@Rumyra) May 28, 2019

whiteboards are amazing for writing pseudocode as well as adding graphics to it. pic.twitter.com/56FUu4rhmU

— norom (@_norom_) May 28, 2019

Oh I used to make these, a long time ago.... pic.twitter.com/lQi4Y8RhwP

— Ben Koppenens (@bkoppenens) May 28, 2019

All the time! pic.twitter.com/YFVVNwls5M

— Bryan (@iamBryanSanders) May 28, 2019

Trying to work with JavaScript and php simultaneously can get a little tricky sometimes pic.twitter.com/Xp0bQyV86D

— frankie | webdev (@azoicx) May 29, 2019

late entry. quick map of scripts. pic.twitter.com/n1kYDxKgya

— Adam Styles (@thelibstyles) May 31, 2019

I'm a little surprised at how much of it is on paper! That's pretty cool, really. Just weird for me as I very rarely use paper for anything. I probably should.

The post Pseudo Code appeared first on CSS-Tricks.

Zoom, CORS, and the Web

Css Tricks - Tue, 07/23/2019 - 4:39am

It's sorta sad by funny that that big Zoom vulnerability thing was ultimately related to web technology and not really the app itself.

There is this idea of custom protocols or "URL schemes." So, like gittower:// or dropbox:// or whatever. A native app can register them, then URLs that hit them get passed to the native app. iOS has "universal links" which are coming to the web apparently. (Atishay Jain has an excellent write-up on them.) But links like that don't leave much choice — they will open in the app. If your app has both web and native components, you might want to offer the user a choice. So, you use a regular URL instead.

In order for that web page to open up a native app, apparently, the tactic used by many is to have it communicate with a server running on localhost on your own computer which uses a URL scheme to open the native app. Clever, but I've heard sentiment from folks like:

  • I had no idea this software was running a localhost server on my machine
  • It feels weird that websites out on the wild internet can communicate with my localhost server

That's the way it is though. But there are some protections in place. Namely: CORS (Cross-Origin Resource Sharing). Ugh. I feel like I deal with some kind of CORS problem every week of my life. But it's important. It prevents XHR requests from websites that aren't specifically allowed. Imagine if you visit my website, and I have your browser shoot requests over to Facebook, hoping you are logged in so I can do things on your behalf. Bad. CORS doesn't prevent that, the same-origin policy of browsers prevents that. CORS is the mechanism to control that.

If my website tries to communicate with your website, and your website's response doesn't have an Access-Control-Allow-Origin header with my domain or *, it will fail. But not everything is subject to CORS restrictions. Images, for example, are not. We can link up images from any domain and they will return data.

Chris Foster thinks CORS and a lack of understanding of CORS was at the heart of the Zoom bug.

Zoom may have needed to get this feature out and did not understand CORS. They couldn’t make the AJAX requests without the browser disallowing the attempt. Instead, they built this image hack to work around CORS. By doing this, they opened Zoom up to a big vulnerability because n/ot only can the Zoom website trigger operations in the native client and access the response, but every other website on the internet can too.

In the wake of all this, Nicolas Bailly wrote "What you should know about CORS":

This is often a source of confusion for newcomers because it's not immediately apparent what CORS is supposed to achieve. Firstly CORS is not a security measure in itself, it's actually the opposite: CORS is a way to circumvent the "Same Origin Policy" which is the security measure preventing you from making [AJAX] requests to a different domain.

The post Zoom, CORS, and the Web appeared first on CSS-Tricks.

CSS :not() with Multiple Classes

Css Tricks - Mon, 07/22/2019 - 11:39am

Say you want to select an element when it doesn't have a certain class. That's what the :not() selector is for.

body:not(.home) { }

But what if there are multiple classes you want to avoid?

There are no logical combinators with :not(), like and or or, but you can chain them, which is effectively like and.

body:not(.home):not(.away):not(.page-50) { }

The :not() selector doesn't add any specificy by itself, but what is inside does, so :not(.foo) adds the same weight as .foo does.

The post CSS :not() with Multiple Classes appeared first on CSS-Tricks.

A Beginner’s Journey to Launching a Website

Css Tricks - Mon, 07/22/2019 - 5:07am

In September 2018, I was just a few months into my journey of learning web development. As I'm sure is the case with many new developers, it was a big task for me to learn not only the basic skills required, but also keeping current with the fast-moving industry. Just as I was getting to the level where it felt as though I could build a simple website, I started to realize that it was only the first step.

Opening up a few HTML pages stored locally on my laptop felt like a million miles away from being able to say to someone, "Hey, check out my website, live on the actual internet!"

But I did it! And the best part is that it wasn't as scary, difficult or expensive as it first felt like it'd be.

It all started with me sending Chris an email, which he used to write an awesome article explaining everything in plain English.

At this point, I didn't have a fully coded website — just an idea for a basic site that I was using to teach myself as I went along. I used the ongoing progress of my site as a push to learn how to get a live website quicker. But I'm sure you could do the whole thing with an HTML document that just says "Hello, world!"

I built my site using Gatsby, a static site generator powered by React. Building a website with these tools in a modular way felt really natural to me. The concept of reusable parts is something I’m familiar with in my career as a physical product designer and mechanical design engineer. It means that you can build in stages, like Lego, brick-by-brick, until you eventually have a life-sized castle you can invite your friends to visit!

This isn't a guide. It's my personal experience in the process of getting a website from my laptop to being live on the internet. Hopefully it'll give you some hope that it's possible and achievable, even by someone who has no formal training in web development and who has only been doing it for 12 months!

Domain registrars

Before I ever bought a domain, it seemed like a pretty serious thing to do. Owning a domain means being responsible for it. People will go to that address and eventually see content that you've put there.

I don’t know if everyone has the same experience, but I spent weeks deciding on a domain name before going for it. It almost became an obsession of mine for a while, searching online for acronym generators to try and be clever, spending hours on dictionary.com trying to find synonyms that were cool. In the end, I settled for my name and what I do: joshlong.design. I still smile a little when I see my name in the address bar.

Since reading Chris' article, I've actually bought two domains from two different providers: a .com and a .design. I realize that I went against Chris' advice of consolidating domain names at a single registrar, but I needed to shop around a bit to get a good deal on my .design domain. I only own two domain names — and one of them I don't actually have any plans for just yet — so keeping on top of where I bought them isn't a task. In fact, I don't remember the last time I needed to login and manage the domain I use on a daily basis!

Buying a domain name was as simple as any other online shopping transaction. Nothing really huge or scary about it. I bought my .com through Namecheap, and my .design through Google Domains, and the process was pretty similar for both. All they needed was my name, address and payment details. Pretty standard stuff!

I don't remember Google trying to sell me a load of extra packages. They seemed happy with me just buying a domain, though they did offer me free WHOIS protection which I snapped up because I didn’t want my contact details freely available for anyone who’s feeling nosey. However, as Chris warned might happen, the other registrar I went through tried really hard to sell me some extras like hosting, email, a VPN (whatever that is!) and SSL certificates.

Google Domains checkout is happy just to sell the domain name. Namecheap tries to sell you all the additional services they offer before getting to the checkout.

I didn't go for any of those extras. I already had a hosting plan, and you can use an alias through Gmail to "fake" having a me@mycoolsite.com email address. I honestly have no idea why I'd need a VPN, and the hosting I was going to go for gave me a free SSL certificate through Let's Encrypt. So just the domain name, please!

Hosting

As Chris suggested it would be, choosing a host was a tad trickier than choosing and buying a domain name. But in the end, the web technology I used to build my site kind of guided me in a particular direction.

My site is built with Gatsby, which means it outputs straight-up static assets, basically as HTML and JavaScript files. That means that I didn't need a host that offered a server (in my most super smart authoritative voice), especially for WordPress with a MySQL database and Apache server, 6 cores @ 3.6 Ghz, 4GB RAM, 5TB bandwidth, 5 IP Addresses and 500GB SSD Storage, etc.

All that jargon goes straight over my head. All I wanted to do was upload my files to the internet and go to my domain to see them all compiled and shiny. Should be easy, right?

Well it turns out that it actually was that easy. As there's been so much hype around it recently, I thought I'd take a look at Netlify.

Netlify is recommended by Gatsby. They have really good documentation, and for my uses I felt as though I could comfortably stay within the free tier that they offer. In fact, at the moment I'm using 0.08% a month of the total bandwidth the free tier offers. Winning! Although maybe that means I’m not doing enough to get people to my site...

A quick aside about GitHub: I'm no expert at it and I don't really know any of the etiquette it entails. All I did was sign up, create a new repository and follow the instructions that they give you. After that, every time I made a change to my site, I used the buttons in my code editor (VS Code) to commit and push my changes. It works, but I have no idea if it's the correct or best practice way of doing it! I'm starting now, though, to understand how to use Git through the command line. I had no idea at all how to do it when I started, but I still muddled through it — and you can too!

Back to Netlify.

I signed up for an account (no credit card details required) and added a new site to Netlify by telling it about the GitHub repository where it was stored. When you’ve connected your repository, you can watch Netlify doing its thing deploying your site.

Part of the Netlify’s deploy process is that it shows your website going live in real time. That’s useful for debugging if something goes wrong, or just to watch and get excited like an impatient puppy waiting for a biscuit. You also get a deploy summary to quickly see what files were uploaded during deployment.

After my site was deployed to the randomly generated URL Netlify gives you, I followed their instructions for adding a domain I had registered elsewhere. They make it so easy!

I assume the instructions will be different for different hosts, but basically, Netlify gave me some server addresses which I then had to go back to my domain registrar to enter them in. These addresses are referred to as nameservers, so look out for that word!

Netlify gives you your nameserver addresses and super easy to understand documentation to set them up with your domain registrar

Once I entered my Netlify nameservers into Google Domains, Google knew where to look to send people who type my domain name into their browser’s address bar. All I had to do after that was wait for some internet magics to happen in the background. That took around three hours for me but can take anywhere from 10 minutes to 24 hours from what I hear.

After that was done, I could type my shiny new domain name into the address bar and — just like that — I'm looking at my own site, hosted live on the internet!

Content Management Systems

The world of Content Management Systems (CMS) is vast, and confusing, but it can also be completely irrelevant to you if you want it to be. I felt so liberated when I realized you don't have to worry about it. It was one less thing in my list of things to do.

My Gatsby site posts and pages (my content) was just a directory of markdown files and my CMS was my text editor. Chris and Dave talked about the idea of this in a recent episode of ShopTalk Show.

My website content is managed right in my text editor, VS Code.

Because I wanted to have a standard structure for different types of posts and pages, I eventually started using NetlifyCMS which is an open-source CMS which can be included in your site real fast. (Chris also did a video recently about NetlifyCMS for his confer-reference site... see what I did there?!) Now I can create blog posts and drafts from anywhere in the world, straight from my website, as long as I have an internet connection!

The same content managed through NetlifyCMS, which offers a great UI and GitHub integration Asset Hosting (CDNs)

A Content Delivery Network (CDN), as Chris explained in his article, is basically somewhere on the internet where you store the files you need for your website to run, HTML, CSS, images, etc. When your website needs them, it goes to the CDN and grabs the files for your site to use.

From what I've read, it's good practice to use a CDN, and because of the hosting decision I made, it's not something I have to worry about - it's included by Netlify as standard, for free!

Netlify has it's own CDN where all of the files for your website are stored. When someone goes to your website, Netlify goes to its CDN and grabs the files. It's amazingly quick, and makes your site feel so much smoother to navigate.

It's a long journey, but you can do it!

There was a point, before I set off on the journey of getting my website live, where I tried to convince myself that it's fine to just have local websites, as my career isn’t in web development. The reason for that was because the path felt like it would be difficult, long and expensive.

In fact, it was none of those things! You could get a website live on the internet for £0.99 (~$1.25 for you Americans) or less if you find a deal on a domain name. The domain name was my only expense because for the path I took for hosting, asset management and content management.

At a super basic level, the path looks like this..

Code > Buy Domain > Find/Buy Hosting > Update Nameservers > Upload Code > Live!

If you happen to use the same vendor to buy your domain name and your hosting, you can skip the nameserver step. (Netlify sells domains too!)

It's definitely possible for anyone to get their website live on the internet. There's a process that you need to follow, but if you take your time, it can be relatively straightforward. It's a really wonderful feeling, getting a thing you built in front of people, and it's honestly something that I thought I'd never be able to do. But it's certainly within everyone's reach!

Something I've come to really admire over this process (and thousands of Google searches) is the willingness of everyone in the web community to collaborate and help, accepting me and my questions as I tried to learn what I was doing. It's something that I wish was more common in my own industry.

I'd love to hear other people's experiences getting their first website live. What were your pitfalls and triumphs? Was it as scary as it first seemed?

The post A Beginner’s Journey to Launching a Website appeared first on CSS-Tricks.

CSS Animation Libraries

Css Tricks - Mon, 07/22/2019 - 5:06am

There are an awful lot of libraries that want to help you animate things on the web. These aren't really libraries that help you with the syntax or the technology of animations, but rather are grab-and-use as-is libraries. Want to apply a class like "animate-flip-up" and watch an element, uhhh, flip up? These are the kind of libraries to look at.

I wholeheartedly think you should both 1) learn how to animate things in CSS by learning the syntax yourself and 2) customize animations to tailor the feel to your site. Still, poking around libraries like this helps foster ideas, gets you started with code examples, and might form a foundation for your own projects.

Let's take a look at the landscape of them. Some libraries have different approaches: only take what you need classes, Sass mixins, light JavaScript libraries for adding/removing classes, etc. But they are all essentially "CSS animation libraries." (Some of them are kinda funny having "CSS3" in the title, which kinda dates them. People just don't say that anymore.)

While animations can both be fun and create useful interactions, it's worth remembering that not all users want them when browsing the web. See Eric Bailey's "Revisiting prefers-reduced-motion, the reduced motion media query" for information on how to accommodate users who prefer little or no motion.

Animista

You pick an animation you like and it gives you a class name you can use that calls a keyframe animation (you copy and paste both). The point is you just take what you need.

See the Pen
Animista Example
by Chris Coyier (@chriscoyier)
on CodePen.

Animate.css

One of the big original classic CSS animation libraries from Dan Eden.

See the Pen
Animate.css (Part 3)
by Hudson Taylor (@Hudson_Taylor11)
on CodePen.

tachyons-animate

Tachyons itself is an atomic CSS library with a ton of utility classes for essentially designing anything by adding classes to what you need. tachyons-animate extends those by adding "Single purpose classes to help you orchestrate CSS animations." It can be used alone, but even the docs suggest it can be used in combination with other animation libraries since helper classes are generically useful.

See the Pen
tachyons-animate
by Chris Coyier (@chriscoyier)
on CodePen.

Infinite

These animations, like rotations and pulses, that are specifically designed to run and repeat forever.

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

Motion UI

A Sass library for creating flexible CSS transitions and animations.

See the Pen
Motion UI
by Chris Coyier (@chriscoyier)
on CodePen.

micron

a [?] microInteraction library built with CSS Animations and controlled by JavaScript Power

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

Vivify

Vivify is sort of like Animate.css in the sense that it contains a lot of the same types of animations. It does offer plenty of its own as well.

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

Hover.css

A collection of CSS3 powered hover effects to be applied to links, buttons, logos, SVG, featured images and so on. Easily apply to your own elements, modify or just use for inspiration. Available in CSS, Sass, and LESS.

See the Pen
Hover.css
by Chris Coyier (@chriscoyier)
on CodePen.

AllAnimationCss3

See the Pen
All Animation
by Chris Coyier (@chriscoyier)
on CodePen.

Magic Animations CSS3

See the Pen
Magic Animations
by Chris Coyier (@chriscoyier)
on CodePen.

It's Tuesday.

A quirky CSS Animation Library.

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

vhs

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

ReboundGen

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

CSShake

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

Motion CSS cssanimation.io

See the Pen
cssanimation.io
by Chris Coyier (@chriscoyier)
on CodePen.

WickedCSS

See the Pen
WickedCSS animations
by Chris Coyier (@chriscoyier)
on CodePen.

Woah.css

See the Pen
Woah.css
by Chris Coyier (@chriscoyier)
on CodePen.

Obnoxious

See the Pen
Obnoxious.css
by Chris Coyier (@chriscoyier)
on CodePen.

Hexa Mimic.css

See the Pen
mimic.css
by Eric Treacy (@etreacy)
on CodePen.

The post CSS Animation Libraries appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.