Una doing an amazing job of showing just how (dare I say it?) easy CSS layout has gotten. There is plenty to learn, but what you learn makes sense, and once you have, it’s quite empowering.
The demos are all together here.
Direct Link to Article — Permalink
The post 10 modern layouts in 1 line of CSS appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
I’m excited to share some of the newer features in Chrome DevTools with you. There’s a brief introduction below, and then we’ll cover many of the new DevTools features. We’ll also look at what’s happening in some other browsers. I keep up with this stuff, as I create Dev Tips, the largest collection of DevTools tips you’ll find online!
It’s a good idea to find out what’s changed in DevTools because it’s constantly evolving and new features are specifically designed to help and improve our development and debugging experience.
Let’s jump into the latest and greatest. While the public stable version of Chrome does have most of these features, I’m using Chrome Canary as I like to stay on the bleeding edge.
Lighthouse is an open source tool for auditing web pages, typically around performance, SEO, accessibility and such. For a while now, Lighthouse has been bundled as part of DevTools meaning you can find it in a panel named… Lighthouse!
I really like Lighthouse because it’s one of easiest parts of DevTools to use. Click “Generate report” and you immediately get human-readable notes for your webpage, such as:
Document uses legible font sizes 100% legible text
Or:
Avoid an excessive DOM size (1,189 elements)
Almost every single audit links to developer documentation that explains how the audit may fail, and what you can do to improve it.
The best way to get started with Lighthouse is to run audits on your own websites:
Even though Lighthouse has been part of DevTools for a while now (since 2017!), it still deserves a significant mention because of the user-facing features it continues to ship, such as:
This is a subtle and, in some ways, very small feature, but it can have profound effects on how we treat web accessibility.
Here’s how it works. When you use Inspect Element — what is arguably the most common use of DevTools — you now get a tooltip with additional information on accessibility.
The reason I say this can have a profound impact is because DevTools has had accessibility features for quite some time now, but how many of us actually use them? Including this information on a commonly used feature like Inspect Element will gives it a lot more visibility and makes it a lot more accessible.
The tooltip includes:
To try this out, right-click (or Cmd + Shift + C) on an element and select Inspect to view it in DevTools.
I made a 14-minute video on Accessibility debugging with Chrome DevTools which covers some of this in more detail.
Exactly as it says on the tin, you can use Chrome DevTools to emulate vision impairments. For example, we can view a site through the lens of blurred vision.
How can you do this in DevTools? Like this:
Cmd + Shift + C).Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows).We used blurred vision as an example, but DevTools has other options, including: protanopia, deuteranopia, tritanopia, and achromatopsia.
Like with any tool of this nature, it’s designed to be a complement to our (hopefully) existing accessibility skills. In other words, it’s not instructional, but rather, influential on the designs and user experiences we create.
Here are a couple of extra resources on low vision accessibility and emulation:
The Performance Panel in DevTools can sometimes look like a confusing mish-mash of shapes and colors.
This update to it is great because it does a better job surfacing meaningful performance metrics.
What we want to look at are those extra timing rectangles shown in the “Timings” in the Performance Panel recording. This highlights:
As a bonus, if you find the Largest Contentful Paint event in a Performance Panel recording, you can click on it to get additional information.
While there is a lot of golden information here, the “Related Node” is potentially the most useful item because it specifies exactly which element contributed to the LCP event.
To try this feature out:
If you want to quickly get started using DevTools to analyze performance and you’ve already tried Lighthouse, then I recommend the Performance Monitor feature. This is sort of like having WebPageTest.org right at your fingertips with things like CPU usage.
Here’s how to access it:
Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows)The Performance Monitor can give you interesting metrics, however, unlike Lighthouse, it’s for you to figure out how to interpret them and take action. No suggestions are provided. It’s up to you to study that CPU usage chart and ask whether something like 90% is an acceptable level for your site (it probably isn’t).
The Performance Monitor has an interactive legend, where you can toggle metrics on and off, such as:
CSS-Tricks has already covered these features, so go and check them out!
I’m sure you noticed that I’ve been using Chrome throughout this article. It’s the browser I use personally. That said, it’s worth considering that:
In other words, keep an eye out because this is a quickly evolving space!
We covered a lot in a short amount of space!
Please check out my mailing list, Dev Tips, if you want to stay keep up with the latest updates and get over 200 web development tips! I also have a premium video course over at ModernDevTools.com. And, I tend to post loads of bonus web development resources on Twitter.
The post A Look at What’s New in Chrome DevTools in 2020 appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Posted by willcritchlow
We're bringing back this slightly different-from-the-norm Whiteboard Friday, in which the fantastic Will Critchlow shares lessons from how kids search. Kids may search differently than adults, but there are some interesting insights from how they use Google that can help deepen our understanding of searchers in general. Comfort levels with particular search strategies, reading only the bold words, taking search suggestions and related searches as answers — there's a lot to dig into.
Click on the whiteboard image above to open a high-resolution version in a new tab!
Hi, everyone. I'm Will Critchlow, founder and CEO of Distilled, and this week's Whiteboard Friday is a little bit different. I want to talk about some surprising and interesting and a few funny facts that I learnt when I was reading some research that Google did about how kids search for information. So this isn't super actionable. This is not about tactics of improving your website particularly. But I think we get some insights — they were studying kids aged 7 to 11 — by looking at how kids interact. We can see some reflections or some ideas about how there might be some misconceptions out there about how adults search as well. So let's dive into it.
I've got this "What do dolphins eat?" because this was the first question that the researchers gave to the kids to say sit down in front of a search box, go. They tell this little anecdote, a little bit kind of soul-destroying, of this I think it was a seven-year-old child who starts typing dolphin, D-O-L-F, and then presses Enter, and it was like sadly there's no dolphins, which hopefully they found him some dolphins. But a lot of the kids succeeded at this task.
The researchers divided the ways that the kids approached it up into a bunch of different categories. They found that some kids were power searchers. Some are what they called "developing." They classified some as "distracted." But one that I found fascinating was what they called visual searchers. I think they found this more commonly among the younger kids who were perhaps a little bit less confident reading and writing. It turns out that, for almost any question you asked them, these kids would turn first to image search.
So for this particular question, they would go to image search, typically just type "dolphin" and then scroll and go looking for pictures of a dolphin eating something. Then they'd find a dolphin eating a fish, and they'd turn to the researcher and say "Look, dolphins eat fish." Which, when you think about it, I quite like in an era of fake news. This is the kids doing primary research. They're going direct to the primary source. But it's not something that I would have ever really considered, and I don't know if you would. But hopefully this kind of sparks some thought and some insights and discussions at your end. They found that there were some kids who pretty much always, no matter what you asked them, would always go and look for pictures.
Kids who were a bit more developed, a bit more confident in their reading and writing would often fall into one of these camps where they were hopefully focusing on the attention. They found a lot of kids were obviously distracted, and I think as adults this is something that we can relate to. Many of the kids were not really very interested in the task at hand. But this kind of path from distracted to developing to power searcher is an interesting journey that I think totally applies to grown-ups as well.
So I actually, after I read this paper, went and did some research on my kids. So my kids were in roughly this age range. When I was doing it, my daughter was eight and my son was five and a half. Both of them interestingly typed "wat do dolfin eat" pretty much like this. They both misspelled "what," and they both misspelled "dolphin." Google was fine with that. Obviously, these days this is plenty close enough to get the result you wanted. Both of them successfully answered the question pretty much, but both of them went straight to the OneBox. This is, again, probably unsurprising. You can guess this is probably how most people search.
So there's a OneBox that comes up, and it's got a picture of a dolphin. So my daughter, a very confident reader, she loves reading, "wat do dolfin eat," she sat and she read the OneBox, and then she turned to me and she said, "It says they eat fish and herring. Oh, what's a cephalopod?" I think this was her going from distracted into developing probably. To start off with, she was just answering this question because I had asked her to. But then she saw a word that she didn't know, and suddenly she was curious. She had to kind of carefully type it because it's a slightly tricky word to spell. But she was off looking up what is a cephalopod, and you could see the engagement shift from "I'm typing this because Dad has asked me to and it's a bit interesting I guess" to "huh, I don't know what a cephalopod is, and now I'm doing my own research for my own reasons." So that was interesting.
My son, as I said, typed something pretty similar, and he, at the point when he was doing this, was at the stage of certainly capable of reading, but generally would read out loud and a little bit halting. What was fascinating on this was he only read the bold words. He read it out loud, and he didn't read the OneBox. He just read the bold words. So he said to me, "Dolphins eat fish, herring, killer whales," because killer whales, for some reason, was bolded. I guess it was pivoting from talking about what dolphins eat to what killer whales eat, and he didn't read the context. This cracked him up. So he thought that was ridiculous, and isn't it funny that Google thinks that dolphins eat killer whales.
That is similar to some stuff that was in the original research, where there were a bunch of common misconceptions it turns out that kids have and I bet a bunch of adults have. Most adults probably don't think that the bold words in the OneBox are the list of the answer, but it does point to the problems with factual-based, truthy type queries where Google is being asked to be the arbiter of truth on some of this stuff. We won't get too deep into that.
But some common misconceptions they found some kids thought that the search suggestions, so the drop-down as you start typing, were the answers, which is bit problematic. I mean we've all seen kind of racist or hateful drop-downs in those search queries. But in this particular case, it was mainly just funny. It would end up with things like you start asking "what do dolphins eat," and it would be like "Do dolphins eat cats" was one of the search suggestions.
Similar with related searches, which, as we know, are not answers to the question. These are other questions. But kids in particular — I mean, I think this is true of all users — didn't necessarily read the directions on the page, didn't read that they were related searches, just saw these things that said "dolphin" a lot and started reading out those. So that was interesting.
The next bit of the research was much more complex. So they started with these easy questions, and they got into much harder kind of questions. One of them that they asked was this one, which is really quite hard. So the question was, "Can you find what day of the week the vice president's birthday will fall on next year?" This is a multifaceted, multipart question.
Most of the younger kids were pretty stumped on this question. Some did manage it. I think a lot of adults would fail at this. So if you just turn to Google, if you just typed this in or do a voice search, this is the kind of thing that Google is almost on the verge of being able to do. If you said something like, "When is the vice president's birthday," that's a question that Google might just be able to answer. But this kind of three-layered thing, what day of the week and next year, make this actually a very hard query. So the kids had to first figure out that, to answer this, this wasn't a single query. They had to do multiple stages of research. When is the vice president's birthday? What day of the week is that date next year? Work through it like that.
I found with my kids, my eight-year-old daughter got stuck halfway through. She kind of realized that she wasn't going to get there in one step, but also couldn't quite structure the multi-levels needed to get to, but also started getting a bit distracted again. It was no longer about cephalopods, so she wasn't quite as interested.
This I think is a whole area that, as Google's capabilities develop to answer more complex queries and as we start to trust and learn that those kind of queries can be answered, what we see is that there is going to be increasing, growing search volume in new areas. So I'm going to link to a post I wrote about a presentation I gave about the next trillion searches. This is my hypothesis that essentially, very broad brush strokes, there are a trillion desktop searches a year. There are a trillion mobile searches a year. There's another trillion out there in searches that we don't do yet because they can't be answered well. I've got some data to back that up and some arguments why I think it's about that size. But I think this is kind of closely related to this kind of thing, where you see kids get stuck on these kind of queries.
Incidentally, I'd encourage you to go and try this. It's quite interesting, because as you work through trying to get the answer, you'll find search results that appear to give the answer. So, for example, I think there was an About.com page that actually purported to give the answer. It said, "What day of the week is the vice president's birthday on?" But it had been written a year before, and there was no date on the page. So actually it was wrong. It said Thursday. That was the answer in 2016 or 2017. So that just, again, points to the difference between primary research, the difference between answering a question and truth. I think there's a lot of kind of philosophical questions baked away in there.
So we're going to wrap up with possibly my favorite anecdote of the user research that these guys did, which was that they said some of these kids, somewhere in this developing stage, get very attached to searching in one particular way. I guess this is kind of related to the visual search thing. They find something that works for them. It works once. They get comfortable with it, they're familiar with it, and they just do that for everything, whether it's appropriate or not. My favorite example was this one child who apparently looked for information about both dolphins and the vice president of the United States on the SpongeBob SquarePants website, which I mean maybe it works for dolphins, but I'm guessing there isn't an awful lot of VP information.
So anyway, I hope you've enjoyed this little adventure into how kids search and maybe some things that we can learn from it. Drop some anecdotes of your own in the comments. I'd love to hear your experiences and some of the funny things that you've learnt along the way. Take care.
Video transcription by Speechpad.com
To help us serve you better, please consider taking the 2020 Moz Blog Reader Survey, which asks about who you are, what challenges you face, and what you'd like to see more of on the Moz Blog.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!
There are tons of smokin’ hot websites out there, with an equal or greater number of talented designers and developers who make them. The web is awesome like that and encourages that sort of creativity.
Even so, it amazes me that certain traits find their way into things. I mean, it makes sense. Many of us use the same UI frameworks and take cues from sites we admire. But every once in a while, my eye starts catching wind of the zeitgeist and commonalities that come with it.
The latest one? Blobby shapes. It’s a fun flourish that adds a little panache, especially for flat designs that need a splash of color or an interesting focal point that leads the eye from one place to anther. I’m sure you’ve seen it. I spent one week collecting screenshots of websites I came across that use it. I certainly wan’t looking for examples; they just sort of popped up in my normal browsing.
I’m sorry if it seems like I’m calling out people because that’s my intention. I actually love the concept — so much, in fact, that I’m considering it on a project! Some of the examples in that gallery are flat-out gorgeous.
After spotting these blobby shapes a number of times, I’ve started to notice some considerations to take into account when use them. Things like:
All of this has me thinking about how the websites of today will be looked at by the developers of tomorrow. Remember way back, like 15 years ago, when many sites adopted Apple’s use of reflective imagery? I probably still have some Photoshop muscle memory from replicating that effect so many times.
Skeuomorphism, bevels, animated GIF backgrounds, long shadows, heroes, gradients, bokeh backgrounds… all of these and many other visual treatments have had their day in the sun. Perhaps blobs will join that club at some point. Perhaps they’ll come back in style after that. Who knows! I just find it interesting to reflect on the things that have inspired us over the last three decades and imagine how the things we do today will be seen through the long lens of time.
It’d be awesome to see other instances of blobby shapes — share ’em if you’ve got ’em!
The post Spotting a Trend appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
You know the title attribute? I can do this:
<div title="The Title">
I'm a div with a `title`
</div>And now if I’m on a device with a mouse pointer and hover the cursor over that element, I get…
Which, uh, I guess is something. I sometimes use it for things like putting an expanded date or time on an element that uses shorthand for it. It’s a tiny bit of UX helpfulness reserved exclusively for sighted mouse users.
But it’s not particularly useful, as I understand it. Ire Aderinokun dug into how it’s used for the <abbr> element (a commonly cited example) and found that it’s not-so-great alone. She suggests a JavaScript-enhanced pattern. She also mentions that JAWS has a setting for announcing titles in there, so that’s interesting (although it sounds like it’s off by default).
I honestly just don’t know how useful title is for screen readers, but it’s certainly going to be nuanced.
I did just learn something about titles though… this doesn’t work:
<!-- Incorrect usage -->
<svg title="Checkout">
</svg>If you hover over that element, you won’t get a title display. You have to do it like this:
<!-- Correct usage -->
<svg>
<title>Checkout</title>
<!-- More detail -->
<desc>A shopping cart icon with baguettes and broccoli in the cart.</desc>
</svg>Which, interestingly, Firefox 79 just started supporting.
When you use title like that, the hoverable area to reveal the title popup is the entire rectangle of the <svg>.
I was looking at all this because I got an interesting email from someone who was in a situation where the title popup only seemed to come up when hovering over the “filled in” pixels of an SVG, and not where transparent pixels were. Weird, I thought. I couldn’t replicate in my testing either.
Turns out there is a situation like this. You can apply a <title> within a <use> element, then the title only applies to those pixels that come in via the <use>.
If you remove the “white part” title, you’ll see the “black part” only comes up over the black pixels. Seems to be consistent across browsers. Just something to watch out for if that’s how you apply titles.
The post SVG Title vs. HTML Title Attribute appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
I have spent the past several years working (alongside a bunch of super talented people) on a font family called Recursive Sans & Mono, and it just launched officially on Google Fonts!
Wanna try it out super fast? Here’s the embed code to use the full Recursive variable font family from Google Fonts (but you will get a lot more flexibility & performance if you read further!)
<link href="https://fonts.googleapis.com/css2?family=Recursive:slnt,wght,CASL,CRSV,MONO@-15..0,300..1000,0..1,0..1,0..1&display=swap" rel="stylesheet">
I started Recursive as a thesis project for a type design masters program at KABK TypeMedia, and when I launched my type foundry, Arrow Type, I was subsequently commissioned by Google Fonts to finish and release Recursive as an open-source, OFL font.
You can see Recursive and learn more about it what it can do at recursive.design.
Recursive is made to be a flexible type family for both websites and code, where its main purpose is to give developers and designers some fun & useful type to play with, combining fresh aesthetics with the latest in font tech.
First, a necessary definition: variable fonts are font files that fit a range of styles inside one file, usually in a way that allows the font user to select a style from a fluid range of styles. These stylistic ranges are called variable axes, and can be parameters, like font weight, font width, optical size, font slant, or more creative things. In the case of Recursive, you can control the “Monospacedness” (from Mono to Sans) and “Casualness” (between a normal, linear style and a brushy, casual style). Each type family may have one or more of its own axes and, like many features of type, variable axes are another design consideration for font designers.
You may have seen that Google Fonts has started adding variable fonts to its vast collection. You may have read about some of the awesome things variable fonts can do. But, you may not realize that many of the variable fonts coming to Google Fonts (including Recursive) have a lot more stylistic range than you can get from the default Google Fonts front end.
Because Google Fonts has a huge range of users — many of them new to web development — it is understandable that they’re keeping things simple by only showing the “weight” axis for variable fonts. But, for fonts like Recursive, this simplification actually leaves out a bunch of options. On the Recursive page, Google Fonts shows visitors eight styles, plus one axis. However, Recursive actually has 64 preset styles (also called named instances), and a total of five variable axes you can adjust (which account for a slew of more potential custom styles).
Recursive can be divided into what I think of as one of four “subfamilies.” The part shown by Google Fonts is the simplest, proportional (sans-serif) version. The four Recursive subfamilies each have a range of weights, plus Italics, and can be categorized as:
This is probably better to visualize than to describe in words. Here are two tables (one for Sans, the other for Mono) showing the 64 named instances:
But again, the main Google Fonts interface only provides access to eight of those styles, plus the Weight axis:
Not many variable fonts today have more than a Weight axis, so this is an understandable UX choice in some sense. Still, I hope they add a little more flexibility in the future. As a font designer & type fan, seeing the current weight-only approach feels more like an artificial flattening than true simplification — sort of like if Google Maps were to “simplify” maps by excluding every road that wasn’t a highway.
Luckily, you can still access the full potential of variable fonts hosted by Google Fonts: meet the Google Fonts CSS API, version 2. Let’s take a look at how you can use this to get more out of Recursive.
But first, it is helpful to know a few things about how variable fonts work.
If you’ve ever worked with photos on the web then you know that you should never serve a 9,000-pixel JPEG file when a smaller version will do. Usually, you can shrink a photo down using compression to save bandwidth when users download it.
There are similar considerations for font files. You can often reduce the size of a font dramatically by subsetting the characters included in it (a bit like cropping pixels to just leave the area you need). You can further compress the file by converting it into a WOFF2 file (which is a bit like running a raster image file though an optimizer tool like imageOptim). Vendors that host fonts, like Google Fonts, will often do these things for you automatically.
Now, think of a video file. If you only need to show the first 10 seconds of a 60-second video, you could trim the last 50 seconds to have a much small video file.
Variable fonts are a bit like video files: they have one or more ranges of information (variable axes), and those can often either be trimmed down or “pinned” to a certain location, which helps to reduce file size.
Of course, variable fonts are nothing like video files. Fonts record each letter shape in vectors, (similar to SVGs store shape information). Variable fonts have multiple “source locations” which are like keyframes in an animation. To go between styles, the control points that make up letters are mathematically interpolated between their different source locations (also called deltas). A font may have many sets of deltas (at least one per variable axis, but sometimes more). To trim a variable font, then, you must trim out unneeded deltas.
As a specific example, the Casual axis in Recursive takes letterforms from “Linear” to “Casual” by interpolating vector control points between two extremes: basically, a normal drawing and a brushy drawing. The ampersand glyph animation below shows the mechanics in action: control points draw rounded corners at one extreme and shift to squared corners on the other end.
Generally, each added axis doubles the number of drawings that must exist to make a variable font work. Sometimes the number is more or less – Recursive’s Weight axis requires 3 locations (tripling the number of drawings), while its Cursive axis doesn’t require extra locations at all, but actually just activates different alternate glyphs that already exist at each location. But, the general math is: if you only use opt into fewer axes of a variable font, you will usually get a smaller file.
When using the Google Fonts API, you are actually opting into each axis. This way, instead of starting with a big file and whittling it down, you get to pick and choose the parts you want.
If you’re going to use the Google Fonts API, you first need to know about font axes abbreviations so you can use them yourself.
Variable font axes have abbreviations in the form of four-letter “tags.” These are lowercase for industry-standard axes and uppercase for axes invented by individual type designers (also called “custom” or “private” axes).
There are currently five standard axes a font can include:
wght – Weight, to control lightness and boldnesswdth – Width, to control overall letter widthopsz – Optical Size, to control adjustments to design for better readability at various sizesital – Italic, generally to switch between separate upright/italic designsslnt – Slant, generally to control upright-to-slanted designs with intermediate values availableCustom axes can be almost anything. Recursive includes three of them — Monospace (MONO), Casual (CASL), and Cursive (CRSV) — plus two standard axes, wght and slnt.
When you configure a font embed from the Google Fonts interface, it gives you a bit of HTML or CSS which includes a URL, and this ultimately calls in a CSS document that includes one or more @font-face rules. This includes things like font names as well as links to font files on Google servers.
This URL is actually a way of calling the Google Fonts API, and has a lot more power than you might realize. It has a few basic parts:
https://fonts.googleapis.com/css2)family parametersfont-display property setting in a display parameterAs an example, let’s say we want the regular weight of Recursive (in the Sans Linear subfamily). Here’s the URL we would use with our CSS @import:
@import url('https://fonts.googleapis.com/css2?family=Recursive&display=swap');Or we can link it up in the <head> of our HTML:
<link href="https://fonts.googleapis.com/css2?family=Recursive&display=swap" rel="stylesheet">Once that’s in place, we can start applying the font in CSS:
body {
font-family: 'Recursive', sans-serif;
}There is a default value for each axis:
MONO 0 (Sans/proportional)CASL 0 (Linear/normal)wght 400 (Regular)slnt 0 (upright)CRSV 0 (Roman/non-cursive lowercase)The Google Fonts API gives you two ways to request portions of variable fonts:
Font styles are requested by adding parameters to the Google Fonts URL. To keep the defaults on all axes but use get a Casual style, you could make the query Recursive:CASL@1 (this will serve Recursive Sans Casual Regular). To make that Recursive Mono Casual Regular, specify two axes before the @ and then their respective values (but remember, custom axes have uppercase tags):
https://fonts.googleapis.com/css2?family=Recursive:CASL,MONO@1,1&display=swapTo request both Regular and Bold, you would simply update the family call to Recursive:wght@400;700, adding the wght axis and specific values on it:
https://fonts.googleapis.com/css2?family=Recursive:wght@400;700&display=swapA very helpful thing about Google Fonts is that you can request a bunch of individual styles from the API, and wherever possible, it will actually serve variable fonts that cover all of those requested styles, rather than separate font files for each style. This is true even when you are requesting specific locations, rather than variable axis ranges — if they can serve a smaller font file for your API request, they probably will.
As variable fonts can be trimmed more flexibility and efficiently in the future, the files served for given API requests will likely get smarter over time. So, for production sites, it may be best to request exactly the styles you need.
Where it gets interesting, however, is that you can also request variable axes. That allows you to retain a lot of design flexibility without changing your font requests every time you want to use a new style.
The Google Fonts API seeks to make fonts smaller by having users opt into only the styles and axes they want. But, to get the full benefits of variable fonts (more design flexibility in fewer files), you should use one or more axes. So, instead of requesting single styles with Recursive:wght@400;700, you can instead request that full range with Recursive:wght@400..700 (changing from the ; to .. to indicate a range), or even extending to the full Recursive weight range with Recursive:wght@300..1000 (which adds very little file size, but a whole lot of extra design oomph).
You can add additional axes by listing them alphabetically (with lowercase standard axes first, then uppercase custom axes) before the @, then specifying their values or ranges after that in the same order. For instance, to add the MONO axis and the wght axis, you could use Recursive:wght,MONO@300..1000,0..1 as the font query.
Or, to get the full variable font, you could use the following URL:
https://fonts.googleapis.com/css2?family=Recursive:slnt,wght,CASL,CRSV,MONO@-15..0,300..1000,0..1,0..1,0..1&display=swapOf course, you still need to put that into an HTML link, like this:
<link href="https://fonts.googleapis.com/css2?family=Recursive:slnt,wght,CASL,CRSV,MONO@-15..0,300..1000,0..1,0..1,0..1&display=swap" rel="stylesheet">While it can be tempting to use every single axis of a variable font, it’s worth remembering that each additional axis adds to the overall files ize. So, if you really don’t expect to use an axis, it makes sense to leave it off. You can always add it later.
Let’s say you want Recursive’s Mono Casual styles in a range of weights,. You could use Recursive:wght,CASL,MONO@300..1000,1,1 like this:
<link href="https://fonts.googleapis.com/css2?family=Recursive:CASL,MONO,wght@1,1,300..1000&display=swap" rel="stylesheet">You can, of course, add multiple font families to an API call with additional family parameters. Just be sure that the fonts are alphabetized by family name.
<link href="https://fonts.googleapis.com/css2?family=Inter:slnt,wght@-10..0,100..900?family=Recursive:CASL,MONO,wght@1,1,300..1000&display=swap" rel="stylesheet">The standard axes can all be controlled with existing CSS properties. For instance, if you have a variable font with a weight range, you can specify a specific weight with font-weight: 425;. A specific Slant can be requested with font-style: oblique 9deg;. All axes can be controlled with font-variation-settings. So, if you want a Mono Casual very-heavy style of Recursive (assuming you have called the full family as shown above), you could use the following CSS:
body {
font-weight: 950;
font-variation-settings: 'MONO' 1, 'CASL' 1;
}Something good to know: font-variation-settings is much nicer to use along with CSS custom properties.
Another useful thing to know is that, while you should be able to activate slant with font-style: italic; or font-style: oblique Xdeg;, browser support for this is inconsistent (at least at the time of this writing), so it is useful to utilize font-variation-settings for the Slant axis, as well.
You can read more specifics about designing with variable fonts at VariableFonts.io and in the excellent collection of CSS-Tricks articles on variable fonts.
If you were to using all 64 preset styles of Recursive as separate WOFF2 files (with their full, non-subset character set), it would be total of about 6.4 MB. By contrast, you could have that much stylistic range (and everything in between) at just 537 KB. Of course, that is a slightly absurd comparison — you would almost never actually use 64 styles on a single web page, especially not with their full character sets (and if you do, you should use subsets and unicode-range).
A better comparison is Recursive with one axis range versus styles within that axis range. In my testing, a Recursive WOFF2 file that’s subset to the “Google Fonts Latin Basic” character set (including only characters to cover English and western European languages), including the full 300–1000 Weight range (and all other axes “pinned” to their default values) is 60 KB. Meanwhile, a single style with the same subset is 25 KB. So, if you use just three weights of Recursive, you can save about 15 KB by using the variable font instead of individual files.
The full variable font as a subset WOFF2 clocks in at 281 KB which is kind of a lot for a font, but not so much if you compare it to the weight of a big JPEG image. So, if you assume that individual styles are about 25 KB, if you plan to use more than 11 styles, you would be better off using the variable font.
This kind of math is mostly an academic exercise for two big reasons:
font-weight a bit, say from 400 to 425!So, you don’t really need to go downloading fonts that the Google Fonts API returns to compare their file sizes. Still, it’s worth understanding the general tradeoffs so you can best decide when to opt into the variable axes and when to limit yourself to a couple of styles.
Fire up CodePen and give the API a try! For CodePen, you will probably want to use the CSS @import syntax, like this in the CSS panel:
@import url('https://fonts.googleapis.com/css2?family=Recursive:CASL,CRSV,MONO,slnt,wght@0..1,0..1,0..1,-15..0,300..1000&display=swap');It is apparently better to use the HTML link syntax to avoid blocking parallel downloads of other resources. In CodePen, you’d crack open the Pen settings, select HTML, then drop the <link> in the HTML head settings.
Or, hey, you can just fork my CodePen and experiment there:
If you are want to skip the complexity of figuring out exact API calls and looking to opt into variable axes of Recursive and make semi-advanced API calls, I have put together a simple configuration tool on the Recursive minisite (click the “Get Recursive” button). This allows you to quickly select pinned styles or variable ranges that you want to use, and even gives estimates for the resulting file size. But, this only exposes some of the API’s functionality, and you can get more specific if you want. It’s my attempt to get people using the most stylistic range in the smallest files, taking into account the current limitations of variable font instancing.
Also, Recursive is actually designed first as a font to use for code. You can use it on CodePen via your account settings. Better yet, you can download and use the latest Recursive release from GitHub and set it up in any code editor.
The Google Fonts API doc helpfully includes a (partial) list of variable fonts along with details on their available axis ranges. Some of my favorites with axes beyond just Weight are Crimson Pro (ital, wght), Work Sans (ital, wght), Encode Sans (wdth, wght), and Inter (slnt, wght). You can also filter Google Fonts to show only variable fonts, though most of these results have only a Weight axis (still cool and useful, but don’t need custom URL configuration).
Some more amazing variable fonts are coming to Google Fonts. Some that I am especially looking forward to are:
And yes, you can absolutely download and self-host these fonts if you want to use them on projects today. But stay tuned to Google Fonts for more awesomely-flexible typefaces to come!
Of course, the world of type is much bigger than open-source fonts. There are a bunch of incredible type foundries working on exciting, boundary-pushing fonts, and many of them are also exploring new & exciting territory in variable fonts. Many tend to take other approaches to licensing, but for the right project, a good typeface can be an extremely good value (I’m obviously biased, but for a simple argument, just look at how much typography strengthens brands like Apple, Stripe, Google, IBM, Figma, Slack, and so many more). If you want to feast your eyes on more possibilities and you don’t already know these names, definitely check out DJR, OHno, Grilli, XYZ, Dinamo, Typotheque, Underware, Bold Monday, and the many very-fun WIP projects on Future Fonts. (I’ve left out a bunch of other amazing foundries, but each of these has done stuff I particularly love, and this isn’t a directory of type foundries.)
Finally, some shameless plugs for myself: if you’d like to support me and my work beyond Recursive, please consider checking out my WIP versatile sans-serif Name Sans, signing up for my (very) infrequent newsletter, and giving me a follow on Instagram.
The post Getting the Most Out of Variable Fonts on Google Fonts appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
A very fun jaunt through the early days of front-end web development. They are open to pull requests, so submit one if you’re into this kind of fun chronicling of our weird history!
That CSS3 Button generator really hits home. 😬
Direct Link to Article — Permalink
The post Dark Ages of the Web appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Posted by brian.ho
Data visualization platforms have become a vital tool to help illustrate the success of a body of work. Painting a clear picture of your SEO efforts is as important as ever, whether you’re reporting out to clients or to internal stakeholders at your own company. More and more SEOs are turning to data visualization tools to do so — pulling in data from across multiple SEO tools, blending that data in unique ways, and helping to pull back the curtain on the mystery of SEO.
Platforms like Tableau and Google Data Studio are becoming more commonplace in the SEO community as we seek better ways to communicate with our teams. We’ve heard from a number of folks in the Moz community that having a central dashboard to present data has streamlined their own reporting processes. It’s also made information more digestible for colleagues and clients, as they can see everything they need in one place.
Thanks to the helpful feedback of many, many STAT customers, we’ve been hard at work building six Google Data Studio Community Connectors to help pull STAT data into Data Studio. Fortified by beta testing and your thoughtful input, we're excited to launch the six connectors today: Historical Keyword Rankings (site and tag level), Share of Voice (site and tag level), and Ranking Distributions (site and tag level).
If you’re already using STAT, dive into our documentation in the Knowledge Base to get all the nitty-gritty details on the connectors. If you’re not yet a STAT customer, why not chat with a friendly Mozzer to learn more?
Want to hear a bit more about the connectors and how to implement them? Let’s go!
Tracking daily keyword positions over time is a central part of STAT and the long-term success of your site. The Historical Keyword Rankings connectors send historical highest rank data to Data Studio for every keyword you’re currently tracking in a site or a tag.
You can start out with a simple table: perhaps if you have a group of keywords in a dynamic tag, you might want to create a table of your top keywords ranking on page one, or your top keywords ranking in positions 1-3.
Turn that table into a line graph to understand average rank for the whole site or tag and spot trends:
Find the Site Level Historical Keyword Rankings connector here and the Tag Level Historical Keyword Rankings connector here.
In STAT, share of voice measures the visibility of a group of keywords on Google. This keyword set can be keywords that are grouped together into a tag, a data view, or a site. Share of voice is calculated by assigning each ranking a click-through rate (CTR) and then multiplying that by the keyword’s search volume.
It’s important to remember that share of voice is based on the concept that higher ranks and higher search volume give you more share of voice.
The default chart type will display a doughnut chart for current share of voice, and a line graph will show share of voice over time:
Find the Site Level Share of Voice connector here and the Tag Level Share of Voice connector here.
Ranking Distribution, available in the Daily Snapshot and Ranking Trends views in the STAT app, shows how your keyword rankings are distributed across the top 119 Google results.
View your top ranking positions as a bar chart to easily eyeball how your rankings are distributed, where shifts are taking place, and where there is clear opportunity for improvement.
Find the Site Level Ranking Distributions connector here and the Tag Level Ranking Distributions connector here.
Whether you’re a Google Data Studio pro or a bit newer to the tool, setting up the connectors shouldn’t be too arduous. Get started by visiting the page for the connector of your choice. Authorize the connector by clicking the Authorize button. (Tip: Each connector must be authorized separately.)
Once you authorize the connector, you’ll see a parameters table like this one:
Complete the fields using the proper information tied to your STAT account:
Once you’ve filled in the table, click Connect in the top right.
Confirm which columns you’d like to include in the report. Review the columns, and click Create Report.
Once you’ve created a report, the exciting part begins! Whether you’re pulling in your STAT data for a fresh report, adding it into a report with other pieces of data, or using Data Studio’s data blending feature to create compelling views of your search presence — there are so many ways to slice and dice.
Ready to put the connectors into production? We can’t wait to hear how your Google Data Studio reports are strengthened by adding in your STAT data. Let us know how it goes in the comments.
Not yet a STAT user but curious how it might fit into your SEO toolkit? Take a tour of the product from your friendly neighborhood Mozzer:
To help us serve you better, please consider taking the 2020 Moz Blog Reader Survey, which asks about who you are, what challenges you face, and what you'd like to see more of on the Moz Blog.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!
These things called passkeys sure are making the rounds these days. They were a main attraction at W3C TPAC 2022 , gained support in Saf...
