DEV Community: Max Antonucci

What's the deal with align-items: baseline?

Max Antonucci — Thu, 14 Oct 2021 13:15:25 +0000

I can't count the number of times flexbox has made an otherwise painful design layout easy. My only qualm was having to calculate margins and paddings to space elements in a flex container. But now that gap has gotten good browser support, even that's no longer an issue.

But while it doesn't inconvenience me anywhere, it still surprises me.

Take the align-items property. When you have a row of items in a flex container, it controls how they line up in that row. I know how the most common values you'd give it work:

stretch is the default value, and it makes each one the height of the tallest element in that row
flex-start aligns each element to the top of that row
flex-end aligns each element to the end of the row
center aligns each element along the row's center axis

But an article I read mentioned the baseline value, and I didn't know that one. My own site's article listing is a flex container, so I threw on align-items: baseline out of curiosity.

The result...was unexpected.

// Detect dark theme var iframe = document.getElementById('tweet-1446503004912295939-669'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1446503004912295939&theme=dark" }

This confused me since the results looked inconsistent. I was guessing flexbox was aligning things by a particular element. But I checked each element and nothing explained the alignment in each row. How could an alignment changed by a single rule give me such random results?

I did a few google searches to find out exactly how baseline aligns content. But I got explanations that were either too sparse or too jargon-filled. So like all confused people with little self-esteem and even less to lose, I turned to Twitter. And I actually got a good answer fast.

// Detect dark theme var iframe = document.getElementById('tweet-1446505854354739200-455'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1446505854354739200&theme=dark" }

This was the simple answer I'd been looking for! Baseline takes the first element in each flex item, and lines things up by the bottom of that element.

This also explained the inconsistency! Posts in the first and third rows all have images, so it aligned the articles based on the bottoms of those. But the middle row has two posts without images, so it went by the element that was first instead: the dates. So while the alignment rule works, the different elements make it look inconsistent.

It also explains why the layout looks so wildly spaced in some areas. In the second post of the first row, the headline text is larger while the flex-basis is shorter. This pushes a lot of content below the baseline and creates those large gaps in the row.

All this has taught me a few good lessons about when I'd want to use align-items: baseline in the future.

It's good for content with some size variation. If you have images or text of different sizes, baseline always aligns them at the same point. So it can add some consistency where they may otherwise be none.
It's bad for content that has too many differences. It only looks at the first element and not any elements after it. My site has shown that having varying text or elements around a baseline can create lots of empty space.

My recommendation is to use baseline when your inconsistencies stay limited to the first element. Like for a list of cards that always started with headings, but you can't guarantee their font size.

As for my own site, I'm going to stick with align-items: stretch for now. Between optional featured images and different excerpt lengths, there's too much empty space.

But as with all things flexbox, this is good to know.

Featured image courtesy of this link.

The Currying Introduction I Wish I Had

Max Antonucci — Wed, 17 Feb 2021 14:21:09 +0000

Currying is one of those JavaScript words I heard many times before I understood it. That's part of why I put in the time to figure it out. The other reason is it's fun to say.

But for anyone reading this who wants to understand for non-just-fun-to-say reasons, I hope you find this post useful. This is the explanation I wished I read as I was learning the basics of JavaScript.

If you wanted to read about the best curry recipes for Pokemon Sword and Shield, I can't help you there. All I can say is Spicy Sausage Curry always wins and you have to accept that.

The Problem Currying Solves

Most JavaScript functions operate predictably:

Put in one or more arguments
Let the function do some stuff with those values
The function returns a value.
ALL HAIL THE MIGHTY GLOW CLOUD.

A basic ES6 function to multiply two values would look like this:

const multiply = (x, y) => x * y;
multiply(5, 10); // 50

But suppose I needed lots of multiplication operations that were not quite the same. For example, there were groups where one number is always the same.

multiply(3, 6);
multiply(3, 8);
multiply(3, 22); // All multiply by 3

multiply(5, 2);
multiply(5, 9);
multiply(5, 34); // All multiply by 5

multiply(7, 4);
multiply(7, 12);
multiply(7, 999); // All multiply by 7

This works, but it’s repetitive, not too elegant, and easier to mess up (especially by folks like me). This can get unmaintainable fast as the codebase scales up.

This is where currying helps. I touched on currying almost two years ago when writing about functional programming. But want to go into more detail here.

So What is Currying?

In a nutshell, currying is making a sequence of nested functions. But that wasn't clear to me at first, so here's the definition outside a nutshell.

Sometimes I may need to call several functions to get what I want, one after the other. Or like the above example, write one function with the same arguments. But imagine writing those functions and arguments in the same order over and over until my mind snaps again. Nobody wants this, especially the guy who has to fix my floorboards.

Currying lets me nest those functions inside each other. Then I only need to call one, and the function calls the rest in the proper order for me. Time, energy, and sanity are saved.

It took a while for this to click for me. If I asked the JavaScript language to explain how this would with the above examples, I imagine it'd go like this.

A Conversation with JavaScript about Currying

Coder: Look at all these multiplication functions. I could you all the arguments at once, but that's repetitive here, right? Instead, can you remember some of the arguments for me? That way when I call multiply, you can take the different argument.

JavaScript: I would remember the number three...so it'd look like this?

const multiply = x => x * 3;

Coder: That would work...but I also want you to remember functions for the other common multipliers: five and seven.

JavaScript: So write those functions out too. You'll need to give them different names.

const multiplyBy3 = x => x * 3;
const multiplyBy5 = x => x * 5;
const multiplyBy7 = x => x * 7;

Coder: That’s the result I want, but rewriting that multiplication logic feels wasteful. I want to generate different versions of that function without rewriting so much.

JavaScript: Hey, you’re the programmer, not me. You’re supposed to figure this stuff out.

Coder: Hmm...could I a function that would make the multiplying function for me? The first function is where I pass in the number I always want to multiply by. Does that one return the function that can multiply by this number?

JavaScript: Sure, it can do that! That’ll look like this:

const multiplyCurrier = y => x => x * y;

const multiplyBy3 = multiplyCurrier(3);
// This is a function that multiplies the argument by three
multiplyBy3(5); // 3 * 5 = 15

const multiplyBy5 = multiplyCurrier(5);
multiplyBy5(5); // 25

const multiplyBy7 = multiplyCurrier(7);
multiplyBy7(5); // 35

JavaScript: Don’t forget that in this language we have "first-class functions." You can use functions as arguments, and you can have them return other functions. Here, I'm breaking a function down into a sequence of functions that each takes one argument. You can pass in each argument to construct lots of different functions with less work.

Coder: Hooray! This looks good and I'm fulfilled at long last!

Call Many Arguments at Once

Currying just helped me make a bunch of multiplication functions with little repetition. I can also make more if I need to. But we can stretch currying's abilities further.

The above example goes two functions deep, and I only call one at a time. But I could call that multipleCurrier function with both arguments at once if I wanted to.

const multiplyCurrier = y => x => x * y;
multiplyCurrier(3)(5); // 15

This lets me multiply two numbers without making a new function.

It also lets me get more ambitious with what kinds of functions I can make. Let's say I have a function that lets me get substrings and goes three levels deep.

const curriedSubstring = start => length => string =>  string.substr(start, length);

The arguments each function in this sequence takes are:

The substring's starting index
The substrings ending index
The string to pull the substring from

Once it gets all these arguments, it returns the substring. So if I wanted to get a string's first character, I could call them all at once.

curriedSubstring(0)(1)('potatoes'); // 'p'

But I can also save the first two levels into a separate function, and use it on its own like this.

const getFirstChar = string => curriedSubstring(0)(1)(string);
//  Note that I need to include "string" as an argument and pass it to "curriedSubstring"

getFirstChar('potatoes'); // 'p'
getFirstChar('white rice'); // 'w'
getFirstChar('sausages'); // 's'

Or I could stop at the first level, and make a function to get different numbers of starting characters.

const getStartingChars = length => string => curriedSubstring(0)(length)(string);
getStartingChars(3)('potatoes'); // 'pot'
getStartingChars(5)('white rice'); // 'which'
getStartingChars(7)('sausages'); // 'sausage'

These all show how I can tap into this sequence of functions at different points into new functions. This lets me extend the code while only writing the underlying logic and arguments once.

Enjoy Your Curry...ing

I hope you found this post useful and watch for times you can break out the currying! Anytime there are many functions with shared logic or arguments, that's often a good sign. Even for things as simple as multiplication or getting substrings.

Plus I'll say it again, "currying" is just fun to say. Understanding it gives us more reason to use it in conversation. I know this, you know this, the world knows this. I know I'm not the only one who learned it mainly for this reason. No one else has admitted it yet.

Ahem, regardless, happy currying!

Featured image courtesy of this link.

Hiding and Showing in SVG with Clip-path and Mask

Max Antonucci — Mon, 01 Feb 2021 14:18:31 +0000

Scalable Vector Graphics, or SVG, are one of those front-end tools that can open up a world of creative ideas. I've been playing around with it more, for work and to distract myself from my hollow, quarantined soul. I did both and made my first component with some cutesy SVG animation.

But near the end, I hit a snag with how SVG can hide parts of the image. Sometimes I wanted to show specific parts of an image. Other times I wanted to hide them. I couldn't get this effect for the sun and moon animations, so I got it with border and fill colors. That's not ideal, but I can always fix it up later.

But while I wanted to figure this out, I had a hard time finding a clear explanation of showing and hiding SVG. So I wrote one myself! The two parts of SVG one needs for these effects are clip-path and mask. Here I'll break down the basics of how to use them with SVG to hide shapes, images, and if you're lucky, painful tangles of repressed emotion.

Clip-path Controls What You See

Let's say I have a red rectangle, but I only want to show a small circle within it. That's when I need clip-path. A clip-path is an SVG shape you pair with a second. Anything in the second shape that doesn't overlap with the clip-path shape gets cropped out, lost, and never seen again. You destroyed it and I hope you're happy.

Ahem...anyways, here's an example. Let's start with this red rectangle.

<svg width="400" height="200" viewbox="-200 -100 400 200">
  <rect x="-200" y="-100" width="400" height="200" fill="red" />
</svg>

Let's add a clip-path to this thing. First, I need to define the circle it'll be using. It's positioned to be in the rectangle's center. But I need to define it within a clip-path. This has to go within a defs element, which is SVG's way of storing variables. Anything in defs won't directly render but can then affect other elements, like repressed memories of staring wistfully at an empty street after the third hard cider.

So within the defs element, the circle must go in a clipPath element. It also needs a unique ID for reference.

<defs>
  <clipPath id="clip-path">
    <circle cx="0" cy="0" r="50" />
  </clipPath>
</defs>

Now, this clip-path circle can be used with the red rectangle. It needs the clip-path attribute with the unique ID, which looks like clip-path="url(#clip-path)", and it's good to go.

<svg width="400" height="200" viewbox="-200 -100 400 200">
  <defs>
    <clipPath id="clip-path">
      <circle cx="0" cy="0" r="50" />
    </clipPath>
  </defs>

  <rect clip-path="url(#clip-path)" x="-200" y="-100" width="400" height="200" fill="red" />
</svg>

You can see the final result below. The light yellow area is where the rest of the rectangle is being hidden below the clip-path.

Mask Controls What You Hide

Once I finally peeled myself off the couch and found the will to keep working despite the terror of it all, I asked, "What if I want the reverse result? If I want to hide everything except that red dot?" To do that, we need a mask. But this approach is a little more complex.

With clip-path, I only had to define a visible area. With mask, there are two steps:

Define a visible area. Anything outside it gets cropped out.
Define what areas within the visible area are also cropped out.

This is like a clip-path but with a lot more potential for what to show and hide, but will only realize once it can experience regular human interaction again. But I only needed these lonely basics to the desired result. If you want to see what it can do, including using shades of gray for translucent effects, check out this blog post of mask examples.

First, defining a visible area here is easy: I want the rectangle to be visible! I'm hiding space within the rectangle, so the entire rectangle itself should be my visible area. I define this within a mask element, which can also go in the defs element.

<defs>
  <mask id="mask">
    <rect x="-200" y="-100" width="400" height="200" fill="white" />
  </mask>
</defs>

Notice the fill="white" I added to the shape. That's important because, in a mask, the visible area must have a white fill color. Don't you dare deprive it of what it needs. You monster.

Now I need to decide what area to hide within the visible area. This is the circle in the middle of the rectangle. This time it needs fill="black" to hide it.

<defs>
  <mask id="mask">
    <rect x="-200" y="-100" width="400" height="200" fill="white" />
    <circle cx="0" cy="0" r="50" fill="black" />
  </mask>
</defs>

With this basic mask complete, we can connect it to the red rectangle. It's done the same way as clip-path but with the mask attribute.


<svg width="400" height="200" viewbox="-200 -100 400 200">
  <defs>
    <mask id="mask">
      <rect x="-200" y="-100" width="400" height="200" fill="white" />
        <circle cx="0" cy="0" r="50" fill="black" />
      </mask>
  </defs>

  <rect mask="url(#mask)" fill="red" x="-200" y="-100" width="400" height="200" />
</svg>

This gives me what I want: a full rectangle missing the center circle. The result is below with the light yellow again showing what's hidden behind the mask. The SVG mask anyway, not the mask of positivity hiding the sense that nothing will truly be okay again.

Not that mask. The SVG mask.

Bonus Challenge

My written example is redundant. It defines the same rectangle shape twice, but with different fills and masks. SVG lets you define a shape once and use it elsewhere, like a variable reference. I did that in my CodePen example - check the code and see how that works!

Wrapping Up

I've still got plenty to learn with SVG, but clip-path and mask are two foundations I'm sure will help me make cooler stuff. If you're like me and feel jealous of the cool, graphic stuff you see developers making on CodePen, SVG is one of the first steps to making similar work and assuaging the deep desolation fermenting within one's soul.

Rereading this post, I think the second part may just be me using learning to handle the mental stress of extended quarantine. But the point about writing better code still stands.

So focus on that. I need to take a long walk. To the wine shop.

If you're not sure where to start, this Pen that doubles as a basic SVG tutorial helped me immensely. You can also grab a copy of "Practical SVG" from the "A Book Apart" series.

Featured image courtesy of SafeBooru.org

What is Programmatic Determinability?

Max Antonucci — Mon, 18 Jan 2021 11:20:57 +0000

The phrase "programmatic determinability" appears a lot in the Web Content and Accessibility Guidelines (WCAG). It's also the kind of phrase that could make you sound smart or conceited, depending on how you use it. For these two very important reasons, I wanted to figure it out.

The official definition of "programmatically determined" kind of helped, but only kind of.

Determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

This is a bit...dense. So I want to unpack it a bit.

A Conversation Between Users and websites

The most succinct definition I can think of programmatic determinability stops misunderstandings between users and websites.

Sometimes you get into arguments with people who refuse to say why they're upset. No matter how many questions you ask, they only give variations of "I'm upset and you should already know why." It's impossible to reach any kind of agreement or resolution, and most likely you storm off on them with less-than-pleasant thoughts.

A better scenario is you meet someone upset, and when you ask why, they say they're upset a store no longer sells their favorite cheesecake. You probably can't fix the underlying issue, but now you can do more helpful things like:

Share a similar experience to show them they're not alone
Offer to get some cheesecake from a new place so they see there are still options out there
Join them in their rage so they blow off steam by smashing cheesecake cardboard cutouts you coincidentally have lying around
Offer use of a time machine to go back to when it was still sold so they can have it one last time and bid their cheesecake a fond farewell. Then the clouds part, the light shines through, and they can take another step forward in life as the credits roll.

The first fruitless, frustrating argument version is a website without programmatic determinability.

Your website (the angry friend) isn't giving enough information to users using assistive technology (the frustrated friend). The user asks but gets nothing, doesn't know what to do next, and leaves in a huff.

Want to avoid that scenario? That website needs that info in a coded format the browser can understand. Then the browser can share it and the two friends, user and website, can finally reconcile. This is programmatic determinability.

Share "Obvious" Info with Users

Here's a specific example: say an English-speaking user visits a website written in a foreign language. They know it has information they need to read but can't understand it. If the computer could talk, their interaction could go like this:

User: I can't understand what you're saying, webpage. What language are you in?
Webpage: How are you not able to understand me? Everyone else can.
User: Well, I can't. Do you know English?
Webpage: What's English?
User: How do you not know that?!
Webpage: I don't know, you should just speak my language.

It goes back and forth like this for a while until the user quits from frustration. They tell all their friends how uncooperative the site was and its reputation suffers and dies on a neglected 404 page.

The site in question forgot the lang attribute on its html tag. Without that, the website couldn't tell the user it was written in Italian. It can't share the info that would end this fight between user and website since it isn't programmatically determinable.

The lang attribute is the coded way the browser can understand what the language is. When it's included, the exchange may go like this.

User: I can't understand what you're saying, webpage. What language are you in?
Webpage: I'm written in Italian. Most of my users read that.
User: I get why you'd think that, but I can only read English. Do you have any translation options?
Webpage: I don't think so, but something like Google Translate can help. When I tell it my language, it'll do a rough translation to English.
User: That'll work for now. Thanks!

Now the relationship is saved, the user isn't lost, and they can go out for cheesecake together later!

Many accessibility issues can be boiled down to this kind of argument between users and inaccessible webpages that don't communicate well.

It seems obvious where the navigation, sidebars, and main content are located in your layout. But some people won't see the layout. So you should share those relationships with roles or semantic markup.
It seems obvious what's being shown on an image. But some people won't see the images. So you should share descriptions with alt tags.
It seems obvious what you're alerting users to with brightly-colored banners. But some people won't see those bright colors, or see the page at all. So you should share how important they are through explicit text, and ARIA live regions or alert roles.

These take even more forms - knowing how to solve them for as many users and websites as possible is part of the never-ending accessibility journey. Programmatic determinability is only one part of it, albeit one of the most important ones.

Keep it in mind, and your users will never miss out on cheesecake with your website again.

What I Didn't Know in the 2020 State of CSS Survey, Part 2

Max Antonucci — Thu, 17 Dec 2020 10:31:44 +0000

Last month I wrote about the first batch of CSS goodness I discovered by taking the State of CSS Survey this year. Then I got delayed from writing this second part thanks to the continued pandemic, changing apartments, and reading the results of the State of CSS survey itself. I also think I had a birthday of some kind, I'm not sure.

Valid excuses aside, I have finally finished part two of this CSS min series. So I'll get back to it without further delay!

CSS Exclusions

The journey begins.

Most people who've worked on the front-end will recognize this kind of layout:

It's pretty simple. A designer wants to include a small image alongside the text. Having it wrap around the image lets it be included without wasting too much space.

The main way to do this is with float. It pushes an element to one side of the container, and any surrounding elements wrap around it. I do the same thing on my own "About" page. It's an established solution to this problem.

Not so fast.

Say one day your designer comes to you with this layout.

Now, float isn't going to help you at all. Floats being you to one side or the other, it can't put you between two elements. There's no real way to get this effect with Grid or Flexbox that's responsive and not excessively convoluted either.

Or so I thought.

This is where CSS Exclusions enters the scene. If you apply a CSS Exclusion to an element, you're telling the browser it's an "exclusion element" and it gets its very own "exclusion box." An exclusion box is that element telling the others around it they can't overlap or touch it. They're excluding it from its space!

That's certainly rude, but the other elements have to put up with it. The good news is they won't go out of their way to appease the exclusion element. They'll avoid it but they'll keep following their own formatting rules. If they let one element like that destroy the whole layout, it would be anarchy!

So in the above example, where the exclusion element is between two columns of text? That text will wrap around the exclusion element without leaving their defined column areas. Same thing if it was in a Flexbox or Grid layout.

Yes, you could have float-style wrap effects in Flexbox or Grid layouts! This opens up so many new layout opportunities with much simpler styling.

That, my dear friends/readers/informants, is what makes CSS Exclusions awesome.

According to current specs, you create the actual effect with the wrap-flow property. It has seven potential values that let you decide how content flows around an element. You have the basic wrapping like above, or you could clear content on the entire sides of the element. This Beyonce-inspired article has more specific details on CSS Exclusion options if you want them.

One final note, which is a disappointing one: Only one browser supports CSS Exclusions, and it's Edge, the one browser you likely never use unless you're doing cross-browser testing. So you'll need to be patient before using this in production. Or anywhere, really.

So the adventure continues.

Pointer Events

The term "pointer event" may make you think only of mouse pointers. But pointer address a wide variety of events around interacting with something online - using a stylus, touch screens, or other kinds of assistive tech. As long as the trigger can be focused around coordinates on a device (the point on the screen), pointer events shall handle them.

The pointer-events CSS property lets you set the circumstances that the selected element can become targeted by pointer events. You could use CSS to give a link no pointer events so you could only interact with it like normal text.

There's a lot of possible values for the pointer-events property, but most relate to SVG that I won't go into here. The main ones for HTML elements are keeping the default, removing them all, or basing it on what the parent element's pointer events are.

The CSS Tricks Almanac (a great resource overall) gives the above example of where you may want to use the pointer-events property: letting users click through overlays or other elements that may block other elements you want to let users keep access to.

Color Gamut

A sad truth is we are not like the mantis shrimp. We only have three color receptors in our eyes, and the mantis shrimp has twelve. They can see color in a way far beyond our puny human brains.

We also can't attack people with lightning-fast strikes carrying over 200 pounds of force, but one depressing fact at a time.

But at least our computers are getting better at seeing new colors. Some desktops can display colors at a level we don't know about when we're picking our website's colors, also called a "wide-gamut display." That's a quick way to a lackluster-looking site, picking colors that don't make use of all these possible color options.

We have an advantage over the mantis shrimp here. We have CSS! It brings us three new color modes to make use of this wider gamut of color options: lab, lch, and display-p3. I won't get into their syntaxes here, but those who want to know more now can read this CSS Tricks articles on using these new color modes. But to understand color-gamut, you only need to know they exist.

Why? Because it's the media query that lets you use the colors when available!

Say you have a basic red color as a hex value. But you also have a nice display-p3 color you want to use for desktops that can. You can include both by using the media query like so:

:root {
    --red: #FF0000;
}

@media (color-gamut: p3) {
    --red: color(display-p3 1 0 0.331);
    /* Let us presume this is a nicer red color */
}

There are other ways to handle like, like a @supports query or passing a fallback to the color() function. But the media query gives you more control and lets you add additional styles behind the query if needed.

Line-clamp

This property was easier to learn since you can guess it from the name. Line-clamp lets you set a maximum number of lines for an element to show. If there are any more lines than that, the CSS clamps down on them and treat them as overflow.

You can see some basic examples of how this works below.

You can also handle the overflow in different ways that CSS already allows. You can hide the extra text altogether or let users scroll to see more. The latter could be useful with modals that could have an unpredictable number of lines.

I welcome this property and am glad it already has surprisingly good browser support. The past tricks I've used to limit text to one line took modifying white space and manually adding ellipses, which worked but was a lot of hassle to get right. This is simpler and even adds ellipses for me. All it needs now is to put the extra mint on my pillow.

New Units of Size

I only use rem and pixel units in my styling these days, but there are some other CSS units worth remembering in the future.

First are three that don't need much explanation to most people - mm, cm, and in. They refer to their real-life measurement units of millimeters, centimeters, and inches. They're absolute values like pixels, which means they won't change if users adjust their browser for bigger font sizes. But they can be useful if you're styling a print-specific version of a webpage since you're working within more static sizes for your content anyway. That and they're the units many people are already used to when designing for print.

The fourth unit I found, ex, is a little trickier. "Ex" is a relative size unit equal to one unit of the current font's x-height. A simple way to find the x-height value is to measure how high the letter "x" is in that font.

This is how much 1ex unit will be. It'll be equal to most other lowercase letters too. So it's useful for lots of typographic spacing, on a large or small scale.

New Pseudo-Elements

The only pseudo-elements I knew before were ::before and ::after, and I thought they were mainly for adding extra elements for more advanced styling. These new pseudo-elements have similar functionality but with more precise purposes.

First is ::marker, which can only be used on list items. ::marker lets you adjust a few styles for the item's "marker box," or element that identifies them as a list item. For example, an unordered list's marker boxes are bullets, while ordered lists have numbers.

::backdrop, meanwhile, can only be used to style the backdrop behind the dialog element. So adding a full-screen, transparent backdrop would be as easy as one more line of CSS. It even makes use of the Fullscreen browser API to create the effect for us. Which I didn't even know was a thing until now.

Seeing that dialog backdrops are already included in dialog elements makes me even more eager for this HTML5 element to get stronger support. Dialogs are nightmares, but this element could make it easier to handle. Both these pseudo-classes (as well as dialog) only have mixed to decent browser support, so don't go crazy with them yet.

The :is() Selector

The :is() selector is the next in the "Let CSS do naturally what Sass can do" series, following custom properties replacing Sass variables.

Say you want to select all paragraphs in an article or section tag. Using Sass, you'd write it like this.

article,
section {
    p {
        // Styles goes here!
    }
}

This would get compiled into the following CSS.

article p,
section p {
    /* Styles go here! */
}

This does what you need, but the compiled styles can grow surprisingly fast. Especially if you needed to style other elements in those two, like ordered and unordered lists.

article p,
article ol,
article ul,
section p,
section ol,
section ul {
    /* Styles go here! */
}

It's compiled into six separate rules just from that! On a larger scale, you could even get dozens to try for this "matches any of the above" selector effects.

The :is() selector gives you that same effect without the preprocessing. You could theoretically get the same effect as above with this.

:is(article, section) :is(p, ol, ul) {
    /* Styles go here! */
}

One selector rule that targets all the same styles, no Sass needed. In some ways, it's even better since it's more readable than nested rules that grow out of hand.

The most interesting thing about this selector is it's the third attempt to get CSS a selector like this, the first two being :any() and :matches(). As this other CSS Almanac on the ":is" selector points out, these first two put together have decent browser support. Presuming :is() gets finalized into CSS later on, it would likely replace those two. But until then, there's a somewhat convoluted but workable way to use this today if you want.

Link Selectors

Turns out you can target link elements with more than a mere anchor tag selector.

First off is :any-link, which looks for any possible element that has an href attribute (including the lesser-known link and area). This includes any link elements that have been visited and you'd need to use :visited to target otherwise. It's got pretty good browser support, so you can use it today!

Next up is :local-link, that only targets links in the current domain. So you can easily change styles between links to other sites and links staying on your own. An example I can think of is distinguishing external links in any site navigations, since otherwise, users may assume all those links stay in your website. One website I saw said you could even target it based on sub-domains, like links only in your local /blog/ pages, but couldn't confirm this anywhere else. But unlike :any-link, this is still a working draft and has zero support as of this writing.

Third up is...nothing. There were only two link selectors I wanted to cover here.

I could have organized this section up better.

Form Controls

These pseudo-classes are all about form inputs and their states. There's a bunch to cover, so I'll tackle them all lightning round style.

valid and invalid only work for required fields with at least one rule, like being a number or falling in a certain range. You can also pair them with the :focus selector to only show the styles on user focus.
user-invalid is the same as invalid, but only kicks in after the user has interacted with the field once. So if a form loads with a pre-filled, invalid value, these styles won't kick in until the first interaction.
indeterminate is a tricky "maybe" state in some inputs, most commonly seen in checkboxes. The browser sees indeterminate inputs as "unchecked," but are styled differently to look like a kind of half-yes, half-no. You can also only get this state by using JavaScript. So I'd avoid relying on this state without a good reason, even with good support for it.
:in-range and :out-of-range speak for themselves: they style if an input value falls inside or outside the input's set range. The most obvious example is a number being too high or too low from what's allowed.
Prosciutto is an Italian dry-cured ham that is usually thinly sliced and served uncooked, and is known as prosciutto cotto in Italy. It's notably high in fat and sodium, so for a daily diet, you may want to...oh, sorry, need to save this for the next Trivia Murder Party.

Phew, that's a lot to cover in an already long blog post. I'm off to the bonus round before I wrap this up.

In Conclusion

Even after two whole posts, there's still content from the CSS Survey I haven't covered! They're mostly methodologies, podcasts, newsletters, and more. But I barely had time to write this amid moving and a pandemic, so I'm going to pass on those for now.

So I'm closing the books on this little mini-series. Some people may understandably think I only scratched the surface of what these tools can do and how to demonstrate them. I would agree with them, and encourage them to look into them more! There are way too many nuances of functionality, overlap with past CSS properties, and browser support to cover in one post. Any one of these sections could have been a separate blog post. I encourage anyone up for it to try writing one of them!

I also encourage them to get six to eight hours of sleep and floss regularly. But once you have those covered, the blog writing awaits.

What I Didn't Know in the 2020 State of CSS Survey, Part 1

Max Antonucci — Fri, 06 Nov 2020 14:55:38 +0000

Like all humans, I like answering questions since it makes me feel smart and powerful on an unconscious level. My most recent indulgence of this was the 2020 State of CSS Survey, which has the added benefit of helping my industry. But it was mostly for that first reason.

That got thrown off when I saw how many CSS topics I knew little or no details about. I took note of them all as I filled out the survey. When I'd finished, I saw the survey was thinking the same thing as me.

The catch is there were so many things I wanted to check, I couldn't fit them into one post. So here's the first part with what they recommended I check first, and with the rest coming later.

Logical Properties

If you're like me, you read web content in English, which is read from left to right. Let's say I was coding a blog post layout and needed some extra margin where the text started. I'd add some CSS like this, right?

.blog-content {
  margin-left: 2rem;
}

However, plot twist! Not everyone on the Internet reads in the same language. Some people, shock of shocks, read it in languages that don't go from left to right. For example, Arabic and Hebrew alphabets are read from right to left. Chinese and Japanese can be written vertically from right to left. So that margin-left for "the starting side of the content" won't work if the user switches to one of these languages.

I admit these are unlikely to virtually impossible scenarios for many sites. For some, like personal developer blogs run by twenty-somethings who finally gave up on Internet fame, these are extreme edge cases. But it still happens, and front-end developers are all about building in solutions for a cohesive, inclusive experience.

That's where logical properties come in. We could rewrite the above CSS to something like this.

.blog-content {
  margin-block-start: 2rem;
}

Now the margin's position is set relative to the start of the writing mode. If the user is using a left to right writing mode like English, it's put on the left side. Right to left writing modes go on the right side automatically. Used right (pun intended), logical properties keep layouts accessible in the face of different languages and reading styles. The current spec lets you use them for margin, padding, border styling, and absolute positioning.

You can read a much better, more detailed explanation of logical properties from Rachel Andrew here. Or you can see a quick demo of hers below.

I should note at the time I'm writing this, there's little browser support for this feature. But it's good to get a basic understanding early on so you're ready to use it when you can.

Contain

Some parts of a webpage may change even after it's loaded up. A list of recent tweets on a personal site may show new tweets as they're posted. A browser will see this happen and need to figure out exactly what's changing and optimize for it. But sometimes a browser may try to optimize the entire webpage around the change, not just the Twitter widget showing the new tweet. That's quite bad for performance.

Contain tells the browser it'll only need to optimize things for that area. So I could add this to my Twitter widget:

.twitter-widger {
  contain: layout;
}

This tells the browser "if you see a change in this element, only optimize things for it and not the entire page." How the browser actually handles this depends on the browser itself. This property only lets developers pass that info along.

I used contain: layout in this example, but there's actually other values you can use with different effects. Once again, Rachel Andrew already explains the specifics of CSS Contain better in this (better) article.

backdrop-filter

I've seen lots of blog post designs built around text placed over a big banner image. My own blog used a design like this until recently. The problem is text right on the image is hard or impossible to read. A common solution is giving it a solid color background, which isn't too pretty but makes it readable.

There's another, more stylish way with backdrop-filter!

For any design with a visual right behind an element, like a banner image behind a blog title, this property can be helpful. Instead of blocking it out from the blog title entirely, it can add filters between the title and the image acting as the backdrop. The filters only affect the overlapping area, not the entire backdrop.

With this, we can add a few filters to make a "frosted glass" effect. I can blur the image, lower the contrast, and brighten it up.

Now the text is easier to read while letting the original image shine through for a sleeker, more polished effect. Most browsers supported this except for IE and Firefox. I happen to use Firefox a lot, so I hid backdrop-filter behind a @supports query with basic light blue background color as a fallback. Progressive enhancement always wins!

touch-action

This touch-events article from CSS Tricks has a good example of where to use these. Say a user on a mobile touch device is trying to zoom in and out with pinch gestures. But instead of interacting with the map, they're just zooming in and out of the page itself. The browser event listeners are set up to see "pinch gesture" as "zoom in and out." So the developer needs to override and remove those for this map!

Before, coders would need to handle this with JavaScript by hooking into the page or component and overriding the needed gestures. But touch-action lets them specify any touch events to keep from the CSS.

.map {
  touch-action: none;
}

This turns off all browser touch events for the map, and any others need to be added through the JavaScript. But it also lets developers specify which events to keep.

.map {
  touch-action: pan-x pan-y;
}

This tells the browser to only handle touch events for panning around the map, while turning off the rest (like zooming). The end result is developers have more control over their user's touch experiences before they get messy and out of hand.

...I'm going to ignore how dirty that sounded and move on.

overscroll-behavior

There have been times I used websites with modals.

They were dark times I don't like to discuss, but I need to for this example. So bear with me if I stare off and scream for a moment.

Let's say a site has a particularly evil modal with so much content, a user needs to scroll through it. They scroll through it real fast, abruptly hit the end without noting fast enough, and keep on scrolling. The user will be scrolling within the modal but wind up scrolling down the whole page by accident. It's not fun and makes it easy to lose one's place.

This unwanted event is called "scroll chaining," and it's something overscroll-behavior aims to stop like so:

.modal-content {
  overscroll-behavior: contain;
}

If you're scrolling in that area, even when you reach the end, it won't ever scroll you past that area. You can check this out in action below if you're using a supportive browser (which is now most of them aside from IE and Safari).

Now the user will reach the end of the modal content and go no further, as God intended.

overflow-anchor

Let's say a user is scrolling down a long webpage and stop at an interesting paragraph. Unknown to them, an unloaded large image is lurking in the areas they just scrolled by. When the user least suspects it, the webpage attacks by finishing the delayed image load! It's a sneak attack that pushes the webpage down, changing the visible viewport, and making users lose their place. Evil triumphs again and the credits roll.

Actually, this probably hasn't happened to users as much lately in most browsers. That's because browsers have something called scroll anchoring. When the large image tries to mess with what a user is reading, the browser adjusts their scroll position to match the change. While the scroll position changes, what the user sees doesn't change, and good wins the eternal battle against the vile.

This is possible due to the overflow-anchor property, which defaults to auto to enable this behavior. For the first time, evil is defeated while good men do nothing.

But there may be rare cases where you don't want good to win. A webpage may have custom scroll behaviors, difficultly loading images, or the developer wants to watch the world burn. Support for the overflow-anchor property lets them disable scroll anchoring.

For these edge cases or debugging. You monster.

font-variant-numeric

I won't lie, despite this property seeming so simple, it took me the longest to wrap my head around.

The simplest explanation I have is it changes the default way certain numbers are shown. These are mainly style changes, like showing a slash through a zero, or if fractions should have a slash in the middle. This can make things easier to read or understand for users, depending on what they're used to.

Let's say I want to change how numeral expressions like "1st" and "3rd" appear on my website. font-variant-numeric can change that in ways that are both correct and incorrect.

I personally see limited use cases for a feature like this. But that could be because it's outside my range of experiences or needs, so I'll limit my judgment for now.

font-display

You remember the "flash of invisible text (FOIT)," one of those problems that haunts designers and developers in the dead of night? When coders set a custom font, but until the font loads, it's invisible to the user and flashes onto the page after most or all of the page is already there. It doesn't break anything, but it's jarring and the stuff of nerd nightmares.

font-display brings us one step closer to fully solving this issue. It tells the browser to use a fallback font while waiting for the other font to load. There are a few different options for how to approach this:

Use the fallback font right away. This can create a "flash of unstyled text."
Wait a little, and if the custom font isn't ready, use the fallback font until it is.
Same as the second option, but it sticks with the fallback font if the browser figures the custom one won't be used at all.

The problems around trying to load different fonts and how they affect what users see likely aren't going anywhere. But developers at least have more choice and control over which problems they'll get. This makes it easier to work around them or design better solutions.

In Conclusion

I learned a lot from the 2020 State of CSS Survey and writing this post, but I haven't even gotten through half the items on my list. So stay tuned for future posts with even more new CSS knowledge goodness!

Scheduling Blog Posts with Eleventy, Netlify, and IFTTT

Max Antonucci — Tue, 27 Oct 2020 13:57:52 +0000

There have been many benefits to moving my personal site from Jekyll to Eleventy: better build speed, not mixing Ruby and JavaScript in the pipeline, and getting a big tax writeoff. I still love Jekyll since it's what got me into static site generators, but Eleventy may have become my new default.

One of my favorite benefits is how I can schedule future posts. Any Jekyll solution I tried was inconsistent and had overly-complicated template logic at best. At worst, I tried sending new blog posts back in time and nearly got my loved ones killed and/or caught in an authoritarian hellscape ruled by French scientists.

But Eleventy, with a little help from Netlify and IFTTT (If This Than That), helped me avoid those unmaintainable or dystopian workarounds. I'm sure this interests other casual bloggers and freedom fighters, so I wrote this blog post!

Filter out Future Posts

The first step is straightforward: how do I keep Eleventy from showing future posts?

One Eleventy feature I love that Jekyll lacks is to hook into the build process. It lets you add custom collections, tags, filters, and other functionality. So I tried making a custom "hide future blog posts" collection.

This was my default JavaScript setup to gather and organize my blog posts.

eleventyConfig.addCollection("posts", function (collection) {
  return collection.getFilteredByGlob("./posts/*.md")
    .reverse();
});

This returns a simple array of blog post objects. And in JavaScript, arrays have a built-in way to take out items you don't want: the filter method! All I need is to write and pass in a filter function that removes future posts.

Here's what I started with, with post being any potential blog post the filter had to check.

const hideFutureItems = (post) => {
  let postDate = post.date;
  // ...what else?
}

postDate here is a timestamp in Coordinated Universal Time, or UTC, format. Something scheduled for October 23rd would have 2020-10-23T00:00:00.000Z as that value. I played around with this value and found it was being made with JavaScript's Date Reference. It's one of the language's built-in ways to manage units of time.

I checked the documentation, and found a method called getTime(). It returns the number of milliseconds between January 1st, 1970 (the standard beginning Unix timestamp for reasons not important for this post) and the specific date. For example, October 23rd, 2020 returns 1603411200000 milliseconds.

This seemed silly and obscure, but it gave me an idea.

Get the number of milliseconds based on the present day.
Do the same thing for the post's date.
If the post's milliseconds are higher than today's milliseconds, it means the post's date is after today. That means it's a future post and will return false to exclude it.
All other posts should be included by returning true.

The result is a smug, satisfactory feeling of smartness...and this function I added to the collection function.

const hideFutureItems = (post) => {
  let now = new Date().getTime();
  if (now < post.date.getTime()) return false;
  return true;
}

eleventyConfig.addCollection("posts", function (collection) {
 return collection.getFilteredByGlob("./posts/*.md")
   .filter(hideFutureItems)
   .reverse();
});

With that, I exiled all future posts from my website!

2) Set Up Daily Deploys

Everything so far is good but has a major blind spot. The date the site sees as "today" is only set when I generate the site pages.

Let's say I relaunch my site on Tuesday that included a scheduled post for the next day. The site's going to think it's still that exact Tuesday for days and even weeks afterward. I could only "schedule" posts if it checks the date and rebuilds itself each day. But relaunching my site each day is the kind of monotonous chore I want to avoid!

That's where Netlify and IFTTT come in.

First, Netlify lets you add build hooks. These are URLs you can send a POST request to that trigger new builds. I set one up for daily builds and copied the given URL.

Now I had to hit this URL each day. I remembered IFTTT as a tool for making simple, conditional web actions. So I can link their "time" and "webhook" services together into "send a POST request to this webhook every day at 7 am."

There are some costs to this. I saw Netlify has set up built-in bandwidth and build time limits for starter accounts like mine. But considering how light and speedy Eleventy builds are, and I don't have any heavy apps hosted on Netlify, these shouldn't be an issue for casual bloggers like myself.

In Conclusion

Moving from Jekyll to Eleventy wasn't easy, but on the whole, I've found it worth it. If you're a programmer looking for a personal website side-project, I recommend this. If not for all these perks, at least do it to distract your mind from the field of damnation that is the world.

So happy scheduling!

The Widening Anxieties of Young Front-end Developers

Max Antonucci — Wed, 14 Oct 2020 11:27:34 +0000

Last week I read Chris Coyier's essay, "The Widening Responsibility for Front-end Developers," and it hit me hard. It reminded me how the career I enjoy so much is also one of my biggest sources of anxiety.

Let me be clear: I love that being a web developer means I'm always learning. I'm finding new ways to solve puzzles and be creative. Even better, I can set the pace of my learning, so I'm not pulling all-nighters or freaking out over exams. It's satisfying to look at code I wrote a year ago and see the different ways I'd write it now. I can see all the progress I've made, especially as it relates to my growing specialization of accessibility.

But the root of that push to improve is feeling insecure in my knowledge and helps in small doses. I even wrote on my blog about how I turn my insecurity into the rising tide that lifts me.

That feeling is bad when it grows to the point where instead of learning, I'm questioning if I can handle this career. This essay reminded me how the wider those responsibilities get, the more my insecurity turns from a rising tide into a tidal wave. It makes me feel like I'm drowning in "everything I should already know." My career thoughts are tainted by worries about how I'm going to keep up. Especially when I'm already behind, and what I need to learn is increasing exponentially. What's the hope of catching up?

How the Tidal Wave Hits Me

Let's get into some specifics. About halfway through the essay, it shows a webpage design and a list of questions a front-end developer would usually ask after seeing it. They cover layout, color schemes, repeated patterns, image optimization, typography, etc.

I already know I have this kind of front-end mindset, even if I don't fully understand all the topics it listed. Someone I know recently showed me a website they made for a college course, and right away I started inspecting it on my laptop for accessibility issues, possible CSS refactors, and responsiveness. The person didn't ask me too, and I was so engrossed I couldn't see their reactions. But I assume people always like it when I offer piles of unwanted website criticism. It's the best gift one can give, as I tell myself.

Then I went further to the second batch of questions from the same design.

Managing API requests and their source.
Dealing with complex or shared state.
Client and server-side rendering options.
Any JavaScript frameworks and their related configurations.

I already felt like I was drowning in it all.

It was extra rough since they made me think of the many new questions and topics I've tried to answer at my current job. It's been tougher to give my growing accessibility specialization the attention it needs, even as the company tries to invest more in it. These new questions are about:

How can we best use Ember's Glimmer syntax in new services and controllers?
Can I figure out the rhymes and reasons for using TypeScript? How do these rules get adjusted in an Ember app?
Can new components in a Rails application be made better as React components sprinkled onto the main page? In what way are those assets configured?
How are new API endpoints added on a Rails app with GraphQL? How does that information get sent to an Ember App using Apollo? Are they checked right with TypeScript? Do the client-side fairies approve? Do they watch me as I sleep?

These all lead to the biggest questions of all, and the most painful ones.

Did I overestimate my intelligence or love of learning?
Am I not learning this at a fast enough rate?
Am I cut out for this if I can't go fast enough?
Will I be a burden to the rest of my team?
Should I keep trying?

Takeaways for The Younger Developers

I can't claim to have gotten past all this myself. If I did I probably wouldn't have written this blog post, and I'd be spending much less time curled up on my couch eating pita chips. But when I've felt the tidal wave starting to pull me down at times, I found some reminders to bring my head back up for air.

Don't Let Perfectionism Freeze You

Perfectionism is the ice that's spent months creeping up my back when I tried to write something new. It froze my hands over the keyboard, saying I couldn't write something if it wasn't 100% original or creative. It's kept me from reading as much about new code languages or tools — I knew learning meant making lots of mistakes, which my mind couldn't handle.

To that, I remind myself: I am human. If I was a perfect robot, I'd be the one executing the code instead of writing it (as I plan to destroy all humans). I should give myself a break and take pride in being better than I was yesterday. If a person dismisses me for having a hard time swimming up after a tidal wave hits me, it's not a problem with me. It's a problem with them and their expectations. They need to remember we can't become better without failing first.

I had to remind myself of this lesson so often, I engraved it onto a piece of wood.

You may ask me, "Well Max, I like this quote, but why did you pair it with random artwork of Pokémon Sword's fighting-type gym leader? Especially when you played Pokémon Shield and never fought her yourself?" To which I say, the reader who is disturbingly informed about my video game history, why not?

Put the Fundamentals First

Most shiny developer tools come and go with time, situational needs, or when the links to their GitHub repositories get rusted shut. The basic tools and skills are going to be around a lot longer, maybe even forever. Investing in those gives you a strong foundational value to build specializations on. Under the tidal wave of new responsibilities, fundamentals are the boogie board that helps pull you back up. These include:

Becoming fluent in a good text editor
Understanding Git or another tool for version control
Getting used to the command line
Talking to humans as well as computers
Building a fast typing speed
Find answers in online documentation and APIs

The Pragmatic Programmer is my go-to recommendation for anyone who wants a full understanding of the core of programming. I think you should read the whole book yourself, but if you're strapped for time, I have notes on the broad concepts and ideas from the Pragmatic Programmer here. Just know that, at the time I'm posting this, the notes are a work in progress.

Remember Your Love of Coding

Lastly, the essay started with what makes front-end development unique and awesome.

Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.

I felt similar when I took a college coding course out of curiosity and it changed my career (alliteration!). I loved learning new things in my course but was frustrated by how abstract they were. Coding was the first thing I found with a real bridge from intellectual abstractions to pragmatic reality. We took ideas about the Document-Object Model, CSS style inheritance, and the insane world that is JavaScript, and brought them to tangible life with that sites people could use to share their thoughts, donate to food aid, or play major roles in destroying civilized democracy.

I've worked more on the server-side these last few years, and the disconnect between it and what we see in the browser has brought back the familiar frustration. Being able to see and play with my code right in a web browser is what makes front-end development feel so "real" to me. It's what makes me feel like my job is fun, challenging, and has a purpose. That's pretty rare and shouldn't be taken for granted.

So when the tidal wave pulls me under again, it's easy to question if any of this is worth it. But I remember how much joy I get when my head is above the water, and it makes swimming back up worth it each time.

Six Surprises I Found in the WCAG 2.1 Accessibility Rules

Max Antonucci — Mon, 12 Oct 2020 12:03:41 +0000

I've been settling into my accessibility specialty for a while. But I'm ashamed to say I haven't spent much time looking over the Web Content Accessibility Guidelines (WCAG) in detail. I've read through the larger goals, like being Perceivable and Operable, and the most common criteria websites struggle with, like color contrast. But I haven't poured over the specifics of each rule as much as a specialist should. Looking closer at even the simplest rules reveals nuances, gotchas, and alien messages most people would overlook.

So I used a recent accessibility audit as a chance to look more closely at the WCAG 2.1 requirements. Even with everything I've already read, I found unexpected bits on the rules I knew, and even some rules I'd overlooked altogether. These are six of the bigger overall surprises I found and how they changed my understanding of the standard.

Skip Links Aren't Always Needed

I've read so many articles saying users need "skip links" to jump over repetitive content like the menu. It saves time and aggravation for keyboard and screen-reader users. The 2.4.1 success criterion refers to these mechanisms as a "bypass block." It mentions skip links as an example of a bypass block, but there's another way!

This other way is with landmarks, which are how assistive tech finds elements with specific roles. Proper landmarks make it easier to know where the navigation, main content, sidebar, and whatever else are. Users can then jump between them and read their content much easier.

For example, say you're using the screen-reader tool VoiceOver on a Mac. You go to a web page and you can open up VoiceOver's "rotor" menu. This breaks down the page's content in many useful ways. You can see elements like:

All the site landmarks
A list of all the links or headings
Any form inputs with their current info or state

From any of these, you can jump to their place on the page. This is the screen-reader user's version of skimming over a webpage and jumping to what they need.

I've used VoiceOver to test out webpages before, but this was the first time I'd tried the Rotor menu. It showed me the direct benefits of "good semantic markup" and "readable link text." Before this, I'd pushed for them while only having a more abstract idea of how they helped.

Perhaps most important, I found new ways to improve my site's accessibility. With other content and styled stripped away, I more easily saw repetitive or vaguely-named links, too many article tags, and weirdly named heading text. This was a reminder that you can get the technical markup right but still give a muddled experience that damages accessibility. It drives home more how important manual testing and direct experience are. The infamous article where Manuel Matuzovic builds an inaccessible webpage with a perfect Lighthouse score drives this point home even better.

In the end, the biggest surprise wasn't that I may not need a skip link. It was seeing the reason why I didn't need one, and the new things to learn it exposed me to. I made a note for the future: I have a lot more to learn about using a screen reader.

Some Common Tips Aren't Commonly Needed

I've read so many articles recommending some accessibility fixes, I assumed they were required for the AA standard most businesses need to meet. Some of those tips include:

Make sure any interactive elements on the phone are at least 44 pixels wide and tall. There are a few exceptions, like for inline links in the text.
Get rid of long words and unneeded jargon to lower your content's reading level. This makes it easier for users with cognitive stress cases or who have a lower level of education. Tools like the Hemingway app can break down the reading level in real time.

Turns out they're not the main requirements! The actual success criterion, 2.5.5 for touch target size and 3.1.5 for reading level, are both at the AAA level. This is the highest level due to these requirements taking a higher level of time and resources to meet. They also may not be possible for many types of content.

I can understand why a low reading level isn't always possible. Some content, by its very nature, will be full of unavoidable jargon. A website for Neurology case studies can't be simplified or explained easily to people who don't know the subject.

But I don't understand why touch target size isn't at the AA or even A level. It doesn't make sense for businesses needing to make websites responsive for mobile devices, but not make those mobile interactions easier with larger touch elements. Even if it's not a legal requirement for most companies, I would still treat it as such considering how much it helps users.

Consistency Really Matters

Consistent content is understandable content. Changing the explicit or implicit rules of your site without warning will upset anyone. But there were some consistency rules I still didn't expect.

Criterion 3.2.2 for inputs says that entering data should be predictable and not cause unexpected context changes. The explanation makes a distinction between context and content changes. A user on a restaurant website selecting an "order online" checkbox and seeing a list of menu items appear below it passes — the meaning or purpose of the page doesn't change.

But selecting an "order online" checkbox fails if checking it does things like:

Opening a new tab
Focusing on a new element or input
Changing the inputs to a dog adoption form

These changes disorient users that are dealing with cognitive stress cases, using assistive tech, or just in a terrible mood and don't want to be jerked around. You can be the most able-bodied person in the world, and a site that drags you all over the place would make you want to break things.

A bit further down the list, criterion 3.2.4 says components with consistent functionality need consistent identification. A search component needs a "search" label on every page, not a "search" on the menu and a "find" somewhere else.

But that got me thinking, how consistently does this mean? Am I allowed to use "search authors" in one place and "search posts" in another? The content is different, but the functionality is the same, so they should both use "search." But should the input label only have "search" and some helper text above it says "find your favorite author?" Or is what we have now consistent enough?

I'm leaning towards the former as a safer option, but my mind is still spinning like a hamster wheel. These are the thoughts that keep me up at night. That and why that moving spill-detector robot at Stop and Shop is out to get me.

You Can Give Too Much Clarification

I've read many tips that boil down to "don't assume your user has the knowledge they may not have." For example, don't assume users will understand the meaning of an icon. The page should tell their meaning explicitly with icon text, like adding "About Us" to an icon of a group of people. So whenever I was in doubt, I wrote more to make things clearer.

But a quote from the documentation's explanation of the 3.3.2 criteria on labels or instructions showed me that's not always good.

Too much information or instruction can be just as harmful as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Simply put, too much text crammed together is just as unhelpful as too little. This seems obvious now, but seeing it in the official rules drove home how I'd forgotten it. Even as I got indirectly reminded of it again while reading some manga.

All this made me wonder why this paragraph was added at all. My guess is this rule takes into account the cognitive bias that if we understand something, we assume others will too. But a lot fewer people than we'd think, if any at all, have the same foreknowledge or intuition with our website that we do.

It's another reason why meeting the WCAG guidelines matter. They help us avoid having our cognitive biases make things tougher for the user without us even realizing it.

You Need to Identify Language Changes Within the Page

For accessible HTML, one of the first tips I always see is including lang="<en/es/it/whatever>" on the html tag. This tells the browser what language the page is in. I'm guessing it's often the first tip since it's important yet easy to do, which eases people to the tougher tasks.

What I didn't know from criterion 3.1.2 is this applies to passages or even phrases of a specific text. If you're using a blockquote to share an Italian proverb like this:

Far d’una mosca un elefante.

You'll need the lang attribute in the blockquote too.

<blockquote lang="it">
  Far d’una mosca un elefante.
</blockquote>

If you don't do this, the assistive tech could real Italian language as if it was English. Here I thought the lang attribute only when on the html element — turns out it's got a day job too.

Sensitive Content has Extra Rules

Any website where you submit info on legal or financial transactions has an extra responsibility to their users I hope they know about it. Criterion 3.3.4 says these submissions have to be either reversible, checkable, or confirmable. All these help avoid mistakes in decisions that could have wide-ranging effects if done carelessly.

This has obvious benefits for users dealing with cognitive or memory stress cases. But it's also useful to anyone on these sites. Any person would want to an "undo" button for financial or legal decisions. You have to be able to double-check the amount of money you're wiring to a deposed Nigerian prince. It's another clear example of how the WCAG standards help all users, not just "disabled" users.

Having this kind of "undo" button in real life would be even better. But that's a ways away, so we'll have to settle for it in web forms for now.

In Conclusion

I feel a bit more educated on the WCAG standards after learning all these details, but I still have a ways to go. There are so many criteria I haven't read through all the details of. There are even a few surprises I couldn't work into this post, like how some websites make us see shadows in the corners of our eyes at night. It's all great info, but it's a lot and can get pretty dense.

None of this learning will happen overnight. But I still look forward to it all.

Restyling my Site's Code Snippets in Quarantine

Max Antonucci — Mon, 21 Sep 2020 13:31:36 +0000

To stay sane in quarantine, I've been busying myself with updates to my site. So far I've done the following:

Added a celebrations page
Made links to random posts and notes
Expanded the colors for different notes and shuffle them around
Expanded the Bitcoin mining operations fueled by my botnet army

But one of my favorite updates has been long overdue: restyling the code block snippets. Before they were formatted right but were bulky and awkward. I wanted them to be slimmer and better styled but still readable.

My first thought was making them look like little browser or application windows, like glancing at source code on your computer. But I later took it even further with individual styling for each coding language.

How the Code Blocks are Rendered

My site is built on Jekyll, using Kramdown to convert to HTML, and Rouge to highlight the code syntax. So for an old post of mine, the markdown I used to include a JavaScript snippet would be wrapped in triple back-ticks with the language included at the start.

Here's the rendered HTML if I did this with a JavaScript language snippet.

<div class="language-javascript highlighter-rouge">
  <div class="highlight">
    <pre class="highlight language-javascript">
      <code class=" language-javascript">
        <!-- Formatted Code Renders Here -->
      </code>
    </pre>
  </div>
</div>

The space for the formatted code is the same as the JavaScript but with lots extra span tags, so I skipped over that here. But this markup is enough for basic styling.

Basic Code Block Styling

This post only looks at the code blocks, but my site also has inline code snippets like this one. Both inline and block code will have light text on a dark background to contrast with regular text, so those styles can be used on their shared selector.

// All code
.highlighter-rouge {
  color: color(mono, white);

  background-color: color(mono, black);
}

The color functions are some extra Sass I set up to quickly pull my style variables. You'll see many similar functions in the below snippets, but they're pretty self-explanatory in what styles they return.

A big change not visible here is font-family, which before was "Bitstream Vera Sans Mono." This is a monospace font good for code, but I wanted something less blocky and awkward, so I switched to "Courier New."

Now for code blocks stylings. The below CSS cleans them up with good spacing and smaller font sizes. It also sets a max-width and horizontal overflow, so long code snippets can be scrolled without breaking the page's flow.

// block code
.highlight pre {
  margin: 0;
  padding: spacing(4);
  max-width: 100%;

  font-size: type(font-size, small);

  border-top: spacing(4) solid #c5c5d0;

  overflow-x: scroll;
}

You may wonder why the border-top styling is adding a thick, gray border on the top. Good catch! I'll return to that later.

Next is the wrapper class around the code block. It's the same highlighter-rouge class that block and inline code snippets share, but with an element selector to only style code blocks. These wrapper styles create a basic "window" effect by curving the corners and adding a shadow behind it.

// block code wrapper
div.highlighter-rouge {
  position: relative;
  margin-bottom: spacing();

  border-radius: spacing(2);
  box-shadow: container(box-shadow, 1);

  overflow: hidden;
}

Another odd bit of styling here is the relative position. If you noticed it, good catch again! Both this and the top border come into adding the code bar, which is just an extra label identifying the block as a code snippet.

This code bar should look generic since it's the default for each code block. It should be a simple gray color with the text "CODE." This is just an enhancement for sighted users, so I felt okay adding it with CSS pseudo-elements.

So a ::before pseudo with absolute positioning is an easy way to add the "CODE" text. It also shrinks the label text to a better fit and uses the code's same font family.

// Text
div.highlighter-rouge {
  &::before {
    content: 'Code';
    position: absolute;
    top: 3px;
    left: spacing(4);

    text-transform: uppercase;
    color: color(mono, black);
    font-family: type(font-family, mono);
    font-size: type(font-size, xtiny);
  }
}

This is good, but I want one more touch to make it look like I window. So I used the ::after pseudo-element to create a small button in the top right like a MacBook browser window. It can't be clicked but adds some nice visual texture.

// Button
div.highlighter-rouge {
  &::after {
    content: '';
    position: absolute;
    top: spacing(1);
    right: spacing(2);
    width: 8px;
    height: 8px;

    border-radius: 100%;
    background-color: color(primary, dark);
  }
}

That's all the foundational stylings taken care of for a nice code block. Here's an example of this very code in action!

Adding Language Labels

I noticed code snippets has classes for specific languages. For example, a JavaScript snippet has language-javascript on several elements. That gave me an idea to layer on new colors and labels for code blocks using specific languages.

First, each language snippet needs a label and color. A Sass map meets that need perfectly. I did a quick regex search of the different languages I used, and either found or made up related colors for them.

$highlight-languages: (
  'html': #ff977d,
  'hbs': #fda,
  'markdown': #332d31,
  'css': #053bb9,
  'scss': #bf4080,
  'javascript': #f7df1e,
  'json': #fcf4a3,
  'yaml': #be93d4,
  'ruby': #a91401,
  'bash': #aaa
);

Now I need to loop through them and make classes that match what Kramdown renders. The styles need to go on the wrapper, so the JavaScript example would need to target div.language-javascript. So I looped through the Sass map and interpolated the language name into a selector.

// Block code for specific languages
@each $language, $color in $highlight-languages {

  div.language-#{$language} {
    // Styling here
  }
}

But I realized a problem: the language colors are a mix of light and dark. Some will need to use lighter colors for the text and button for proper contrast. How could I tell them apart in this loop?

I've hit a similar issue before, so I know Sass has a built-in function for measuring color lightness. I set the text and button colors to two variables and added a conditional for lightness. Now the text and buttons will use darker colors if the language color is light, and vice versa.

// Block code for specific languages
@each $language, $color in $highlight-languages {
  $text-color: '';
  $button-bg: '';

  @if (lightness($color) > 50) {
    $text-color: color(mono, black);
    $button-bg: color(primary, dark);
  } @else {
    $text-color: color(mono, white);
    $button-bg: color(primary, light);
  }

  div.language-#{$language} {
    // Styling here
  }
}

All that's left is the relatively simple task of overriding some CSS properties. Namely a few colors and the code bar's text.

// Block code for specific languages
@each $language, $color in $highlight-languages {
  $text-color: '';
  $button-bg: '';

  @if (lightness($color) > 50) {
    $text-color: color(mono, black);
    $button-bg: color(primary, dark);
  } @else {
    $text-color: color(mono, white);
    $button-bg: color(primary, light);
  }

  div.language-#{$language} {
    .highlight pre {
      border-color: $color;
    }

    &::after {
      background-color: $button-bg;
    }

    &::before {
      content: $language;
      color: $text-color;
    }
  }
}

This @each loop generator creates lots of extra classes, which risks bloating the CSS file. That's why these classes only override as few styles as they need to. Everything else is already taken care of.

There is some bloat by the styles changing the text and button colors for contrast. Some language colors use the dark colors already set by default. So overriding dark colors with the same dark colors isn't needed. This is just a little code bloat, but I may still refactor it away later.

Wrapping Up

With that, this is all how you'll see the fancier code snippets throughout my site! You can see examples of it throughout the original post on my website, but here's one with another language to drive it home.

Here's the full Sass partial with all these styles, including the code syntax styling I skipped over. It's a bit long for me to copy in a snippet here, even with the new look. Although later if I want to support long snippets better, I may add a max height with a vertical scroll. There are almost always more ways to improve one's code.

I encourage coders reading this to play around with how they style their code snippets. Or take this styling as a starting point and then restyle it for their site. Like all good redesigns, it makes me more eager to write posts and share code here.

Cover image courtesy of SafeBooru.org.

Min, Max, and Clamp

Max Antonucci — Tue, 15 Sep 2020 21:35:09 +0000

I recently learned about three CSS functions I can't believe I'd never heard of before: min, max, and clamp. They let you define a fluid range of values for about any property in a single line. They sound simple but open up a lot of possibilities.

This excited me, but then I checked how long some major browsers had supported them. Most have done so for a few months, with Chrome supporting it since 2019 and Safari since 2018.

As the cliche goes, better late than never. Plus there's this whole pandemic occupying my thoughts, so I'm not upset with myself. But it's still embarrassing in a field about constant learning and following updates. So I thought I'd write a blog post about them to help anyone else who may not yet know about them. Also to prove to myself (and the world) I've finally caught up (for now).

What can These Functions do?

Let's say you have an article and want it to go full width, but stop at a certain size. CSS already makes that pretty easy with two lines.

article {
 width: 100%;
 max-width: 700px;
}

With min, you can pull this off with one line.

article {
 width: min(100%, 700px);
}

Same result, less CSS! Granted, this is a simple example, but that's because width is already a lucky property. It has complimenting properties like max-width and min-width to give it limits.

But consider all the properties that don't have this, like padding and font-size. Making a fluid CSS font size used to take complex math stuck into in a Sass mixin. But these functions bring all that to native CSS in a much simpler format.

How Exactly do they Work?

Let's start with min and max, since clamp is a combination of the two. I find the names misleading since how they work seems flipped around.

min takes two arguments: a base value and a hard maximum the first can't be larger than.
max takes two arguments: a base value and a hard minimum the second can't be smaller than.

Yes, min sets the largest possible value, and max sets the smallest possible value. No, this does not make any sense to me either. So I drew up some doodles for how the values work together as a reminder.

Thankfully clamp is easier to understand. It has three arguments: the smallest value, the base value, and the largest value. The base value is what kicks in as long as it's within that range.

p {
 font-size: clamp(1rem, 2.5vw, 2rem);
}

This example is pretty easy to understand at first glance. Paragraph tags will start at 1rem and grow as the screen size increases. But they'll stop growing when they hit 2rem. The base value just controls how fast that increase happens.

Remember when I mentioned these functions could make fluid typography faster and easier? This is exactly how one would do that.

Can I Use Them?

The big caveat with any neat CSS feature is always browser support. As of this writing, all major browsers support them except, of course, Internet Explorer. This isn't a big deal, since you can use them as a progressive enhancement over a functional baseline.

p {
 font-size: 1.2rem;
 font-size: clamp(1rem, 2.5vw, 2rem);
}

As I hope more and more designers come to learn, it doesn't need to look the same across browsers.

Go Forth and Find Your Limits!

I'm embarrassed that I'm finding useful CSS functions like these months after the fact. But they're here, they're useful, their names are confusing, but they're mostly ready to go! Go forth and embrace your CSS property limits to become more limitless.

The Rails Model Introduction I Wish I Had

Max Antonucci — Tue, 07 Apr 2020 10:52:09 +0000

As the pandemic rages on, I need to distract myself. What better way than by diving into some Ruby on Rails? I focused entirely on front-end early in my career, but have come to enjoy Ruby and Ruby on Rails for the back-end. Ruby's clear syntax coupled with Rails' convention over configuration makes it a joy to code with. I still have much to learn, but all this makes the learning fun!

Imagine, fun learning and I don't even need a magic school bus.

Rails itself has many parts to understand, so I wanted to focus on one piece at a time. So this is about the part of a Rails app that's been the toughest for me to understand, but also one of the most important - the Rails model!

This is a high-level overview of what models Models are, how they work, and their basic functions. I couldn't cover everything, so I chose the most important details based on my own experiences using Rails for the last three years. I hope it helps others build a solid foundation of understanding that lets them more easily learn the nitty-gritty details of more complex models.

With that, let's begin!

What is a Rails Model?

A Model is part of the classic Model-View-Controller design pattern and represents the data being stored on the database. Databases will hold all kinds of different records with their own info and rules to follow. In Rails, each record type has a model to keep all that info and logic tidy and organized.

Let's say you were making a library app that lets people check out books. One record type you'd want to keep track of is, obviously, the books. So your book model would help you manage important things like:

What info are we storing in the database about each book? It'd likely be the title, author, publication date, ISBN, page length, and others. Some of this data may need to be validated, like making sure it's present or is a certain type of data.
What other record types are connected to the book? We may have separate database records (and therefore models) to tracking different book genres or authors. Or we'll have different sections of the library that contain many books. The model will tell us one book record will contain one or more genres and belongs to one or more sections.
Does this model have any special methods? Maybe there's a method that calculates if the book is checked out of not. Or if its genres are appropriate for younger readers. Info like this relies on database info, but can't be stored in one since they some extra business logic.
Are there any extra tasks linked to this model? When a book is available, the model may want to send a notification to whoever wants to read it next. The model won't have the notification code itself but will say when it's triggered and how.

This post will go into more specific ways models do all these things, but not too much detail. I hope to build a basic understanding of models for readers so further research goes smoother.

ActiveRecord, Models, and Migrations

Before I go on, there are a few terms I should clarify.

Models are more of an abstract term. In a general context, models refer to the parts of a program that structure and store data in a database. Models outline the design and functionality of the data but aren't data themselves. Each bit of data is a record, and each record follows the rules set up by the model.

Imagine a model as the blueprint for making a basic building. Each actual building you build based on that blueprint is a record. Each building you make will be different in some way, like the people and businesses inside of it. But each one follows the same rules from the blueprint, such as how the foundation is set up and the approaches for adding and removing floors.

Ruby on Rails is an application framework with setup for everything already in mind, including their models. So the specific rules around Rails models won't always apply to models you see in other frameworks or software. Most of the content in this article is specific to Rails models, although the principles behind them may carry over to other model setups.

The main way Rails carries out models is using a gem called ActiveRecord. All model files build off the code already built into this gem. It has many built-in rules based on Rails conventions that developers must follow, for things like names and database fields. But following these conventions makes it easier to do what's often needed, like associations and validations. So it's important to know Rails' emphasis on convention over configuration.

Lastly, models need help from another part of the program to add data to databases. Migrations are what set up the database to properly store the expected data. Whenever you add or change a model, you need migrations to prepare the database for that new or changed data. It's like carving a circle-shaped hole in a plank before you can start putting a circle-shaped block inside it. Explaining migrations is a whole other blog post, but the Rails guides explain them well. But know migrations and models go hand-in-hand when you start writing them yourself.

It's also important to know what exactly goes into a well-written model.

The Logic a Model Holds

If you search for articles on good Rails application architecture, you'll likely find the "fat model, skinny controller" rule. It argues virtually all logic not related to network or router responses, but still related to that model's data, should be in the model.

Let's say our library app had a page to show a single book. Part of that page could show other books by the same author. To make this section, we need to query the database for books by the same author. This logic could technically go in either the controller or the model.

When I first started with Rails, I put lots of logic like this in the controller. But this isn't what a controller is supposed to do. Controllers find and update data based on user inputs. Finding books with the same author has nothing to do with user input, since it's based on data records. So it should be moved to the model instead. Later in this article, I'll give an example of a model method like this.

Just remember that any model logic should directly relate to the data. Some functionality is only indirectly related to it, like sending notifications when a book is ready. Models will call functions like this when the data requires it, but the code for the notification itself is elsewhere.

That's all the context taken care of. Let's start writing an actual model!

Let's Start a Simple Model

If we were writing a model for books in our supposed library app, it'd start like this.

# app/models/book.rb

class Book < ApplicationRecord
end

This is the simplest possible starting point. We can see some of the terms from before already at work.

The file is in the models directory. Knowing what models are based on the Model-View-Controller pattern, we know right away these files are about managing data records.
The file is named book.rb, but the class name is Book which is capitalized. This follows a basic Ruby and Ruby on Rails naming convention - the class name is the file name but capitalized and camel case.
The Book class inherits from ApplicationRecord subclass, which is from the ActiveRecord gem. So we know all the rules and functionality being pulled in to define our models.

The Model's Database Schema

For me, one of the most important yet easy to overlook parts of a model is the database schema. These are the actual values being stored in the database, making them vital to using your model correctly.

However, as of this writing, creating a model in rails doesn't automatically document the database schema. Our Book model so far works and can use its database values, but they're not documented anywhere. That means anyone else reading our code, or ourselves when we inevitably forget, will have a real hard time figuring it out.

So before adding anything else to our model, I recommend adding some comments at the top with the database schema. Or even better, use a gem like annotate_models to generate one automatically from your database migration. The result would give you something like this.

# app/models/book.rb

# == Schema Info
#
# Table name: books
#
#  id                  :integer        not null, primary key
#  created_at          :datetime       not null
#  updated_at          :datetime       not null
#  title               :string         not null
#  isbn                :integer        not null
#  available           :boolean        default(TRUE), not null
#  print_version       :boolean        default(TRUE), not null
#  ebook_version       :boolean        default(FALSE), not null
#  shelf_position      :string
#

class Book < ApplicationRecord
end

Now we can see the data given to each model by the database, as well as any validations or defaults built into the schema. For example, we could call something like book.ebook_version and know it will have a value that defaults to false for new entries.

Having these values is great, but the data being stored is on the simpler side since it's limited to strings and booleans and the like. Now we can start defining the more complex logic.

Associations

Associations are a big part of what lets all the different models work together. In this library app, they're how users can check out different books and have late fees. Or how different libraries can have different books. Associations are how we can make data easy to navigate for ourselves and users.

Let's look at an example association in our Book model. Let's say we wanted to add a model for authors, and we needed to create a relationship between authors and their books. We know each book only has one author, but each author has potentially many books. So each model needs to define their relationship to the other.

Rails make this easy to do on both sides, and in one line each.

class Book < ApplicationRecord
  belongs_to :author
end

class Author < ApplicationRecord
  has_many :books
end

It's that easy. Now for each record, we can run book.author to see the book's author, and author.books for an array of all their books. The records are connected but updated separately. So if you change an author, you'll still see that change in the data when viewing it through its book record.

Let's look at another relationship. Our library could have different custom library categories for books such as "featured," "archived," "mature," and others. Each book could potentially have many custom categories at once, and each custom category will have many books. So we'd have has_many being used on both sides. Calling each association on either type of record would give us an array of the other records.

class Book < ApplicationRecord
  belongs_to :author
  has_many   :custom_categories
end

class CustomCategory < ApplicationRecord
  has_many :books
end

Associations can get more complex along with the data. You can define associations through other models. Some may need more database schemas to link them together. There are also polymorphic associations, which I still don't quite understand myself. But the Rails guides explain the details of associations better too.

Model Methods

If you have a basic understanding of Ruby, you'll have noticed each model is still a class. Classes are built on their methods, yet so far our book model has none. So let's add some!

Model methods work off data in the database. If there's any common logic that only need to pull and organize some related data, it should go in the model. Most models will have plenty of these, especially if it's being moved to the model from controllers or views.

Methods to Get More Data

We may need to know if each book is classified as "new" if it was bought in the last month. This can be added as a method called is_new? with some built-in Rails magic.

def is_new?
  created_by > Date.now - 1.month
end

Now any book record can call book.is_new?. It will check if that book record's created_by date falls within the last month. I ended the method name with a question mark to show it returns a simple boolean without changing anything.

The example of finding books with the same author is perfect for another method. We can query all the books in the database that have the same author while excluding our own.

def by_same_author
  Books
    .where(author: author)
    .where.not(id: id)
end

Methods to Trigger Other Services

Suppose we had an entirely separate service that alerts users when their book is available. The notification code should be somewhere else, but we can reference it in a method here.

def tell_user_is_available(user)
  UserNotification(user, "#{book.title} is available to check out!")
end

This method references code in another folder, like app/notifications/user_notification.rb. I don't know or care how it would alert the user, and neither does the model. It simple passes in the needed info and that class does the work. But our book records can now alert users on their own without coupling the code too tightly.

Methods not linked to Specific Records

You may have seen all these examples are for specific book records. You need to know exactly what book you're talking about before seeing what else the author has written. But what if we wanted info related to all the books, not just specific ones? That's where class methods come in handy.

Say we wanted a method to give us all the available books. The query itself is pretty simple, but we'd need to write it slightly differently.

def self.available
  Book.where(available: true)
end

Adding self identifies this as a class method, meaning it can be called on the Book class and not just specific book records. So we can call Book.available without needing to get a specific record first.

Scopes

That last method for finding available books works, but can be fine-tuned. Rails already has a tool for limiting queries in a cleaner way less prone to bugs. That tool is, fittingly enough, scope. Any time you run a where query in a class method, it's a good idea to use scope instead.

Adding this scope to our Book class is as simple as this:

scope :available -> { where(available: true) }

The result is the same and lets us call Book.available to find available books. But we can get fancier with it too. What if each book had an array of related genres, and we wanted available books with at least one genre in common?

has_many :genres

scope :available_related_books -> (genres) {
  where(available: true)
    .select { |book|
      common_genres = book.genres & genres
      common_genres.length > 0
    }
}

After taking a group of genre objects as an argument, it only picks available books that have at least one genre in common. We'd pass the needed argument when calling it, like with Book.available_related_books([array, of, genres]).

But you'll notice we're duplicating code from the available scope. They both even have the word "available" in their names, which is a red flag. A rule of thumb with any code is each method or function doing one thing and doing it well. So let's split these scopes apart.

scope :available -> { where(available: true) }
scope :same_genre -> (genres) {
  joins(:genres).where(genres: {id: genres.ids})
}

Now we can use these separately or together if we want to. To get all available books of the same genre, we would use Book.same_genre([array, of, genres]).available.

For some extra fun, let's get fancier. Say each book's web page has an "also consider checking out" section. It has a list of five random, available books similar to the featured one. We can use these scopes in a method to give us exactly what we need.

scope :related_items -> (id, num) {
  where.not(id)
    .available
    .order("random()")
    .limit(num)
}
end

This method makes use of our custom methods, our scopes, and some basic Ruby to keep all this logic readable, separated, and in a convenient place. Now we can call Book.related_items(id, 5) for a random list of five related books.

Validations

A final but no less important part of models are validations. They came up when defining database schemas, such as making sure important fields aren't empty. But this only works for simpler validations and often won't be enough. If our library app allowed books with duplicated ISBNs or no genres, things would fall apart fast. That's why good validation keeping out bad data is essential anywhere.

So ActiveRecord makes it easy to add simple or complex validations. Validations can get quite complex depending on the data, and you could use a method like validates_with to separate your validations logic into another class. I'm going to stick with simpler ones here.

Let's go back to our two examples, as ActiveRecord has some built-in validation helpers for these cases. For our ISBNs, we can use the uniqueness helper.

validates :isbn, uniqueness: true

For ensuring our books have good genres, we can check that each one has genres passed in when they're created. We can also run an extra validation check on each associated genre object to be safe.

has_many :genres, presence: true
validates_associated :genres

Let's say we try to make a book record that uses a duplicated ISBN. If we use book = Book.create with that invalid data, three things will happen:

The data won't be persisted into the database, sparing our app future headaches.
We could call book.valid? and it would return false, letting us confirm it's not a valid book.
We could see the specific error messages with book.errors.messages. In this case, we'd get something like {isbn:["must be unique"]}. These objects can tell us, and the user, what went wrong so we can fix it. You'll often see messages from this method appear over a form in red after it fails to submit.

There are many more helpers and nuances with validations, but that's too much for this post. And to be honest, I still don't know all the details myself. Again, the Ruby on Rails guides are best for taking a deeper validations dive.

Wrapping Up

Experienced developers will likely see other parts of models I excluded and maybe shouldn't have, like callbacks or accessors. Those are fair points, but I chose these topics based on my own experiences of what's more essential to understanding models That and this article was already long enough.

I highly recommend the Rails guides for even more details on what models can do in each of these areas. Because believe me, my examples only scratched the surface. If this article helped you understand the essence of a model's role and functionality, then I encourage you to go forth and multiply your knowledge of them!

Go forth and write Rails for the world, my subjects!

Cover Image courtesy of SafeBooru.org