Solving Shrinkwrap: New Experimental Technique

💥 Explore this trending post from Hacker News 📖

📂 **Category**:

💡 **What You’ll Learn**:

In this article, I present my new technique for solving a CSS problem that was deemed impossible — true shrinkwrapping of an element with auto-wrapped content. By using anchor positioning and scroll-driven animations, we can adjust our element’s outer dimensions by measuring its inner contents, demonstrating that for many cases this can already work and might unlock a future native feature.

CSS is Awesome

Since anchor positioning and scroll-driven animations appeared on my radar, I knew they would unlock things that were not possible before. These new CSS features hook into many things that were previously either impossible or available only through cumbersome JavaScript APIs. Two years ago, I wrote about one of such things — the “shrinkwrap” problem and a partial decorative workaround that used anchor positioning — in my “The Shrinkwrap Problem: Possible Future Solutions” article.

After writing that article, and experimenting more with scroll-driven animations, I knew that there could be a way to combine those and achieve shrinkwrapping not just visually, but also make it affect the layout. In the last few months, I was experimenting with my past findings and a few novel approaches, and, finally, honed them into something reusable — and already working in stable Chrome and Safari, with a graceful degradation^{Go to a sidenote} for other browsers.

It really helps that this technique is mostly decorative: when it doesn’t work well, things do not look as good, but everything still works. It is pretty similar to features like text-wrap: balance, where it can be used to improve some existing designs or make new ideas possible, while not compromising on the functionality. Jump to this sidenote’s context.

That said, even though my examples for the base technique might work in the latest versions of some stable browsers, the technique itself is highly experimental.

For example, I experienced occasional crashes in Safari. I managed to find a workaround, but I strongly suggest being careful before using anything from this article in production.

Let’s say we have a simple header, which we style to look like a nice rounded box, and that should shrink to its max-content:

I am a Short Header!

When it is short, all is good! But we anticipate that it might wrap when the content is longer, and add text-wrap: balance to make it prettier. But then, this happens:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

On most viewports, you could see how when the header wraps, we get all this extra space on one side — the shrinkwrap problem. What exactly is happening, and why is it so challenging to make it work?

I’ll quote my first article about shrinkwrap:

When different content wraps — be it text, floats, inline-blocks, flex, or grid, — if that wrapping is automatic (without hard breaks), the way CSS calculates the final width is limited. The element with wrapped items gets expanded to fill all the available space.

In CSS2 specs, this behavior is called “shrink-to-fit”:

shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width)

This is a problem people have stumbled over and over from the beginning of time.

Under a cut — a long (not comprehensive) list with many links!

In 2015, Elika J. Etemad wrote about it to the www-style mailing list: “True Shrinkwrapping”. She even already mentioned text-wrap: balance in the code example!
In 2016, yisibl opened an issue #191 on CSSWG’s GitHub, “How to shrink to fit the width?”, showing a use case for wrapping of items inside a flexbox layout. Most of the following cases are from this issue.
In 2017, Vasilis van Gemert questioned if this can be fixed in his blog post “How do I fix this CSS alignment issue?”, about a left-aligned block that, when wrapped, should be aligned as a whole to the right.
In 2018, Nadya678 opened a duplicate issue about this.
Also in 2018, Benoît Rouleau provided another use case in the issue #191. The CodePen in question is no longer accessible, but from the description, it sounds like the underlined headers use case from my previous article about shrinkwrap.
In 2019, Dan Tonon also provided his use case in the same issue. This is probably the hardest to solve use case — a menu.
In 2020, Dan stumbled upon this again and opened a duplicate issue with the same case.
Starting from 2023, we saw a resurgence of reports about this issue thanks to the work on text-wrap: balance which highlighted this issue. Many people did write about it then:
In 2024 this continued:
2025!

And this is just mostly mentions from the #191 issue — there are also many StackOverflow issues and likely other places where authors wrote about this.

This article will show how we could solve almost all of these cases.

The bulk of all use cases are “simple”: we have a pre-defined space in which we have our element that could wrap, with the wrapped state often being the default one. There, we never want to use max-content for the element’s width, and these elements generally do not depend on the surrounding context but want just their box to be flush with text or the surrounding context to depend on our wrapped box.

These cases are solved either by the base technique, or by a more advanced version of it where we have to measure multiple items.

The hardest cases are those like the menu items, where every item might wrap, and by default, they want to be sized as max-content. I admit that my technique is not a good fit for these cases, but I will attempt to solve that as well, although through an extension of the base technique that uses content duplication.

The Base Techniqueanchor

Here is how I will present the technique:

I will list the limitations and corresponding prerequisites for using this basic technique.
The full code for the abstracted technique is placed under a cut — if you are eager to try to understand what is going on inside without my lengthier explanations, feel free to read it! Although I placed many comments inside, which helps.
Not all of that code is needed for the simplest of cases: first, I will iteratively explain how we solve the common case of an element with text-align: left.
Then, I will complete the technique by handling the non-left text alignment.
Finally, I will show how to use the technique as a building block for handling more complex cases with multiple nested phrasing contents.

Limitations & Requirementsanchor

The prerequisites for being able to use this technique are:

Generally, we’d want to have some container-type: inline-size around our element, as its default max-inline-size will use 100cqi, and most use cases will want to use cqi in one way or another.
The element’s max-inline-size should not depend^{Go to a sidenote} on its siblings. For the technique to work, we will need to set it to a value in px, which could depend on its container through the container query length units. But we can’t have our element respond to flex-shrink or flex-grow: when placed in a flex or grid context, its width will be more or less static.
Our element must have only phrasing content, or, in other words, should contain only inline elements inside. Replaced elements like are allowed inside, alongside anything with inline-block, inline-flex, and other inline-s, like the future inline grid-lanes.

Full Codeanchor

If you’re curious, you can peek at the full code of the technique. It is thoroughly commented and might cover some of the things I did not cover in this article. That said, I tried to expand on many things in later sections, so keep reading if you want to get the most of that info in a more readable form!

The full code of the technique.

/*
  The shrinkwrap technique.
  https://kizu.dev/shrinkwrap-solution/
*/
.shrinkwrap 🔥

.shrinkwrap-content {
  /* Must be specifically `block`, nothing else. */
  display: block;

  /* Required for establishing the view timeline. */
  overflow: hidden;

  /*
    Required for getting non-anchored positioning
    dimensions.
  */
  position: relative;

  /*
    Crucial part: the content element should always
    be max-sized and independent of anything else,
    unless the technique is disabled.
  */
  inline-size: var(--sw-enabled--on, var(--_sw-max-size));

  /* Makes shrinking not be hidden by the overflow. */
  min-inline-size: min-content;

  /*
    The following styles should only apply for the
    browsers that support `timeline-scope`, which is
    currently the furthest from being implemented in
    Firefox on 2026-01-26.
  */
  @supports (timeline-scope: --f) 🔥
}

.shrinkwrap-source {
  anchor-name: var(--sw-source, --_sw-source);

  /*
    Must be specifically `inline` by default.
    Allows anchor positioning to measure it’s size
    and its offset.
  */
  @layer defaults {
    display: inline;
  }
}

/*
  Creating the “probing” element that will be used to
  measure the source element’s dimensions and offset.
*/
@supports (timeline-scope: --f) {
  /*
    We cannot use `::before` here due to a WebKit bug:
    https://bugs.webkit.org/show_bug.cgi?id=302703
  */
  .shrinkwrap-probe {
    position: absolute;
    /* Could also be `visibility: hidden` in production. */
    pointer-events: none;

    /* Anchoring to the source element. */
    position-anchor: var(--sw-source, --_sw-source);

    /* Not strictly required, but better to be explicit. */
    inset-block: 0;
    /* Key part for calculating the text-align offset. */
    inset-inline: var(--sw-inset, anchor(inside, 0px));
    /* Accounting for the inner spacing if needed. */
    margin: calc(-1 * var(--sw-inner-padding, 0px));

    /* Exposes the element to the scope on an ancestor. */
    view-timeline: --_sw-x inline;
  }
}

/*
  Custom properties that will be applied via scroll-driven
  animations, with the value from 0 to 1.
*/
@property --_sw-x-end {
  syntax: "";
  initial-value: 0;
  inherits: true;
}
@property --_sw-x-start {
  syntax: "";
  initial-value: 0;
  inherits: true;
}

/* The keyframes that deliver their values. */
@keyframes --_sw-x-end {
  0%   { --_sw-x-end: 0 }
  100% { --_sw-x-end: 1 }
}
@keyframes --_sw-x-start {
  0%   { --_sw-x-start: 0 }
  100% { --_sw-x-start: 1 }
}

Simple Caseanchor

Let’s look at the case from “The Problem” section again:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

And now, let’s apply our base technique to it:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

It works! But how did we achieve this?

Here is the HTML^{Go to a sidenote} needed for the technique. Instead of just one element, we need to have a pretty specific^{Go to a sidenote} nested structure:

shrinkwrap is our topmost wrapper element — one that will receive the final dimensions.
shrinkwrap-content is the inner wrapper that usually will be wider than its parent and will determine how the text content inside will wrap.
shrinkwrap-source is the additional wrapper around our inline content, which we will target with anchor positioning.
shrinkwrap-probe is our anchored element that will measure the shrinkwrap-source and which will communicate its dimensions to the shrinkwrap via scroll-driven animations.

The core idea is relatively simple. To steal^{Go to a sidenote} a Doctor Who metaphor from Amelia Bellamy-Royds:

We want a box that is bigger on the inside than out.

That’s precisely what we’re doing with our technique.

If you read my previous article on this topic, you might wonder, wouldn’t that previous technique that involved just anchor positioning be enough?

The problem with that older technique was that it would only position the anchored element around our inline element — and this would not impact the actual element’s dimensions or position in any way, making the setup pretty awkward.

For example, we would not be able to make the text inside this header be still left-aligned while centering the header itself:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

The new technique gave the parent shrinkwrap element the correct dimensions, making it possible to continue using CSS as usual, without trying to “fake” its visuals through an external anchored element.

I will omit explaining some styles and will trim various calculations — you can find them in the full code, but in these sections I want to give the general overview of the code involved in the technique.

Styles for the Top Wrapperanchor

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

Our top shrinkwrap wrapper has a few important parts^{Go to a sidenote} in its CSS:

.shrinkwrap {
  /* 1. Setting up overrideable custom properties. */
  @layer defaults {/*…*/}

  /* 2. Base styles: some other values are allowed. */
  display:  block;
  overflow: hidden;

  /* 3. Scroll-driven animations for remote measuring. */
  timeline-scope:     /* One timeline   */;
  animation:          /* Two animations */;
  animation-range:    /* Two ranges     */;
  animation-timeline: /* One timeline   */;

  /* 4. Applying the measured dimensions to the element. */
  inline-size:     /* Cyclic-toggled value. */;
  min-inline-size: max(/*…*/);

  /* 5. Some important resets. */
  box-sizing: content-box !important;
  flex-grow:  0 !important;
  flex-shrink:     /* Cyclic-toggled value */;
  max-inline-size: /* Cyclic-toggled value */;
}

We use layers and custom properties for defining the CSS API of our technique.
Our topmost element should have a normal flow: block or inline-block will work, as well as it being inside a flex or grid context, but the element itself can’t establish a grid or flex.
The key part: we use scroll-driven animations to retrieve the dimensions of our inner element. I will expand on this a bit more in a later “Remote Dimensions Measuring” section.
Second key part: applying^{Go to a sidenote} the measured dimensions to our element. The inline-size and min-inline-size will be calculated based on variables that will be applied via scroll-driven animations.
I also included a few properties that we should never really change for our parent element, as we are sizing it in a very specific way. This part might be adjusted: we could add more properties there or find use cases in which these properties could play a role and require overriding.

Styles for the Content Wrapperanchor

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

The shrinkwrap-content is that “inner box” that might be bigger than the actual shrinkwrap element^{Go to a sidenote}.

.shrinkwrap-content {
  /* 1. Base styles. */
  display:  block;
  overflow: hidden;

  /* 2. Inner box’ dimensions. */
  inline-size:     /*…*/;
  min-inline-size: min-content;
}

The styles for the inner box are (for now) simple:

We need to have some base styles — again, we need to make sure we use a normal flow, and specifically overflow: hidden, as scroll-driven animations will rely on its presence on this element.
We have to set the dimensions of our element in a pretty specific way. It will reuse several “private” custom properties that we set on the wrapper and which are based on the custom properties defined by our technique’s API. The inline-size here is the most important part: the way we size it (by default with 100cqi) makes it so it is independent of the shrinkwrap’s dimensions.

Styles for the Sourceanchor

The shrinkwrap-source is^{Go to a sidenote} one of the more simple elements:

.shrinkwrap-source {
  anchor-name: var(/*…*/);

  @layer defaults {
    display: inline;
  }
}

This element will provide the anchor-name used for our technique, which might be reassigned via the custom properties API.

Then, we need it to be inline by default, as this is what we rely on when measuring our element. However, there are use cases where we are not measuring inline elements, so we apply this style weakly and allow overriding externally.

Styles for the Probeanchor

Finally, we have our shrinkwrap-probe element:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

@supports (timeline-scope: --f) {
  .shrinkwrap-probe {
    /* 1. Base styles. */
    position:       absolute;
    pointer-events: none;

    /* 2. Anchoring to the Source. */
    position-anchor: var(/*…*/);
    inset-block:     0;
    inset-inline:    calc(/*…*/);
    margin:          calc(/*…*/);

    /* Establishing the view timeline. */
    view-timeline: /*…*/;
  }
}

This is our absolutely positioned^{Go to a sidenote} element that will measure the source element. We should remove the pointer-events from it, as it should not interfere with our page in any way. An alternative could be to use visibility: hidden, but I find it is much easier to keep it “visible” with just pointer-events for easier debugging.
We then anchor this element to the shrinkwrap-source. Later techniques might override some of these, but by default we only care about the inset-inline and use anchor positioning for defining it. Additionally, we’re using a margin to optionally adjust the measured rectangle.
Finally, we need to establish an inline view timeline, which will mean we could access it on the shrinkwrap element via timeline-scope and its animation properties.

I also tried using position: fixed here, but it was not as stable as absolute, especially in Safari and Firefox. While fixed anchor positioning can be pretty useful, it is better to keep things absolute whenever possible and rely solely on fixed if nothing else helps.
See my “Anchoring to a Containing Block” blog post for a few more details. Jump to this sidenote’s context.

Note that we can also wrap this whole element with an @supports — no reason to do anything with it unless timeline-scope is supported.

Non-Left Text Alignmentanchor

The above styles would be enough for cases when we have just a left-aligned text, as our shrinkwrap-source’s left boundary will be the same, and that would be enough to just shrink the shrinkwrap element.

However, if we were to override the text-align on our element, the following could happen:

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

Because our inner box is bigger than the outer, and the text is aligned inside that box, it is not enough to shrink the outer one — we need to also detect^{Go to a sidenote} that offset between the shrinkwrap-content and shrinkwrap-source.

Alternatively, if we knew the alignment in advance, we could’ve changed the justify-self on the shrinkwrap-content, but I decided to go with an automatic adjustment. Jump to this sidenote’s context.

Thankfully, with the way we’re measuring our element, we can reuse the variables that our scroll-driven animation applies and adjust the position of our shrinkwrap-content:

/* Added to the other styles */
.shrinkwrap-content {
  position: relative;

  @supports (timeline-scope: --f) {
    inset-inline-start: min(/*…*/);
  }
}

We make^{Go to a sidenote} our element position: relative, and then use inset-inline-start to adjust its position.

I placed the position: relative to be always there regardless of the timeline support, as this property can have an impact on the element’s contents, and we would not want to lose it for the fallback case. Jump to this sidenote’s context.

I am a Longer Header; I Will Wrap & Look Bad! Oh no! What Can We Do?

I imagine there could be other text edge cases that the base technique does not cover — if you’ll think of anything, please let me know!

Multiple Nested Phrasing Contentsanchor

While the base technique is limited to only shrinkwrapping elements with phrasing content, more complicated cases could be covered by reusing the technique multiple times for every instance of such content inside.

For example, we could have a list with several items, and then we’d want to put it into a card with its edges flush with the content of all items inside. For this, we can make our list the container and then wrap the contents of each list item with the technique and then size the card with max-content — and it will just work! And if some list items have multiple paragraphs, we use the technique once per paragraph.

This example shows how we can have a list take up to 50% of content while shrinking to fit the wrapped items that have text-wrap: balance, which usually results in a worse visual experience.

Some non-wrapping item.
Another item, this time with more content, wrapping onto a few more lines.

In short, we can use our base technique as a building block for anything that is more complex. The later sections expand on this base technique but adjust how we measure things and what exactly we are measuring.

Base Technique’s APIanchor

The HTML of the technique is a part of its API:

The shrinkwrap and the shrinkwrap-content can be anything apart from the div, but they can only have the display: block (which is applied by the technique but should not be overridden).
The shrinkwrap-source defines what we will be measuring, and by default has display: inline. It is possible to apply it to some other element or skip this element completely if we’re overriding what we’re targeting with the shrinkwrap-probe.
The shrinkwrap-probe is our measuring element, it must be strictly inside the shrinkwrap-content, and by default is measuring the shrinkwrap-source. We can override what the shrinkwrap-probe is measuring by overriding its inset.

Alongside HTML, we can define a set of CSS custom properties on the shrinkwrap element:

--sw-limit — the key custom property that has the default of 100cqi. We can use it when we want to place some other elements alongside ours on the same “row”. The above “Multiple Nested Phrasing Contents” use one such case, where we set it to, essentially, 50cqi - 3 * var(--gap) - var(--list-item-padding) — defining the max^{Go to a sidenote} limit that the text inside could take to be a half of the container, minus all the paddings and gaps that the surrounding layout has.
--sw-padding can be used when we have a uniform padding around the element that we’re sizing. We are in a something similar to the box-sizing: content-box context when we’re using this technique, so we can use this custom property to communicate the possible adjustment. It is similar to using a calc() inside a --sw-limit, and often is a more simple way of handling the paddings, but more complex cases might be better solved with the calculated --sw-limit.
--sw-inner-padding is a bit different, and might be mostly used for more complex cases that involve --sw-inset or --sw-source overrides. This is a custom property to account for any padding that could be present between the shrinkwrap and the measured content inside the shrinkwrap-content.
--sw-inset can be used to override the value of the shrinkwrap-probe’s inset, making it possible to anchor it to multiple elements for more complex cases like the “Multiple Explicit Anchors”. This is where the --sw-inner-padding can also be useful, as it will be automatically used for calculations that can be trickier to achieve with the inset shorthand. **Note: ** this custom property is used specifically for inset-inline property, and not inset.
--sw-source is for those rare cases where you’d want to override the anchor-name of the shrinkwrap-probe element. This can be useful for any complex techniques where the measured element lives outside the shrinkwrap element, allowing us to “link” them. See my “Inline Custom Identifiers” blog post that covers this way of connecting elements.

Initially, I wanted to also introduce a custom property for the “minimum limit”, but ended up simplifying the api. If necessary, it is always possible to do a max(min-limit, limit) for the same effect. Jump to this sidenote’s context.

Remote Dimension Measuringanchor

I am using a technique, the basics of which I came up with somewhere in 2023, after publishing my second article about scroll-driven animations. I did not write about this technique anywhere yet, but had a few drafts with various use cases for it that I sometimes worked on in background.

Thankfully, someone else came up with a similar technique and wrote about it — it was Temani Afif and his “How to Get the Width/Height of Any Element in Only CSS” article from July 2024.

There is one difference between our techniques: Temani relies on the “measuring” element when it is at the beginning of the box, and then using its 1px dimension and its proportions relative to the scrollport to calculate that scrollport’s dimensions.

Because I am using anchor positioning to place my probing element at a very specific point — which I want to measure — I, instead, rely on a very high value of the timeline-range, which I store in the --resolution custom property.

When some view timeline then reports its position in this range, by knowing this “resolution” we can then retrieve that position through scoping the timeline to another element.

Here is the CSS^{Go to a sidenote} responsible for the scroll-driven animations that I previously skimmed through:

.shrinkwrap {
  /* Lifting the scope of view timelines from inside. */
  timeline-scope: --_sw-x;

  /*
    Accessing the start and end coordinates of the
    inner element via scroll-driven animations.
    Only apply when the technique is enabled.
  */
  animation: var(--sw-enabled--on,
    --_sw-x-start linear both,
    --_sw-x-end   linear both
  );

  /*
    We will be using the “resolution” as a range to
    retrieve the width of various things.
  */
  --_sw-resolution: 10000px;
  animation-range:
    0               var(--_sw-resolution),
    contain contain var(--_sw-resolution);
  animation-timeline: --_sw-x;

  /*
    Calculating the actual size from the variables applied
    via the animation with the given resolution.
  */
  --_sw-size:
    (var(--_sw-x-start) - var(--_sw-x-end))
    *
    var(--_sw-resolution)
  ;
  /*
    For the main size, clamp the result within limits,
    and guard everything with a space toggle.
  */
  inline-size: var(--sw-enabled--on,
    clamp(
      0px,
      var(--_sw-size),
      var(--_sw-max-size)
    )
  );
  /* Min-size should not be clamped. */
  min-inline-size: max(
    0px,
    var(--_sw-size)
  );
}

.shrinkwrap-content {
  @supports (timeline-scope: --f) {
    /* Guard by the cyclic toggle. */
    inset-inline-start: var(--sw-enabled--on,
      min(
        0px,
        var(--_sw-x-start) * var(--_sw-resolution)
        -
        var(--_sw-max-size)
      )
    );
  }
}

@supports (timeline-scope: --f) {
  .shrinkwrap-probe {
    /* Exposes the element to the scope on an ancestor. */
    view-timeline: --_sw-x inline;
  }
}

/*
  Custom properties that will be applied via scroll-driven
  animations, with the value from 0 to 1.
*/
@property --_sw-x-end {
  syntax: "";
  initial-value: 0;
  inherits: true;
}
@property --_sw-x-start {
  syntax: "";
  initial-value: 0;
  inherits: true;
}

/* The keyframes that deliver their values. */
@keyframes --_sw-x-end {
  0%   { --_sw-x-end: 0 }
  100% { --_sw-x-end: 1 }
}
@keyframes --_sw-x-start {
  0%   { --_sw-x-start: 0 }
  100% { --_sw-x-start: 1 }
}

I am planning to write a separate article that will explain how this dimension measuring works in detail, and I would rather not repeat myself in this one (and make it even longer).

So — stay tuned for that next article!

A Crashing Safari Buganchor

As mentioned in the disclaimer, this technique is very experimental, and the CSS features it relies on are pretty new, and can sometimes cause issues even though they’re there in the “stable” versions of major browsers.

Initially, I was creating the probing elements as pseudo-elements, but while testing my article, I found that in certain conditions my article was crashing its tab in Safari.

After reducing the code to its minimal reproduction^{Go to a sidenote}, I found that the probing element being a pseudo-element was one of the conditions for the crash to happen, so I adjusted the technique by replacing it with a real element.

Initially, my technique also had another pseudo-element that did not trigger the issue, but I managed to simplify my technique to allow doing both measurements from the single additional element.

Solving for Complex Contentanchor

The base technique works for the simple case where our source element has phrasing content: only inline (and inline-…) elements inside.

But what about more complex cases, like when we have multiple items inside wrapping flexbox, grids, etc?

The simpler cases which we could separate into several independent phrasing contexts can be solved by repeating the base technique — see “Multiple Nested Phrasing Contents”, but not everything can be done this way.

Multiple Explicit Anchorsanchor

I covered this use case and a few of my approaches to a solution in my previous article, in a “Wrapping Flex Items” section, but the new technique improves on those.

In short, if we have a wrapping list of items, either inside a grid or a flex container, if we know the number of items, then we can assign a unique anchor to every item and then use a min() function involving all the anchors to find the “furthest” element that could be used to determine our shrinkwrapped dimension.

An item
Second item
Third item
Fourth item
Fifth item
Sixth item
Sixth item

Because I abstracted the measuring into a separate element, implementing this is as easy as doing the following^{Go to a sidenote} (after stripping visual styles unrelated to the technique):

We have to fall back to calc(infinity * 1px), as otherwise things could break if one or more items won’t be in the DOM.

Adding infinity inside a min() will gracefully remove this item from being considered for the calculation completely. Jump to this sidenote’s context.

li {
  padding:     var(--padding);
  anchor-name: var(--is);
}

.shrinkwrap {
  --sw-inner-padding: var(--padding);
  --sw-inset:
    min(
      anchor(--a inside, calc(infinity * 1px)),
      anchor(--b inside, calc(infinity * 1px)),
      anchor(--c inside, calc(infinity * 1px)),
      anchor(--d inside, calc(infinity * 1px)),
      anchor(--e inside, calc(infinity * 1px)),
      anchor(--f inside, calc(infinity * 1px)),
      anchor(--g inside, calc(infinity * 1px))
    )
  ;
}

And the HTML is pretty simple: we wrap our list with our shrinkwrap technique:

Because what we’re measuring is not inline, we are not using the shrinkwrap-source class that would assign the target that we measure; that’s where the --sw-inset custom property comes into play: we can use it to reassign how the shrinkwrap-probe will be positioned by overriding its inset property, and thus what exactly it will measure.

The only thing that we need to do here is use the min() function and pass all items’ anchors inside, making it possible to compare the inset positions of all the items and choose those that make the biggest bounding box.

In addition to this, we can use the --sw-inline-padding to accommodate the padding around items, which, in this case, is much easier to do than adding a calculation to the min().

Chained Anchors Abominationanchor

Of course, the above code relies on knowing the number of elements, assigning the unique anchor identifiers to them, and then listing all of them inside a min(). But what if I tell you that we could achieve this without doing so?

Well, we can, but, for now, this works only in Chrome — this relies on the ability to chain multiple anchors together, and that currently only works reliably in Chrome, while Safari and Firefox have pretty serious bugs^{Go to a sidenote} with that behavior.

This time, HTML is a bit more simple in one way (no unique idents), but more complex in another (additional probe elements, two per item):

{💬|⚡|🔥} **What’s your take?**
Share your thoughts in the comments below!

#️⃣ **#Solving #Shrinkwrap #Experimental #Technique**

🕒 **Posted on**: 1770396090

🌟 **Want more?** Click here for more info! 🌟

Solving Shrinkwrap: New Experimental Technique

By

Leave a Reply Cancel reply