DEV Community: Stacey

Container queries are live (in Chrome)!

Stacey — Thu, 08 Sep 2022 02:34:00 +0000

Update September 14, 2022: Safari 16 now also supports container queries!

Chrome 105 rolled out some pretty exciting CSS support updates including long-awaited container queries!

What are container queries?

Container queries are a new type of CSS query that, like many use cases for media queries, allows us to define styles based on a defined size. However, where @media encompasses the width of the environment—viewport or user settings like zoom—the new @container allows us to target specific elements on the page.

For a potential use case, let’s look at the related news stories section of an article on the New York Times’ website.

Here we have two columns: one wide column and one narrow column. The wider column includes a flex layout with multiple rows of three thumbnails and headlines (let’s call these headline and thumbnail sets “cards”). The narrower column includes a text-based list of links to the most popular stories. As I adjust the size of my browser window to be smaller, the two columns also change; the flex layout contained in the larger column reduces to show multiple rows of two cards instead of three.

(There’s an empty space in both of these screenshots because of my ad blocker. 🙃)

Currently, this is achieved with media queries. The individual cards are given a max-width that increases or decreases depending on the viewport’s width in pixels.

.card {
        max-width: 48%;
}

@media (min-width: 768px){
    .card {
        max-width: 32%;
    }
}

This works fine here, but what if this flex container of cards had more applications? Maybe a content author could insert our flex container into both narrow and wide columns. Currently, we only have the one media query for a min-width: 768px, but that would not be enough to make the cards look good in a significantly narrower column.

And just think if our imaginary stakeholders wanted even more options: one, three, four column layouts that have to fit our flex container. Our edge cases are going to quickly spiral out of control as we’ll have to manually test and write out every possible viewport width combination as a media query. Instead of doing that, though, we can use container queries to scope these variations to the width of the container itself.

.card-container {
    container-type: inline-block;
}

.card {
        max-width: 48%;
}

@container (min-width: 420px) {
    .card {
        max-width: 100%;
    }
}

@container (min-width: 680px) {
    .card {
        max-width: 32%;
    }
}

Note that we’re only styling the child .card selector within the container query. @container does not allow us to style the container itself. To apply responsive styles to the container element itself, we’ll need to still use @media. Technically we could use another parent container, but if we need this flex container to have a variety of applications, nesting @container queries would bring us back to the busy work of working out every possible edge case of parent component.

With the continued popularity of component-based design systems and UI component libraries like Storybook, container queries allow us to be more consistently modular and flexible in our code.

container-type

The key to getting a container query to work is adding a container-type property to the element you wish to enable as a container. This will also allow the container to show up in Chrome DevTools.

In the latest working draft, container-type can take three potential values:

normal: the initial value/assumed default. This means the element will not be treated as a queryable container.
size: establishes the element as a query container for size queries on both the inline (horizontal) and block (vertical) axis.
inline-size: establishes the element as a query container for size queries on the inline (horizontal) axis.

inline-size is the one you’ll probably see the most in early examples, and it’s the one I used in my codepen. It works the way you’re probably used to working with media queries where it is relative to the width of the container.

container-name

You may find yourself wanting to establish multiple containers on a page with different styles. In this case, you’ll want to use the container-name property. This takes any string as a value and will allow you to specify which container you’re querying:

.card-container {
    container-type: inline-block;
    container-name: card-container
}

@container card-container (min-width: 420px) {
    .card {
        max-width: 100%;
    }
}

In this example, I’ve used the class name as the container-name, but that is by no means a requirement. It can be any unique, single-word string you need. As for best practices, while it’s still early days, the current draft uses kebob case (dashes) in its examples.

Size container features beyond width

In the examples above, I wrote my container queries using a min-width and pixel value for my size feature, but we’re not limited to that format. Let’s look at this example from the working draft:

main {
  container-type: size;
  container-name: my-page-layout;
}

.my-component {
  container-type: inline-size;
  container-name: my-component-library;
}

@container my-page-layout (block-size > 12em) {
  .card { margin-block: 2em; }
}

@container my-component-library (inline-size > 30em) {
  .card { margin-inline: 2em; }
}

Recall that “inline” refers to the horizontal sizing while “block” is the vertical. In the example above, main—named my-page-layout—has the container-type of size (both block and inline) while .my-component—named my component-library—has an inline-size (just inline). Therefore, in their named container queries, @container my-page-layout (block-size > 12em) will apply with a container height larger than 12em, whereas @container my-component-library (inline-size > 30em) will apply with a width larger than 30em.

In future iterations, we may be to write size container queries in respect to aspect-ratio as well.

Limitations

As you may have guessed from multiple references to the working draft, @container is not universally supported yet. It is available in only the newest version of Chrome and Chromium-based Edge (partially), but is not yet in FireFox or Safari. Keeping an eye on CanIUse.com, we see support is slowly but surely rolling out, as it’s now in the latest Safari Technology Preview. You will probably find yourself using @media in most cases for a little while longer, but it’s exciting to see such mainstream progress on its adoption.

Posted late at night (for me) and edited with fresh eyes in the morning; cross-posted to my site.

Hiding Images with Content Warnings in React

Stacey — Wed, 15 Jun 2022 14:45:10 +0000

After attending Tori Clark and Keli Sierra Bradley’s axe-con talk on trigger and content warnings, I put making a toggle-able content warning for my blog on my to-do list.

By content warning, I’m envisioning something similar to Instagram’s current implementation. In the screenshot included below, the account belonging to horror magazine Fangoria has age-gated some of its especially gnarly images. The image is blurred beyond recognition with text overlaying it that lets users know why it is hidden. Lastly, there is a button to click to reveal the image.

In my past life in academia, I wrote a lot about horror video games, and would like to better integrate that interest into my portfolio. Given that most of my website is about my current experience as a front-end developer, including a warning before the, uh, grosser of that content sounded like a good idea.

In their talk, Clark and Bradley compared content warnings to wet floor signs: the warning benefits everyone, but some people are more likely to slip than others. I interpreted that to mean, if you have an image you think might be triggering to someone, it’s best to err on the side of caution and give users the opportunity to opt into seeing it. The worst case is that a user may have to take an extra action to see it, which, I think, is worth the payoff of potentially ruining someone’s day by not hiding it. I specifically brought up content warnings in terms of hiding horror, but it could have a lot of other, comparatively benign applications such as hiding a spoiler from a popular TV show or respecting culture-specific sensitivities.

My portfolio currently uses GatsbyJS, so React is going to be the way to go for me, and JSX makes it very easy to hide and show HTML elements inline. That said, this should be relatively easy to adapt to other frameworks like Vue or even vanilla Javascript if we break it down effectively.

The elements of our component

Just taking the instagram post as an example, we know we need at least four basic pieces for our component:

an image
alt text
toggle state management
warning copy

If we are making this a re-usable React component, we know that at a bare minimum, the image will be different each time. Therefore, we’ll pass the image url and alt text in as props. We may want to start with something like:

const ContentWarning = ({imgSrc, alt} => {
    return (<div>
        <img src={imgSrc} alt={alt} />
    </div>)
}

Continuing down our list, we know we need a way to manage state, which we can easily use in modern React with the useState hook. We’ll also go ahead and throw in our warning text.

const ContentWarning = ({imgSrc, alt} => {
    const [showContent, setShowContent] = React.useState(false);
    return (<div>
        <img src={imgSrc} alt={alt} />
        <div className="warning-text">
              This image may contain sensitive content
     </div>
    </div>)
}

So what all do we need to control with our state? We know we want to disguise the image and show our warning text when showContent is false, but we also should be careful to disguise our alt text so that a screenreader user also isn’t inadvertently exposed to something they don’t want to hear. All images must have an alt attribute in compliance with WCAG, but that attribute can be empty—no space, just empty—so we’ll add a ternary function to check for whether showContent is true. Similarly we’ll use the logical and operator to only display the content warning if showContent is false.

Fortunately, blurring the image only requires a single line of code in modern CSS! We will similarly only include that if showContent is false.

const ContentWarning = ({imgSrc, alt} => {
    const [showContent, setShowContent] = React.useState(false);
    return (<div>
        <img 
                src={imgSrc}
                style={{ filter: !showContent ? "blur(1.5rem)" : "none" }}
                alt={showContent ? alt : ""} />
        {!showContent && <div className="warning-text">
              This image may contain sensitive content
     </div>}
    </div>)
}

Finally, to manage the state of our content, we need a button for users to click to toggle the image:


const ContentWarning = ({imgSrc, alt} => {
    const [showContent, setShowContent] = React.useState(false);
    return (<div>
        <img 
                src={imgSrc}
                style={{ filter: !showContent ? "blur(1.5rem)" : "none" }}
                alt={showContent ? alt : ""} />
        {!showContent && <div className="warning-text">
              This image may contain sensitive content
     </div>}
<button
          className="toggle-button"
          type="button"
          onClick={() => setShowContent(!showContent)}
        >
          {showContent ? "Hide" : "Show"} Image
        </button>
    </div>)
}

(remember to add a type to your button, folks!)

Putting it all together

To use our component, the code would look like this:

<ContentWarning
      imgSrc="https://picsum.photos/id/1025/500/300"
      alt="an adorable pug sitting upright while wrapped in a blanket in the woods"
    />

So we put that all together and we see our image hiding and showing based on our state… all good! ….Right?

Actually, there is at least one more step. Remember how I mentioned we also wanted to render the alt text conditionally based on whether the content was hidden or not? In its current implementation, this does add the alt text back to the page when we show the image, but a screen reader user won't immediately get that new information like a sighted user will when they see the instant visual change. There are a couple ways to solve for this, and I think the simplest solution may be to just wrap our image in a live region.

const ContentWarning = ({ imgSrc, alt }) => {
    const [showContent, setShowContent] = React.useState(false);

    return (
      <div>
        <div aria-live="polite">
          <img
            style={{ filter: !showContent ? "blur(1.5rem)" : "none" }}
            src={imgSrc}
            alt={showContent ? alt : ""}
          />
          {!showContent && (
            <div className="warning-text">
              This image may contain sensitive content
            </div>
          )}
        </div>
        <button
          className="toggle-button"
          type="button"
          onClick={() => setShowContent(!showContent)}
        >
          {showContent ? "Hide" : "Show"} Image
        </button>
      </div>
    );
  };

This way, it will announce the new text after a user hits the toggle button.

Here’s a Codepen example with some small style tweaks to make it a little more presentable (don’t worry, the image is an inoffensive and very cute dog).

Potential enhancements

Global Toggles

On social media platforms like Twitter, users have the option of opting in and out of seeing “media that may contain sensitive content.” We therefore may also want to have a site-wide toggle that will hide or reveal all images on the page.

To do this: instead of just passing the image url and alt text as props, we would also pass something like globalShowContent

const ContentWarning = ({ imgSrc, alt, globalShowContent}) => {}

If we still want users to be able to toggle individual images, we would start by setting our component level state as const [showContent, setShowContent] = React.useState(globalShowContent); to respect the global setting from the jump.

Srcset instead of Src

Since we are well into 2022 at this point, you may want to pass in multiple image sources a la srcset, to do this, in addition to passing in a string with imgSrc, we could pass an array of strings containing our urls and sizes (["https://picsum.photos/id/1025/500/300 x1”, “https://picsum.photos/id/1025/1000/600 x2”]), and map it in our component.

<img src={imgSrc}
     alt={showContent ? alt : ""}
         srcSet={imgSrcSet.map(imgSrc=>imgSrc)} />

Conclusion

As Clark and Bradley called out in their talk, ensuring users can safely access your content is an accessibility issue, and content warnings are a relatively straightforward way to do that. Whether it’s gating potentially-triggering content or just hiding a spoiler, it’s worth putting basic safe guards in place to ensure your users have a smooth, pain-free experience. Hopefully this example proves to be an easy baseline for starting your component.

Edit to correct typos; cross-posted from my site

Rebasing in English

Stacey — Tue, 17 May 2022 12:46:16 +0000

A coworker recently explained rebasing in a way that made it make sense to me for the first time: it's just pretending you branched off of better code than you actually did.

The usual diagram of rebasing looks something like this:

This is clear to me when I have two branches--a main/master branch and a second branch with my new feature--but that's rarely how a repo is being used. There's usually multiple feature and bug branches being worked on simultaneously--often by different team members. When I'm asked to rebase due to changes made to main, this diagram makes it look destructive and scary. To be clear, it IS destructive in the sense that it fundamentally changes the history of your branch, but the consequences aren’t necessarily as scary as they appear.

For me at least, I found it helpful to just ignore the diagram and think of it like this:

First, I made my feature off of main. Meanwhile, someone else made a significant improvement to main--an important bug fix maybe. I could merge main into my branch and leave a paper trail, but if we're confident in these changes, why not keep my commits clean and pretend like they were always there? Rebasing essentially tells my feature branch, hey, let's just act like I was working off of this new and improved main branch all along.

Quick Tip: always include a type on your buttons

Stacey — Sun, 24 Apr 2022 16:56:05 +0000

Did you know the default type value on a button element isn’t “button?”

To step back for a moment, the button element was introduced as part of HTML 4 specification in the late 90s—it’s been with us awhile. Previously, if you wanted a submit button on a form, you would use an input with a type="submit"

<input type="submit" value="Submit the form">

Increasingly, the button does more than just submit or reset form values. It opens dialogs! Navigates slideshows! All of our favorite things!

The modern button element carries over many of the attributes of the original input spec, including a type that defines the button’s behavior.

type takes three possible values, all of which are fairly self-evident. To quote the HTML Standard spec:

submit - “submits the form”
reset - “resets the form”
button - “does nothing”

This is great for a number of reasons, especially because it makes it very clear to you or whoever has to read your code after you exactly what this button does.

The tricky part comes from when the type isn’t set. If we have a button element without a type (<button>My Sample Button</button>) or a button with an invalid type value <button type="resete">My Sample Button with mispelled "type"</button>, the state defaults to submit not button.

(except in Internet Explorer, because IE always has to do its own thing)

This is an easy step to miss, and depending on your project, might not cause any obvious issues. Or it could cause very obvious issues.

For example, let’s say you’re building a form and it calls for a dialog with more information. You may put a button trigger for that dialog. If you don’t include a type on that button, clicking that button will submit the form before the user’s ready! Here’s an extremely basic codepen example.

The lesson here, then, is always assign a value to your type. It makes your code valid, readable, and saves your users headaches.

and
: a native HTML accordion

Stacey — Fri, 15 Apr 2022 20:16:18 +0000

Did you know about <details>? If you did, great. I’m happy for you. If you--like me--did not, the code looks like this:

<details>
    <summary>More Information</summary>
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
</details>

Rendered, it would look something like this:

If you click on that “more information” text—either with a mouse or space bar on focus—you’ll see this

Clicking “More Information” will hide the expanded text again.

Essentially, anything you put in summary becomes a button-like element that, when pressed, displays any children of details that come immediately after it. You can wrap those adjacent children in a div for easy styling, but just dumping the text right next to the summary works just fine. This makes it sound a heck of a lot like the countless custom accordions you’ve no doubt had to make. A native HTML solution is almost always preferred to a custom one, and this one is supported in modern browsers, and its appearance is relatively easy to customize.

The black arrow renders as a :marker on summary in most modern browsers, which is easy to disable with list-style-type: none and replace with whatever pseudo-class content or background-image you choose. The exception, as expected, is Safari, which still uses ::-webkit-details-marker (summary::webkit-details-marker). So in order to fully disable the default marker style, you’ll need to do something like this:

summary {
    list-style-type: none;
}

summary::webkit-details-marker {
    display: none 
}

Still pretty painless!

details also comes with a handy open property that appears when the full text is expanded, allowing you to animate your custom marker. Here’s a simple, if impractical, example on codepen.

Limitations

There’s always a catch. While <details> and <summary> are a great, out-of-the-box solution for a lot of projects. There are some exceptions to consider.

No IE support

As I’m sure you can guess, this is not available in any version of Internet Explorer. If you still need to support IE11, you’ll need to come up with a custom solution.

Customized animations/transitions

One of the main reasons we end up turning to custom solutions is because of very specific UI requirements; we often want that hidden text to gracefully slide into view when expanded. Unfortunately, while you can modify the appearance of the marker fairly easily, you won’t be able to do too much with the actual text reveal transition without some extra Javascript.

Accessibility considerations

For the most part, this component is fairly accessible out of the box; you’re able to navigate it using your keyboard, with both keyboard and most assistive technology treating the summary element as a button. However, as Hassel Inclusion discovered in a test of the element in 2019, the revealed text isn’t always announced correctly by screen readers, so an unsighted user might not know what their button press actually did. A way around this may be adding extra markup and a little Javascript to make the expanded text a live region when it is expanded, or perhaps just move focus on expansion to the new text. At that point, you’re basically making a custom component, though.

this post was cross-posted from my site

VSCode snippet for IE11-only CSS and SCSS

Stacey — Thu, 31 Mar 2022 10:27:20 +0000

I’m very grateful that my current employer has chosen to put Internet Explorer 11 out to pasture, but I have not always been so lucky. Even as Microsoft prepares to end support this June, so long as a significant number of users refuse to upgrade, some devs will be forced to support it. A few years ago, I added a snippet for SCSS for projects that still needed the support, and have now adapted it for CSS to make it a little more flexible.

To use this snippet, add the following to your CSS snippets (on Mac, that’s Code -> Preferences -> User Snippets).

{
  "IE11": {
    "prefix": "IE11",
    "body": [
      " /* rule only parsed by IE11 (╯°□°)╯︵ ┻━┻*/",
      "*::-ms-backdrop, $1 {",
      "$0",
      "}"
    ],
    "description": "IE11 override styles"
  }
}

Now if you start typing “ie” in a css file, you should be prompted to choose “IE11” from your snippets, resulting in the following code:

/* rule only parsed by IE11 (╯°□°)╯︵ ┻━┻*/
*::-ms-backdrop,  {

}

When authoring, your cursor will first appear after the *::-ms-backdrop, ready to add the selector you want to style (for example, *::-ms-backdrop, .container). When that’s done, hit tab to enter the curly braces to start adding your styles.

(If you haven’t authored VS Code snippets before, the $1 and $0 in the snippet denote the tab stops for authoring. $1 is first and $0 is last. See the VSCode docs for more)

If you want to test out the override itself, I’ve set up a codepen.

Why do this?

Back when we thought IE6 was as bad as it could get, Microsoft supported conditional comments where we could print special messages (“upgrade your browser, you maniac”) or even link browser-specific stylesheets like so:

<!--[if IE 6]>
<link rel="stylesheet" href="i6sux.css">
<![endif]-->

However, these were dropped with newer versions of the browser, leaving developers to instead look for pseudo-classes that only exist in Internet Explorer. This is inherently fragile, and not every solution works for every version. In my example, *::-ms-backdrop seems to work specifically for IE11. If you need to support even older versions of IE, Stackoverflow is haunted by the ghosts of devs past, all desperate to target whatever the latest version of Internet Explorer was at the time.

It’s worth noting that usually when I see examples using *::-ms-backdrop, they are wrapped in a media query like media all and (-ms-high-contrast:none). In my experience, that hasn’t been necessary. I think it would also omit users that have high-contrast settings enabled from seeing your fixes, though I have not tested that myself.

What about SCSS?

I primarily used my snippet in SCSS files, so my actual snippet looks more like this:

{
  "IE11": {
    "prefix": "IE11",
    "body": ["   //rule only parsed by IE11 (╯°□°)╯︵ ┻━┻", "*::-ms-backdrop, & {", "$1", "}"],
    "description": "IE11 override styles"
  }
}

With this being a possible use case:

.container {
    display: grid;

     //rule only parsed by IE11 (╯°□°)╯︵ ┻━┻
    *::-ms-backdrop, & {
        display: flex;
    }
}

If you are unfamiliar with SCSS, the & represents a repeat of the parent selector, .container. This makes it a bit more modular and easier to re-use than just plain CSS. In the example above, it will use display: grid in modern browsers but display: flex in Internet Explorer 11, because grid is annoying in IE11.

Final Thoughts

If you take nothing from this post, at least take the table-throwing emoticon:

(╯°□°)╯︵ ┻━┻

this post was cross-posted from my site

axe-con 2022 takeaways: CSS

Stacey — Tue, 22 Mar 2022 23:04:31 +0000

This year’s axe-con featured two talks about new and upcoming CSS changes and their potential impacts on accessibility, Rachel Andrew‘s “New CSS with accessibility in mind” and Stephanie Eckles’ "Modern CSS Upgrades To Improve Accessibility.” Both were great and absolutely worth the watch (registering with the con for free gets you access to previous sessions). Here are a few of the key takeaways I noted from the talks.

display: contents

The contents value was discussed by Rachel Andrew in “New CSS with accessibility in mind.” Supported by modern browsers, display: contents drops the wrapping “box” from elements to allow the children to inherit the flex behavior of their grandparent.

Take the following example:

<div class="container" style="display: flex">
    <div class="nested-div">A direct child div</div>
    <ul style="display: contents">
        <li>One List Item</li>
        <li>A Second List Item</li>
    </ul>
</div>

Here we have a div with a class “container” that has two directly nested elements: another div, and an unordered list. If we give the container a display: flex and the unordered list the display: contents property and value, the list items contained therein will appear inline with the nested div as if they were immediate children of the container div.

Here’s a Codepen example if you’d like to play with it yourself.

Note that this specifically applies to the display of the children and not necessarily other properties. If I were to include a style like .container > * { margin-left: 5rem } the immediate child div would have a margin-left of 5rem, but the more deeply nested li elements would not.

From an accessibility perspective, from Andrew’s talk, I learned this was originally implemented incorrectly by browsers where the element was set to display: none and children were “put back” on the page—but they were all effectively hidden from screen readers. As of 2020, According to a blog post by Adrian Roselli, this was fixed in Chromium browsers, while Firefox and Safari still had issues when this was applied to tables. The lesson here being that whenever a fun new contents value is released, check how it is interpreted by assistive technologies to make sure the browser isn’t stripping the element’s role or removing it completely.

color-contrast()

The new bit of CSS I was most excited about from the talk was the one with the least amount of support. The functional notation color-contrast() is currently only implemented in Safari Technology Preview but has awesome potential! It compares one color with a list of other potential colors and picks the one match with the highest contrast. MDN Web Docs give the following example:

color: color-contrast(wheat vs tan, sienna, #d2691e)

Here, the color wheat is compared against a list containing two named colors and a hex value— tan, sienna and #d2691e —where it will ultimately return sienna as the color on the element.

This will be especially helpful when combined with CSS custom properties and the new prefers-color-scheme media query, also discussed in the talk. prefers-color-scheme detects the user’s OS preference for a light or dark theme, allowing you to customize your website to accommodate those preferences while still using brand colors. This means you could potentially do something like this in the near future:

:root {
  --background-color: #eeb4b3;
}

@media (prefers-color-scheme: dark) {
  :root {
    --background-color: #2f242c;
  }
}

body {
  background-color: var(--background-color);
  color: color-contrast(var(--background-color) vs #c179b9, #a42cd6, #502274);
}

(try it on Codepen)

To test this, you will need to make sure you have Experimental Features → CSS color-contrast() enabled in your Safari Technology Preview.

prefers-color-scheme and prefers-contrast vs forced-colors

Touched on above, prefers-color-scheme is a newer media query supported by most modern browsers that checks for the user’s OS preference for dark or light theme, and allows us to adjust styles based on the users preference. However, as Andrew noted in her talk, just because a user prefers a dark color scheme on their OS does not mean your dark color scheme will be the most accessible combination for the user, so it is important to give users an option to toggle between your website’s light and dark themes.

By... contrast, prefers-contrast checks for the user’s color contrast settings at the OS level. This experimental media feature introduced in Stephanie Eckles’ talk, Modern CSS Upgrades to Improve Accessibility, accepts the values less, more, or no-preference (not set in OS). In her talk, Eckles also cited custom , meaning the user set preferences in the OS, though that is not currently listed on MDN Web Docs. These primarily help to serve users with light sensitivity where less will decrease the contrast and more will increase the contrast to help users better distinguish details.

Interestingly, Eckles said that these queries can be chained (once support is more universal, of course). In this case, a user can define a style for someone with a dark color scheme who prefers high contrast like so:

@media (prefers-color-scheme: dark) and (prefers-contrast: more) {
    .container {
        background-color: "darkslategray";
        color: "white"
    }
}

On the same token, there is another new media query, forced-colors which is meant to specifically check for Windows’ users High Contrast setting. It has two potential values: none or active, where active indicates that forced colors mode is active on the user's machine.

Helpfully, Eckles explained the primary difference betweenprefers-contrast and force-colors: prefers-contrast presumes that the user still wants to see your design and colors, where force-colors requires you to use the user’s set color palette.

spacing with `min()` and `clamp()`

Moving back from the experimental to something more applicable in code today, Eckles gave some great tips for harnessing more modern CSS methods for responsive spacing.

clamp(), from Eckles’ example, is a great way to control the padding and keep it proportionate at different breakpoints/zoom levels. The example she uses is this:

padding: clamp(1rem, 5%, 1.5rem)

In this example, the padding value will be no smaller than 1rem, no larger than 1.5rem, and maintain 5% as an “ideal.” This saves us the trouble of having to define “pixel-perfect” padding tweaks at every breakpoint to ensure the boxes still look as expected in browser resize.

Similarly, for spacing between boxes, such as a series of <section> elements, she gives the following example:

section + section {
    margin-top: min(128px, 15vh)
}

Full disclosure: math functions like min() generally make my brain hurt. My rudimentary understanding is that the browser will interpret the lowest of the comma-separated expressions to use when applicable. web.dev has a great demo of how this can work on Codepen. The tricky bit is that despite most examples using 2, min() can actually take any number of arguments, though it gets much harder to parse what is happening with more arguments added.

For accessibility specifically, the main takeaway here is that as users adjust their zoom or browser window size to accommodate their needs, the CSS will preserve the desired ratio between elements. If we were to instead define margin between sections with a set pixel measurement, the space between elements would appear larger and larger as users zoom, perhaps even pushing elements out of the viewport and thus making users unaware that more content even exists.

Take more away

While these were the new tricks that arguably blew my mind the most, these are absolutely not the end all be all of either talk. I highly recommend catching the recordings if you can. As of writing, you can still register for free even though the live event has passed, and view these sessions (as well as some great sessions from 2021!)

this post was cross-posted from my site and edited to fix typos

DEV Community: Stacey

Container queries are live (in Chrome)!

What are container queries?

container-type

container-name

Size container features beyond width

Limitations

Hiding Images with Content Warnings in React

The elements of our component

Putting it all together

Potential enhancements

Global Toggles

Srcset instead of Src

Conclusion

Rebasing in English

Quick Tip: always include a type on your buttons

and : a native HTML accordion

Limitations

No IE support

Customized animations/transitions

Accessibility considerations

VSCode snippet for IE11-only CSS and SCSS

Why do this?

What about SCSS?

Final Thoughts

axe-con 2022 takeaways: CSS

display: contents

color-contrast()

prefers-color-scheme and prefers-contrast vs forced-colors

spacing with min() and clamp()

Take more away

and
: a native HTML accordion

spacing with `min()` and `clamp()`