Collective #737










collective 737 item image

Marten

Marten is a Crystal web framework that makes building web applications easy, productive, and fun. It enables pragmatic development and rapid prototyping.

Check it out




collective 737 item image

Huge type on the web

Matej Latin explores huge type in print, looks for similar examples on the web, and tries to find out what is it that works well about those designs.

Read it


collective 737 item image

Idiot proof git

Tips and aliases that make rebase-based workflows in Git much less advanced feeling.

Read it


collective 737 item image

Bezel (Beta)

Bezel is a collaborative 3D design tool, empowering teams to design and prototype on a spatial canvas together.

Check it out


collective 737 item image

Blessed.rs

An unofficial guide to the Rust ecosystem with helpful pointers on which crates to use when.

Check it out




collective 737 item image

Cozo

A general-purpose, transactional, relational database that uses Datalog and focuses on graph data and algorithms.

Check it out




Adam Argyle’s Sick Mouse-Out CSS Hover Effect

I was killing some time browsing my CodePen feed for some eye candy and didn’t need to go past the first page before spotting a neat CSS hover effect by Adam Argyle.

I must’ve spent 10 minutes just staring at the demo in awe. There’s something about this that feels so app-like. I think it might be how contextually accurate it is in that the background color slides in from the left, then exits out through the right. It’s exactly the sort of behavior I’d expect from a mouse-in, mouse-out sort of interaction.

Whatever the case, I fired up a fresh pen and went to work recreating it. And it’s not super complex or anything, but rather a clever use of transitions and transforms paired with proper offsets. Quite elegant! I’m actually a little embarrassed how long it took me to realize how the mouse-out part works.

Here’s how I tackled it, warts and all.

“I bet that’s using a transition on a background.”

That was my first thought. Define the background-color, set the background-size and background-position, then transition the background-position. That’s how I’ve seen that “growing” background color thing done in the past. I’ve done that myself on some projects, like this:

If I could do the same thing, only from left-to-right, then all that’s left is the mouse-out, right? Nope. The problem is there’s nothing that can really make the background-position transition from left-to-right to left-to-right. I could make it do one or the other, but not both.

“Maybe it’s a transform instead.”

My next attempt was jump into transforms. The transform property provides a bunch of functions that can transition together for slightly more complex movement. For example, the background can “grow” or “shrink” by changing the element’s scale(). Or, in this case, just along the x-axis with scaleX().

But like I mentioned, there isn’t a way to isolate the element’s background to do that. Going from scaleX(0) to scaleX(1) scales the entire element, so that basically squishes the link — content and all — down to nothing, then stretches it back out to its natural size which is a totally different effect. Plus, it means starting with scaleX(0) which hides the whole dang thing by default making it unusable.

But a pseudo-element could work! It doesn’t matter if that gets squished or hidden because it isn’t part of the actual content. Gotta put the background on that instead and position it directly under the link.

a {
  /* Keeps the pseudo-element contained to the element */
  position: relative;
}

a::before {
  background: #ff9800;
  content: "";
  inset: 0; /* Logical equivalent to physical offsets */
  position: absolute;
  transform: scaleX(0); /* Hide by default */
  z-index: -1; /* Ensures the link is stacked on top */
}

“Now I need ::before to change on hover.”

I knew I could make ::before scale from 0 to 1 by chaining it to the link element’s :hover state.

a:hover::before {
  transform: scaleX(1)
}

Nice! I was onto something.

Sprinkle a little transition fairy dust on it and things start to come to life.

a::before {
  background: #ff9800;
  content: "";
  inset: 0;
  position: absolute;
  transform: scaleX(0);
  transition: transform .5s ease-in-out;
  z-index: -1;
}

“Hmm, the transition moves in both directions.”

Again, this is where I sorta got stuck. Something in my head just wasn’t clicking for some reason. As per usual, I ran over to the CSS-Tricks Almanac to see what property might’ve slipped my mind.

Ah, yes. That would be transform-origin. That allows me to set where the transform starts, which is not totally dissimilar from setting the background-position like I tried earlier. The transform could start from the left instead of its default 50% 50% position.

a::before {
  background: #ff9800;
  content: "";
  inset: 0;
  position: absolute;
  transform: scaleX(0);
  transform-origin: left;
  transition: transform .5s ease-in-out;
  z-index: -1;
}

Yeah, like this:

I was already transitioning ::before to scaleX(1) on link hover. If I reversed the transform-origin from left to right at the same time, then mayyyybe the highlight goes out the opposite of how it came in when the mouse exits?

a:hover::before {
  transform: scaleX(1);
  transform-origin: right;
}

🤞

Whoops, backwards! Let’s swap the left and right values. 🙃

Gorgeous. Thank you, Adam, for the inspiration!


Adam Argyle’s Sick Mouse-Out CSS Hover Effect originally published on CSS-Tricks. You should get the newsletter and become a supporter.

Collective #659






Practical Accessibility

Sara Soueidan is launching a web accessibility course for web designers and developers. Subscribe and be among the first to know when it’s out.

Check it out



















Madosel

A family of responsive front-end frameworks that make it easy to design responsive websites.

Check it out







The post Collective #659 appeared first on Codrops.

Chrome + System Fonts Snafu

There was just a bug late last year where system fonts (at least on Mac, I don’t know what the story was on other platforms) in Chrome appeared too thin and tracked-in at small sizes and too thick and tracked-out at larger sizes. That one was fixed, thankfully. But while it was a problem, it was the reason I gave up on system fonts for now and switched something else. A performance loss but aesthetic gain.

Now there is a new much worse bug, where the system font can’t be bolded. It’s not great, as a ton of sites roll with the system font stack as it has two major benefits: 1) it can help your site look like the operating system 2) it has great performance as the site doesn’t need to download/display and custom fonts.

Jon Henshaw wrote it up:

… the bug caught the attention of Adam Argyle, maker of VisBug and Chrome CSS Developer Advocate at Google. Argyle created a Chromium bug report, but the Chromium development team ultimately decided it wasn’t a blocker for releasing version 81. That resulted in sites like Coywolf not being able to use bold text for fonts that are larger than 16px (e.g., every heading).

The bug won’t be fixed in version 82 because the Chromium team announced that they’re skipping it, and will be releasing version 83 in mid-May instead. Argyle assured everyone on the original GitHub bug report that it would be fixed in version 83.

Above is Jon’s site. Andy Bell’s site got hit by it too.

So we’re looking at 4 weeks or so. Šime Vidas proposed a temporary fix of going Helvetica for now:

body {
  font-family: -apple-system, Helvetica;
}

I guess with -apple-system in there, older versions of Chrome/macOS still might be able to benefit from system fonts? Not sure.

That brings up a source of confusion for me. When I first heard of using system font stacks, there was -apple-system and BlinkMacSystemFont and you were supposed to use them in that order in the font stack. Then came along -system-ui, and that seemed to work well all by itself and that was nice as it was obviously less Mac-specific. But there is also system-ui (no starting dash), and that seems to do the same thing and I’m not sure which is correct. Now it looks like the plan is ui-sans-serif and friends (like ui-serif and ui-monospace). I like the idea, but I’d love to hear clarity from browser vendors on what the recommended use is. Are we in a spot like this?

/* Just a guess... */
body {
  font-family: 
    ui-sans-serif, 
    system-ui, 
    -system-ui, 
    -apple-system,
    BlinkMacSystemFont,
    Roboto, Helvetica, Arial, 
    sans-serif, 
    "Apple Color Emoji";
}

Another observation from me… as I was trying to replicate this on Chrome 81, at first I was like “weird, works for me”, because I was trying out the bolding on default 16px text. I noticed that it was when the font was 20px or bigger the problem kicked in:

Bramus has an alternative fix idea: use Inter.

The post Chrome + System Fonts Snafu appeared first on CSS-Tricks.

Max Stoiber’s Strong Opinion About Margins

Going with that title instead of the classic developer clickbait version Max used. ;)

We should ban margin from our components.

Don’t use margin?! This thing I’ve been doing my entire career and don’t have any particular problems with?!

Well, that’s not exactly Max’s point. The point is that any particular component doesn’t necessarily know what context it is in, so it also doesn’t know what kind of spacing is necessary around it. His solution? Leave it to a parent component.

I don’t have any particular problem with that. Then again, constructing things can sometimes feel overwhelming when you’ve got a route component wrapping a query component wrapping a styled component wrapping a state machine component wrapping a spacer component wrapping some kind of semantic template. If that sounds like a lot, I bet a lot of y’all’s JavaScript-built codebases nest much deeper than that already.

In this world of component-driven front-ends, we need to make sure we don’t end up with such thick soup we can’t reason through it.

This also reminds me of a bold prediction from Adam Argyle, that the use of margin will decline entirely as gap is used more heavily in all-flexbox-and-grid situations.

Direct Link to ArticlePermalink

The post Max Stoiber’s Strong Opinion About Margins appeared first on CSS-Tricks.

Four Layouts for the Price of One

Pretty notable when a tweet about a flexbox layouts gets 8K+ likes on Twitter!

That's "native" CSS nesting in use there as well, assuming we get that at some point and the syntax holds.

There was some feedback that the code is inscrutable. I don't really think so, to me it says:

  • All these inputs are allowed both to shrink and grow
  • There is even spacing around all of it
  • The email input should be three times bigger than the others
  • If it needs to wrap, fine, wrap.

A great use case for flexbox, which is the right layout mechanism when you aren't trying to be super precise about the size of everything.

There is a blog post (no byline 🤷‍♂️) with a more longwinded explanation.


This reminds me a lot of Tim Van Damme's Adaptive Photo Layout where photos lay themselves out with flexbox. They don't entirely keep their aspect ratios, but they mostly do, thanks to literally the flexibility of flexbox.

Here's a fun fork of the original.

It's like a zillion layouts for the price of one, and just a few lines of code to boot.

The post Four Layouts for the Price of One appeared first on CSS-Tricks.

Is “is” Useful?

God I'm funny.

Anytime we have fairly repetitive selectors that have a common parent, it's probably a place we can use the :is() pseudo-selector.

Holger Bartel demonstrates like this:

section section h1, section article h1, section aside h1, section nav h1,
article section h1, article article h1, article aside h1, article nav h1,
aside section h1, aside article h1, aside aside h1, aside nav h1,
nav section h1, nav article h1, nav aside h1, nav nav h1 {
  font-size: 20px;
}

Becomes:

:is(section, article, aside, nav)
:is(section, article, aside, nav) h1 {
  font-size: 20px;
}

Adam Argyle demonstrated like this:

MDN has an extra dramatic one:

ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
  list-style-type: square;
}
:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) ul,
:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) menu,
:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) dir {
  list-style-type: square;
}

It's less code and easier to reason.

Kezz Bracey notes that pairing it with :not() can be nice as well:

:not(article, section, aside) :is(h1, h2, h3, h4, h5, h6) {
  font-weight: 400;
}

Browser support is just starting to get there and polyfilling is hard, so we aren't at day-to-day no-brainer use levels quite yet. I'd bet it's not too far away.

The post Is “is” Useful? appeared first on CSS-Tricks.

Thoughts After Looking at the Web Almanac’s Chapter on CSS

Woah, I didn't see this coming! The HTTP Archive dropped this big "state of the web" report called Web Almanac with guest writers exploring data from 5.8 million websites.

Una Kravetz and Adam Argyle wrote the CSS chapter. The point is to squeeze a digestible amount of insight out of a mountain's worth of data. So there is some irony here with me squeezing in my thoughts about this chapter for an even quicker read, but hey, here we go.

  • 83% of sites make use of rgba() but only 22% use rgb(). That entirely makes sense to me, as rgb() isn't a particularly useful color format, if you ask me. It's the "a" (alpha) that gives the format the ability control transparency, which is only recently available in the most popular format, Hex, in the form of 8-Digit Hex Codes. But even then, it isn't as nice as rgba(). hsla() is arguably the nicest color format.
  • Definitely not surprising that white and black are the two most popular named colors. I use them, by name, a lot. I even change CSS commits to use white instead of #FFF and black instead of #000 because I think there is less mental overhead to it.
  • em is twice as popular as rem. Wow. I'm a rem guy myself, just because I find it less finicky and more predictable. In theory, I still like the idea of px at the Root, rem for Components, and em for Text Elements, but I'm not sure I've ever pulled it off that cleanly.
  • Classes are by far the leader in selector types. Factoring how many are used, they have over a 10x lead over anything else. I like to see that. They have a low-but-not-too-low specificity value. They have nice APIs for manipulating them. Their entire purpose is to be a styling hook. They are element-agnostic. It's just the right way to do styling. The flatter you keep styles, the less headaches you'll have., A little more surprisingly to me is the fact that the average number of classes per element is one. Makes me really wanna know the decimal though. Was it 1.1? 1.4? 1.00001?
  • Holy buckets. Flexbox on half of sites and grid only on two percent?! The browser support isn't that different. I'm well aware they are both very useful and can be used together and are for different things, but I find grid generally more useful and personally use it more often than flexbox.
  • I would have guessed the median number of loaded fonts on a site to average to 0, but it's 3! I think of CSS-Tricks as having one (which is Rubik at time of writing and used only for titles. The body font of this site is system-ui.) But really, it's 4, because of preloading and subsetting and bold versus regular and such. I wonder when variable fonts will start having an impact. I would think it would lower this number over time. Open Sans and Roboto are triple any other loaded font, and the whole list is Google Font stuff, other than some instances of Font Awesome.
  • It's funny how some major libraries can skew stats at such a global/universal scale for their use of certain features. I remember how YouTube's play button used to "morph" into a pause button using an SVG technology called SMIL. But because YouTube is so huge, it could look like a very high percentage of internet traffic includes SMIL, when it's really just one button on one site. filter is in that report. While filters are cool, it's really the fact that it happens to be within YouTube embeds and Font Awesome's stylesheet that the percentage of sites using it (78%) looks astonishingly high.
  • Of pages that make super heavy use of transitions and animations, transitions are about twice as heavily used, but, transitions are used six times more at the 50th percentile. That feels about right to me. Transitions are generally more useful, but the more animation you are doing, the more you reach for advanced tools like keyframes.
  • Looks like most websites have approximately 45 media queries on them. It's not totally clear if those are different media queries, or if they could be the same media queries repeated elsewhere in the stylesheet. That seems like a lot if they are all different, so I suspect it's just a tooling thing where people use nested media queries for authoring clarity and they bubble out but don't get combined because that's too weird with specificity. I'd be interested to see how many unique media queries people use. The most fascinating thing to me about the media query data is that min-width and max-width are neck-and-neck in usage. I would have put max-width far ahead if I was guessing.
  • About six stylesheets per site. It's probably too hard to tell because assets like this are so often hosted on CDNs, but I'd love to know how many are hand-authored for the site, and how many are from third parties. Is the distribution like three and three or like one and five?

There is a lot more in the report, and CSS is just one of twenty chapters. So go digging!

The post Thoughts After Looking at the Web Almanac’s Chapter on CSS appeared first on CSS-Tricks.

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

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


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

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

Flexbox on top, Grid on bottom

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

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

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

.parent {
  display: grid;
  grid-template-columns: 3fr 1fr; /* Two columns, one three times as wide as the other */
  grid-template-rows: 200px auto 100px; /* Three columns, two with explicit widths */
  grid-template-areas:
    "header header header"
    "main . sidebar"
    "footer footer footer";
}

/*
  Now, we can explicitly place items in the defined rows and columns.
*/
.child-1 {
  grid-area: header;
}

.child-2 {
  grid-area: main;
}

.child-3 {
  grid-area: sidebar;
}

.child-4 {
  grid-area: footer;
}
Flexbox on top, Grid on bottom

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


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

/*
  The flex children do most of the work
*/
.flexbox {
  display: flex;
  > div {
    &:nth-child(1) { // logo
      flex: 0 0 100px;
    }
    &:nth-child(2) { // search
      flex: 1;
      max-width: 500px;
    }
    &:nth-child(3) { // avatar
      flex: 0 0 50px;
      margin-left: auto;
    }
  }
}

/*
  The grid parent does most of the work
*/
.grid {
  display: grid;
  grid-template-columns: 1fr auto minmax(100px, 1fr) 1fr;
  grid-template-rows: 100px repeat(3, auto) 100px;
  grid-gap: 10px;
}

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

Flexbox on top, Grid on bottom

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


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


Here are some of my favorite tweets on the subject:

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