Author: Chris Coyier

Posted on

Custom Property Brain Twisters

Category Image 052

I am part of that 82% that got it wrong in Lea’s quiz (tweet version).

Here’s the code:

:root {
  --accent-color: skyblue;
}

div {
  --accent-color: revert; 
  background: var(--accent-color, orange);
}

So what background do I expect <div> to have?

My brain goes like this:

  1. Well, --accent-color is declared, so it’s definitely not orange (the fallback).
  2. The value for the background is revert, so it’s essentially background: revert;
  3. The background property doesn’t inherit though, and even if you force it to, it would inherit from the <body>, not the root.
  4. So… transparent.

Nope.

Lea:

[Because the value is revert it] cancels out any author styles, and resets back to whatever value the property would have from the user stylesheet and UA stylesheet. Assuming there is no --accent-color declaration in the user stylesheet, and of course UA stylesheets don’t set custom properties, then that means the property doesn’t have a value.

Since custom properties are inherited properties (unless they are registered with inherits: false, but this one is not), this means the inherited value trickles in, which is — you guessed it — skyblue.

Stephen posted a similar quiz the other day:

Again, my brain does it totally wrong. It goes:

  1. OK, well, --color is declared, so it’s not blue (the fallback).
  2. It’s not red because the second declaration will override that one.
  3. So, it’s essentially like p { color: inherit; }.
  4. The <p> will inherit yellow from the <body>, which it would have done naturally anyway, but whatever, it’s still yellow.

Nope.

Apparently inherit there is actually inheriting from the next place up the tree that sets it, which html does, so green. That actually is now normal inheriting works. It’s just a brain twister because it’s easy to conflate color the property with --color the custom property.

It also might be useful to know that when you actually declare a custom property with @property you can say whether you want it to inherit or not. So that would change the game with these brain twisters!

@property --property-name {
  syntax: '<color>';
  inherits: false;
  initial-value: #c0ffee;
}

The post Custom Property Brain Twisters appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

TablesNG — Improvements to table rendering in Chromium

Category Image 091

When I blogged “Making Tables With Sticky Header and Footers Got a Bit Easier” recently, I mentioned that the “stickiness” improvement was just one of the features that got better for <table>s in Chrome as part of the TablesNG upgrade. I ain’t the only one who’s stoked about it.

But Bramus took it the rest of the nine yards and looked at all of the table enhancements. Every one of these is great. The kind of thing that makes CSS ever-so-slightly less frustrating.

Just the writing-mode stuff is fantastic.

Direct Link to Article — Permalink

The post TablesNG — Improvements to table rendering in Chromium appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

“Weak declaration”

Category Image 052

PPK looks at aspect-ratio, a CSS property for layout that, for the most part, does exactly what you would think it does. It’s getting more interesting as it’s behind a flag in Firefox and Safari now, so we’ll have universal support pretty darn soon. I liked how he called it a “weak declaration” which I’m fairly sure isn’t an official term but a good way to think about it.

This will produce a 16 / 9 element:

.movie-card {
  aspect-ratio: 16 / 9;
}

This will too:

.movie-card {
  width: 50%;
  aspect-ratio: 16 / 9;
}

But this won’t:

.movie-card {
  width: 150px;
  height: 150px;
  aspect-ratio: 16 / 9;
}

Because you’ve explicitly set the height and width, that is what will be respected. The aspect-ratio is weak in that it will never override a dimension that is set in any other way.

And it’s not just height and width, it could be max-height that takes effect, so maybe the element follows the Aspect ratio sometimes, but will always respect a max-* value and break the Aspect ratio if it has to.

It’s so weak that not only can other CSS break the Aspect ratio, but content inside the element can break it as well. For example, if you’ve got a ton of text inside an element where the height is only constrained by aspect-ratio, it actually won’t be constrained; the content will expand the element.

I think this is all… good. It feels intuitive. It feels like good default behavior that prevents unwanted side effects. If you really need to force an Aspect ratio on a box with content, the padding trick still works for that. This is just a much nicer syntax that replaces the safe ways of doing the padding trick.

PPK’s article gets into aspect-ratio behavior in flexbox and grid, which definitely has some gotchas. For example, if you are doing align-content: stretch;—that’s one of those things that can break an Aspect ratio. Like he said: weak declaration.

The post “Weak declaration” appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

Are we in a new era of web design? What do we call it?

Category Image 052

Una is calling it the new responsive. A nod to the era we were most certainly in, the era of responsive design. Where responsive design was fluid grids, flexible media, and media queries, the new responsive is those things too, but slotted into a wider scope: user preference queries, viewport and form factor, macro layouts, and container styles.

I like the thinking and grouping here and I kinda like the name. It eludes to an evolution and extension of responsive web design rather than a rejection and replacement.

This isn’t the first crack at identifying and naming a shift between eras. Back in 2018, Jen Simmons was doing a talked called “Everything You Know About Web Design Just Changed” where she identified that responsive design was a major shift in how we did layout on the web. And yet, it was firmly defined in an era where layout tools like flexbox and grid didn’t even exist. Now, they do exist, and with them a bevy of other new features that bring more capable graphic design to the web. She called it Intrinsic Design.

I almost like Intrinsic Design more now than I did in 2018, because now, if we attempt to lump in @container queries, the name makes more intuitive sense. We (hopefully will soon) make styling choices based on the intrinsic size of elements. We make styling choices based on the intrinsic nature of the individual users we serve. We make styling choices off the intrinsic qualities of the browser.

I wouldn’t say either of the terms have really caught on though. It’s hard to make a name stick. That little burst of ideating around CSS4 sure didn’t go anywhere.

Direct Link to Article — Permalink

The post Are we in a new era of web design? What do we call it? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

Inline Styles as Classes (lol)

Category Image 091

If you’re abhorred by using inline styles, just move that style to the class attribute! And then make sure you have CSS in place that, ya know, does what it says on the box.

OK lemme dig in and totally ruin the joke.

  • First off, it’s a joke, so don’t actually do this. I don’t even mind the occasional inline style for one-off stuff, but this is not that.
  • To me the weirdest part is that period (.) character. Escaping the more unusual characters with a backslash () feels normal, but what is that period about? UPDATE: It’s because of the space. It’s two classes in the HTML, not one. Derp.
  • The little period trick there doesn’t work when the following character is a number (e.g. .padding:.1rem;). UPDATE: Because classes that start with a number are invalid. Derp.
  • You can avoid the escaping and trickery if you go with an attribute selector like [class*="display: flex;"].
  • This reminds me of Mathias Bynens’ research: CSS character escape sequences. But… that doesn’t seem to work anymore? I wonder if browsers changed or if the tool broke and doesn’t output what it should anymore (e.g. does .color\3A \ #f06d06 look right?).

Here’s all that playing around:

The post Inline Styles as Classes (lol) appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Useful and Useless Code Comments

Category Image 052

Jim Nielsen:

If somebody says a comment isn’t adding any value, I would ask: to whom?

Personally, I’ve never liked the advice that writing obvious comments is bad practice—probably because I write obvious comments all the time.

Jim showed off some examples of “code comments that are at the same level of fidelity as the code itself.” Those are the hardest calls with code comments. 

// this function adds two numbers
function add(a, b) {
  return a + b;
}

Easy to point at that and call it not useful. I tend not to leave this type of comment, but it’s fair play for Jim to question that. Comments can be used for a wide swath of people whom may at some point interact with that code, so why gate-keep it?

[…] comments can serve a very different purpose when they’re being read vs. when they’re being written. Those are almost two different kinds of activities.

I’d add they serve a different purpose when re-visiting old code vs actively working. Also different when you’re trying to code review versus directly contribute.

Direct Link to Article — Permalink

The post Useful and Useless Code Comments appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

#320: Andy and Una from Google’s Learn CSS Project

Category Image 052

Learn CSS is a very cool project from a whole team of people at Google (and outside). It does a great job of documenting where is right now, in a fairly comprehensive way. Learn CSS was spearheaded by Una Kravets and Andy Bell did the bulk of the writing, so they are two extra-special guests to have on the show to talk about it. Why CodePen Radio though? Because there are literally hundreds of Embedded Pens used in this course, all using a style guide base and are live editors in the site itself. Cool!

Time Jumps

  • 00:55 What is Learn CSS?
  • 03:07 Who’s idea was this?
  • 08:08 Sponsor: WooCommerce
  • 09:17 Snapshot of now and the future of CSS
  • 12:55 Quality content and course creation
  • 17:51 Using CodePen for demos
  • 19:27 Shared stylesheet for a design system
  • 24:06 Native CSS only
  • 26:58 How difficult was it to sell Google on this?

Sponsor: WooCommerce

WooCommerce supports Apple Pay at checkout now, which is a nice thing to offer. Some people have pretty strong preferences for how they pay online, and it’s best to meet them there rather than force one particular payment method.

The post #320: Andy and Una from Google’s Learn CSS Project appeared first on CodePen Blog.

Posted on

How a CodePen Support Ticket Turned into a Great Conversation

Featured Imgs 23

A nice story from Heather Burns on how she helped us improve the accessibility and usability of Embedded Pens.

We had an ongoing email exchange with Chris for about a month. He and his talented team made changes that improved the accessibility of ALL embedded CodePens. AND without requiring the authors of the pens or the page to make changes!

The post How a CodePen Support Ticket Turned into a Great Conversation appeared first on CodePen Blog.

Posted on

Making Tables With Sticky Header and Footers Got a Bit Easier

Category Image 091

It wasn’t long ago when I looked at sticky headers and footers in HTML <table>s in the blog post A table with both a sticky header and a sticky first column. In it, I never used position: sticky on any <thead>, <tfoot>, or <tr> element, because even though Safari and Firefox could do that, Chrome could not. But it could do table cells like <th> and <td>, which was a decent-enough workaround.

Well that’s changed.

Sounds like a big effort went into totally revamping tables in the rendering engine in Chromium, bringing tables up to speed. It’s not just the stickiness that was fixed, but all sorts of things. I’ll just focus on the sticky thing since that’s what I looked at.

The headline to me is that <thead> and <tfoot> are sticky-able. That seems like it will be the most common use case here. 

table thead,
table tfoot {
  position: sticky;
}
table thead {
  inset-block-start: 0; /* "top" */
}
table tfoot {
  inset-block-end: 0; /* "bottom" */
}

That works in all three major browsers. You might want to get clever and only sticky them at certain minimum viewport heights or something, but the point is it works.

I heard several questions about table columns as well. My original article had a sticky first column (that was kind of the point). While there is a table <col> tag, it’s… weird. It doesn’t actually wrap columns, it’s more like a pointer thing to be able to style down the column if you need to. I hardly ever see it used, but it’s there. Anyway, you totally can’t position: sticky; a <col>, but you can make sticky columns. You need to select all the cells in that column and stick them to the left or right. Here’s that using logical properties…

table tr th:first-child {
  position: sticky;
  inset-inline-start: 0; /* "left" */
}

Here’s a sorta obnoxious table where the <thead>, <tfoot>, and the first and last columns are all sticky.

I’m sure you could do something tasteful with this. Like maybe:

The post Making Tables With Sticky Header and Footers Got a Bit Easier appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

target=blank

Category Image 052

Does that make your eye twitch a little bit? Like… it’s a typo. It should be target="_blank" with an underscore to start the value. As in…

<a target="_blank" href="https://codepen.io">
  Open CodePen in a New Tab
</a>

Welp, that’s correct syntax!

In the case of the no-underscore target="blank", the blank part is just a name. It could be anything. It could be target="foo" or, perhaps to foreshadow the purpose here: target="open-new-links-in-this-space".

The difference:

  • target="_blank" is a special keyword that will open links in a new tab every time.
  • target="blank" will open the first-clicked link in a new tab, but any future links that share target="blank" will open in that same newly-opened tab.

I never knew this! I credit this tweet explanation.

I created a very basic demo page to show off the functionality (code). Watch as a new tab opens when I click the first link. Then, subsequent clicks from either also open tab open that link in that new second tab.

Why?

I think use cases here are few and far between. Heck, I’m not even that big of a fan of target="_blank". But here’s one I could imagine: documentation.

Say you’ve got a web app where people actively do work. It might make sense to open links to documentation from within that app in a new tab, so they aren’t navigating away from active work. But, maybe you think they don’t need a new tab for every documentation link. You could do like…

<a target="codepen-documentation" 
  href="https://blog.codepen.io/documentation/">
  View CodePen Documentation
</a> 

<!-- elsewhere -->

<a target="codepen-documentation" 
  href="https://blog.codepen.io/documentation/">
  About Asset Hosting
</a>

The post target=blank appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

#318: Anna Lytical on What CodePen Is

Featured Imgs 23

When Anna Lytical heard Stephen and I talking about “What is CodePen?” she mentioned we did fab without her. So of course, I had to do one with her! Anna creates fun coding content all over the web, in addition to being an engineer at Google. Catch her on YouTube, Instagram, TikTok, and Twitter. For Anna, the appeal of CodePen is in the simplicity: nothing to set up, easy/free to get started, and you can get to the heart of learning quickly. Not to mention the sharing—as a teacher you can provide code as simply as sharing a URL. And of course, all the existing code to be inspired by!

Timestamps

  • 00:31 Guest introduction
  • 03:05 Taking part in building the technology around us
  • 05:20 What is drag?
  • 07:08 How to pick a platform to share content on
  • 13:03 Sponsor: Netlify
  • 14:59 Changing the bar for learning
  • 17:06 Using CodePen to teach code
  • 19:59 GitHub vs CodePen
  • 23:33 What’s your incentive to keep going with this?

Sponsor: Netlify

Did you see that Netlify bought FeaturePeek and rolled into into all Deploy Previews? They did! It’s cool! Imagine you need to make a change to a website, and need approval from a client first. You can do a Pull Request against the site and your Netlify-hosted site will give you a URL with a Deploy Preview. They’ve done that forever, and it’s incredibly useful. Now, it’s even more useful, as that client can open up a little UI widget on the Deploy Preview and give feedback. They don’t need to know anything about GitHub, yet their feedback can manifest as a GitHub Issue. And that’s just one possible integration.

The post #318: Anna Lytical on What CodePen Is appeared first on CodePen Blog.

Posted on

Should DevTools teach the CSS cascade?

Category Image 052

Stefan Judis, two days before I mouthed off about using (X, X, X, X) for talking about specificity, has a great blog post not only using that format, but advocating that browser DevTools should show us that value by selectors.

I think that the above additions could help to educate developers about CSS tremendously. The only downside I can think of is that additional information might overwhelm developers, but I would take that risk in favor of more people learning CSS properly.

I’d be for it. The crossed-off UI for the “losing” selectors is attempting to teach this, but without actually teaching it. I wouldn’t be that worried about the information being overwhelming. I think if they are considerate about the design, it can be done tastefully. DevTools is a very information-dense place anyway.

Direct Link to Article — Permalink

The post Should DevTools teach the CSS cascade? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

CSS Hell

Category Image 052

Collection of common CSS mistakes, and how to fix them

From Stefánia Péter.

Clever idea for a site! Some of them are little mind-twisters that could bite you, and some of them are honing in on best practices that may affect accessibility.

Why “CSS Hell”?

It’s a joke idea I stole from HTMHell. I hope adding some fun and sarcasm to learning might help raising awareness of how !important a good CSS code is.

Direct Link to Article — Permalink

The post CSS Hell appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Learn CSS!

Category Image 052

Ooo look at this mighty SEO flex from Google: Learn CSS! Well deserved — this is great content. Twenty-three chapters taking you through all the fundamentals of CSS with extra content, like relevant podcasts, interactive examples, and even quizzes to make sure you retained what you read.

Has CSS become… a real system? Heck yes, it has.

Who’s behind the scenes here? Look at this extraordinary pedigree, which you can see for yourself in the conclusion:

Direct Link to Article — Permalink

The post Learn CSS! appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Euismod

Category Image 052

An interactive tool for learning grid syntax from Etesam Ansari. In the Learn section, it teaches you some concepts (involving multiple bits of the grid syntax) then gives you a task to complete by filling out the right syntax. I’m sharing because I think this sort of thing really clicks with people — I know Flexbox Froggy did. Once you know the possibility, there is no shame in memorizing all the details, that’s what our guides are for: we have them for flexbox and grid. Generators can be awfully helpful too, like Sarah’s Grid Generator.

Aside: I wonder what Euismod means. Google suggests it is Latin for Performance.

Direct Link to Article — Permalink

The post Euismod appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

DevTools for CSS layouts 2021 edition

Featured Imgs 23

Chen Hui Jing covers some recent movement in DevTools:

Firefox’s grid inspector was pretty full-featured from the get-to and released together with CSS grid in Firefox 52. It was constantly improved upon since. Chrome added a basic grid inspector tool in Chrome 62 that let developers highlight elements using grid layout, but more robust features were only added in Chrome 87. And now, Webkit [sic] has joined the party, as Safari Technology Preview 123 adds Grid inspecting features as well.

You love to see it. DevTools have a massive impact on how front-end developers think about, build, and of course, debug websites. Stuff like seeing the numbered grid lines visually is a huge deal. I’ve done enough mentally counting what rows/columns I want to place things on, thank you very much.

Direct Link to Article — Permalink

The post DevTools for CSS layouts 2021 edition appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

2021 Design Systems (Survey/Courses)

Category Image 052

My friends at Sparkbox are doing a survey on design systems, as they do each year. Go ahead and fill it out if you please. Here are the results from last year. In both 2019 and 2020, the vibe was that design systems (both as an idea and as a real thing that real companies really use) are maturing. But still, it was only a quarter of folks who said their actual design system was mature. I wonder if that’ll go up this year.

In my circles, “design system” isn’t the buzzword it was a few years ago, but it doesn’t mean it’s less popular. If anything, they are more popular almost entering the territory of assumed, like responsive design is. I do feel like if you’re building a website from components, well, you’ve got a component library at least, which is how I think of design systems (as a dude who pretty much exclusively works on websites).

I’d better be careful though. I know design systems mean different things to different people. Speaking of which, I’d be remiss if I didn’t also shout out the fact that Ethan has a handful of totally free courses he’s created on design systems.

As you might have guessed from the titles, we’ve broadly organized the courses around roles: whether you’re a designer, a developer, or a product manager, we’ve got something for you. Each course focuses on what I think are the fundamentals of design systems work, so I’ve designed them to be both high-level and packed with information. 

The post 2021 Design Systems (Survey/Courses) appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

#315: Support Success

Featured Imgs 23

Over the last year, almost every metric that you want to go up has gone up at CodePen. More users creating and doing more things. You’d think that customer support would go up at the same level. And if it did, we would have thought that was very normal and dealt with it. But customer support doesn’t have to be this static thing that just is the way it is forever. If you find that people have the same questions over and over, you can fix your app or documentation such to answer that question better. If people report bugs, you can fix them. In fact, if you do a lot of those things, you can reduce customer support even as the number of customers you support grows. That’s exactly what we did at CodePen.

The result is that our customer support went from a job nearly impossible to get all done in a day, or the point where it is a part-time endeavor for whoever is on support that day. Even while our time-to-respond to tickets has also dramatically dropped. We’re just over one hour right now, and of course hope to drop below that line. The truth is though, most tickets are half that, it’s just some tickets that slip between the cracks and take days that hurt our average.

Timejumps

  • 00:23 Support levels in 2021
  • 02:52 What’s changed
  • 06:13 …while still getting new users!
  • 11:11 Sponsor: Netlify
  • 12:15 Average response time to tickets
  • 15:12 Measuring the right thing is difficult
  • 20:32 COVID isn’t the main thing
  • 28:26 Focused on support tickets

Sponsor: Headless Commerce Summit

Netlify is throwing a totally free online conference: Headless Commerce Summit.

E-commerce is growing at an unprecedented rate, making everything from your site performance to your ability to iterate faster a critical business advantage.

Take have a day and go! Even if you aren’t currently literally building a headless site, it would be good to have in your brain how other people are doing it and what they are getting out of it.

The post #315: Support Success appeared first on CodePen Blog.