DEV Community: Leo

Safari 27.1 previews CSS for foldable screens

Leo — Sun, 25 Oct 2026 16:07:45 +0000

I don't have a foldable phone on my desk, so this one started with WebKit's code samples pasted into a scratch stylesheet. The news: Safari 27.1 ships alongside the iPhone Duo, running what WebKit calls "the same WebKit engine and the same web technologies as every other iPhone." It also includes a preview of two APIs for foldable layouts, the Device Posture API and the Viewport Segments API. Both sit behind feature flags. WebKit's post doesn't mention other browsers, a spec stage or Baseline status, so treat this as a developer preview and nothing more.

Two new questions your CSS can ask

The iPhone Duo has an outer display for when it's closed and a larger inner display for when it's open. Both rotate between portrait and landscape. Per WebKit, that puts viewport widths anywhere from 382 to 951 CSS pixels and heights from 368 to 902.

Width and height can't tell you there's a fold running through the screen. The two previews can.

The Device Posture API tells you how the device is being held. It reports one of two values. folded means the device is partially folded, in a book or laptop pose. continuous means the screen is flat, which per WebKit covers both fully open and fully closed.

The Viewport Segments API tells you how the viewport is split. It adds the horizontal-viewport-segments and vertical-viewport-segments media queries, plus six environment variables: viewport-segment-width, viewport-segment-height, viewport-segment-top, viewport-segment-right, viewport-segment-bottom and viewport-segment-left.

Wiring up a two-pane layout

The smallest useful rule comes straight from WebKit's post. Go to two columns when the device is folded:

@media (device-posture: folded) {
  .layout {
    display: grid;
    grid-template-columns: 1fr 1fr;
  }
}

That works, but 1fr 1fr is a guess about where the fold sits. The segment variables let the grid match the physical halves. Each env() call takes a column index and a row index, counted from 0 at the top left. With two segments side by side, the left one is 0 0 and the right one is 1 0. Stacked, the top is 0 0 and the bottom is 0 1.

horizontal-viewport-segments: 2 matches the book pose, with two segments side by side. vertical-viewport-segments: 2 matches the laptop pose, with two stacked. Here's WebKit's book-pose grid:

@media (horizontal-viewport-segments: 2) {
  .wrapper {
    display: grid;
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

On the script side, navigator.devicePosture.type gives you the current posture and fires a change event. window.viewport.segments is an array of DOMRect objects. WebKit's sample logs each segment's size and runs again on both posture changes and resize:

function reportSegments() {
  window.viewport.segments.forEach((segment, i) => {
    console.log(`Segment ${i}: ${segment.width}px × ${segment.height}px`);
  });
}

reportSegments();
navigator.devicePosture.addEventListener("change", reportSegments);
window.addEventListener("resize", reportSegments);

The rough edges

The flags come first. To try any of this, open Settings > Apps > Safari > Advanced > Feature Flags and turn both APIs on. Your visitors won't have done that. WebKit also says, with both APIs behind flags, "there may still be time to evolve how they work." I wouldn't build a layout that depends on these exact names yet.

Second, don't sniff for the device. WebKit puts it bluntly: "Avoid UA sniffing to detect devices, and use feature detection instead." The post points to the usual responsive toolkit of media queries, Grid and Flexbox. The rules above already behave that way. Where the query doesn't match, the page keeps its normal layout.

Third, continuous covers both the open inner display and the closed outer one. Posture alone won't tell those two apart. Your existing width-based queries still have to handle that.

Support today

Safari 27.1 on the iPhone Duo, behind flags. That's the full list as far as WebKit's post goes. It names no other engine, no standards status and no Baseline status. If you don't have the hardware, WebKit says Xcode 27.1 or later includes Device Hub, where you can create an iPhone Duo simulator. One detail outside CSS: when the device is partially folded like a book, Safari 27.1 shows PDFs as two pages side by side.

What I'm watching next

Whether the names hold. WebKit has said these APIs can still change while they're flagged. In the next Safari release notes, the first thing I'll check is whether device-posture and the viewport-segment-* variables come out from behind the flag unchanged. Until then, your plain responsive layout is the one that ships.

Grid Lanes masonry settles on Grid syntax, and flow-tolerance is now fit-tolerance

Leo — Sat, 24 Oct 2026 16:07:14 +0000

If you wrote flow-tolerance somewhere in a Grid Lanes prototype, rename it. Saleh Mubashar's walkthrough on Piccalilli, published 22 October, says the property is now fit-tolerance. The layout mode itself is display: grid-lanes, and according to the article it works in Safari 26.4 and later, while "support in other browsers is still evolving."

The smallest version is three declarations, and they're all ones you already know from Grid:

.masonry {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

That reuse is deliberate, and it took a while to get here. Rachel Andrew opened a CSSWG issue asking for a native Pinterest-style layout in 2017. Two competing shapes followed: grid-template-rows: masonry on a regular grid (Mozilla's idea, later picked up by WebKit) and a separate display: masonry mode from Chromium. In January 2025 the CSS Working Group agreed to reuse Grid's track-definition syntax, and the article says the name display: grid-lanes was settled in December 2025. Spanning works the Grid way too: grid-column: span 2 on an item.

The knob that got renamed

The browser places each item in a lane, usually the shortest one. fit-tolerance decides what counts as "shortest" when lanes are close in height. Per the source, 0 favours the tightest packing. A larger value lets the browser treat near-equal lanes as equal, so items stay closer to source order, and infinite takes that all the way. The default is normal, which resolves to 1em.

.masonry {
  fit-tolerance: 0;
}

That's the one thing I'd try today. Open a card grid in Safari, flip between 0 and infinite, and watch where the cards land. The article also notes that source order stays intact even when items move around visually, so it's worth checking keyboard order on your own content.

The caveat is the support line. One engine ships it, so for now this is progressive enhancement: browsers that don't recognise grid-lanes ignore that declaration, which means your fallback layout has to come from a declaration they do understand. What I'm watching next is whether the other engines ship it under the settled name, and how subgrid cards inside a Grid Lanes container behave in practice. The article says subgrid can work alongside it, since masonry now lives inside the Grid model.

Vercel wants static credentials gone. Its own GitHub Actions deploy still needs one

Leo — Sat, 24 Oct 2026 10:23:51 +0000

Count the long-lived tokens your deploy job can read right now. One is plenty, and a recent npm worm that scraped tokens straight out of CI pipelines made that point the expensive way. Vercel has now told its Marketplace vendors to get rid of theirs: they have until January 2027 to drop long-lived API keys or risk being delisted. Then developers opened Vercel's own GitHub Actions deployment guide.

The policy, and the stick behind it

Vercel CTO Malte Ubl says the company surveyed more than 1,000 SaaS vendors and found that only 8.4% supported what Vercel considers secure authentication methods. Vercel's proposed replacement is OpenID Connect (OIDC) plus short-lived, identity-based tokens, instead of API keys that can stay valid indefinitely. CEO Guillermo Rauch put it on X as "time to kill 'static credentials'", arguing that stolen credentials should behave more like "self-destructing keys" that expire before an attacker gets much use out of them.

There is a nearer deadline too. By November 30, Marketplace integrations that fall short of Vercel's authentication requirements get a "Not secure" warning on their listing.

Good policy, honestly. A platform using its distribution to force vendors off static keys will move more of them than a hundred conference talks. (Delisting tends to get a product manager's attention faster than a threat model does.)

Meanwhile, in the deploy guide

Vercel's GitHub Actions deployment guide still tells you to authenticate deployments with a VERCEL_TOKEN secret. Yordis Prieto, a senior software engineer at Fanatics, replied to the announcement that Vercel had "invented" OIDC federation yet still left him leaning on "a long-lived access token" in his CI pipeline. He also took aim at Vercel's non-expiring token option.

Vercel's answer is in Ubl's announcement: the company is extending OIDC support across its API and CLI to retire long-lived tokens from deployment workflows. It also added GitHub OIDC authentication for its Container Registry in late September. Neither change removes VERCEL_TOKEN from the documented GitHub Actions deploy flow today.

Hypocrisy? That's a cheap shot. Retrofitting OIDC into an existing API and CLI is the exact job Vercel is handing its vendors, and it isn't a weekend of work. Still, you don't get to sell the cure while your own install docs keep handing out the disease.

What federation does that a secret can't

If you haven't wired OIDC into a deploy job before, the general mechanism looks like this:

The CI job asks its platform's OIDC provider for a signed token. In GitHub Actions that requires permissions: id-token: write on the job.
The token carries claims about where the job runs: repository, ref, workflow, environment.
The target service checks the signature against the issuer's public keys, checks the audience, and matches the claims against a trust policy you wrote.
If everything matches, the service issues its own short-lived credential. It expires on its own, and nothing sits in your repository settings waiting to leak.

So the trust boundary moves. The question used to be "who can read this secret?" and becomes "who can get a workflow to run that matches this policy?" That's a better question, but it doesn't answer itself. Write a subject match loose enough to accept any branch or any repo in the org, and anyone who can push a workflow file can mint deploy credentials. Same blast radius, fresher paperwork. Pin the trust policy to one repository and one protected branch or environment. (We covered a similar fine-print problem when npm trusted publishing gained dist-tag support.)

Living with VERCEL_TOKEN until the CLI catches up

You can't federate a deploy that only takes a token. You can make the token less attractive to steal:

Give it an expiry. Skip the non-expiring option Prieto complained about.
Put it in a GitHub environment with protection rules, and reference that environment only from the deploy job.
Keep it out of any job that runs on pull requests from forks.
Rotate it on a schedule, and immediately after anything that smells like a leak.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # VERCEL_TOKEN lives here, behind required reviewers
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<full-40-char-sha>
      - run: npx vercel deploy --prod --token="$VERCEL_TOKEN"
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

The fine print nobody published

Vercel hasn't published the survey methodology, named the companies it surveyed, or said how many existing Marketplace partners will have to change their authentication. Keep that in mind before you quote 8.4% at your vendor-review meeting.

Then there's Vercel Connect, which lets applications and agents request scoped credentials at runtime using their deployment identity and handles token exchange and renewal. It still supports static API keys for providers that lack OAuth or another identity-based option. Its documentation describes storing those keys centrally and pulling them at runtime, and the keys underneath can still live indefinitely. A static key in a central vault is still a static key. It just has a nicer address.

Until the CLI speaks OIDC, the most dangerous string in your Vercel deploy is the one Vercel's guide tells you to paste in. Vercel just gave its vendors an expiry date. Give your token one too.

Safari Technology Preview 255 puts a button in select and spends fifteen fixes on line-clamp

Leo — Fri, 23 Oct 2026 16:07:55 +0000

Truncating text to a few lines has been copy-paste folklore for about as long as cards have had titles. You grab the snippet, it works on your test string, and you never look at it again until a float shows up below the cut and the whole thing falls apart. So yes, Safari Technology Preview 255 has a shiny forms feature. I'll get to it. The part I keep rereading is the fifteen separate line-clamp fixes.

The build, in one paragraph

STP 255 shipped on October 22 for macOS Golden Gate and macOS Tahoe, covering WebKit changes 322011@main through 323397@main. The new features are support for <button> in the native appearance of <select>, the side attribute on the SVG <textPath> element, the inline layout engine switched on for SVG text, the cross-origin-isolated Permissions Policy feature, transferring streams to an AudioWorklet, and a CSS keyframe animation editor in Web Inspector. One method is gone: the unimplemented document.implementation.createCSSStyleSheet(). The rest of the notes are mostly fixes, and there are a lot of them.

A button inside the select

The note is a single line: added support for <button> in the native appearance of <select>. It ships with no markup example, so I'm not going to make one up and pretend it's official. What I can tell you is that the Forms section brings two related fixes. :open had stopped matching a <select> while its base appearance picker was still showing, and a <select> was computing its selected option's style from outdated ancestor styles. Both are fixed. If you're building a customizable select in this preview and your :open styles dropped while the picker was still on screen, that was this bug.

Fifteen ways a clamp can leak

Here's the pile, sorted by what actually went wrong:

Content past the clamp point stayed around. Block boxes after it stayed visible and kept taking up space. Floats after it stayed visible, and so did absolutely positioned elements whose containing block is an inline after the clamp point.
Floats misbehaved. They made the line-clamp container taller, added to its scrollable overflow, and painted past its block-end content edge.
The ellipsis landed in the wrong place. It could appear after a <wbr> in a white-space: nowrap line, on a line containing only a float, or refuse to hang with hanging-punctuation.
line-clamp: auto had its own problems. It couldn't clamp between sibling blocks, it clamped inside a box with a set height, and it applied no clamp at all until the clamp point was found.

The other two: a line-clamp container now establishes an independent formatting context, and content before the clamp point no longer loses its lines when it hasn't changed.

That's a whole category of layout bugs getting worked through in one build (a clamp that leaks floats is not a clamp). If you wrote off line-clamp in this engine after a float broke it, test it again in this build.

Cascade fixes you'll feel in hand-written CSS

This one is small and it bugs me that it existed. font-family: initial was behaving like font-family: inherit, so you got the parent's font instead of the property's initial value. Fixed:

.plain-text {
  font-family: initial;
}

initial and inherit are two different keywords that mean two different things, and a reset rule written with one was quietly getting the other.

The deeper cascade fixes: revert inside @starting-style was dropping @starting-style declarations from lower cascade layers. revert and revert-layer used the wrong cascade origin for visited and unvisited link styles, which wrongly disabled native appearance. :visited wasn't updating for links inside shadow trees. @scope now invalidates scope membership correctly when structural DOM changes affect the scoping root selector. And tree-scoped var() and custom function references inside an @function now resolve when the function is called from a :host rule. If you run layers, entry animations or shadow DOM in this preview, those are your bugs.

Two accessibility fixes for HTML you already write

Radio groups first. In HTML, putting required on any radio in a group makes the whole group required. The notes say WebKit now also exposes every radio in the group as required to assistive tech when only one carries the attribute:

<fieldset>
  <legend>Shipping speed</legend>
  <label><input type="radio" name="speed" value="standard" required> Standard</label>
  <label><input type="radio" name="speed" value="express"> Express</label>
</fieldset>

Second, VoiceOver presses were dispatching a click event with an event.detail of 0. That's fixed too, and it's a good excuse to stop guessing the input device from event.detail. A click is a click.

There's also a popover fix in the HTML section: tabbing to a popover invoker now moves focus into the popover itself when the popover is focusable.

Where it stands

This is a preview build of one engine. The notes make no Baseline claim and I won't add one, so the <select> button support and the side attribute are things to try out on a test page, not to ship. One known issue to keep in mind: document.activeElement returns the <html> element instead of null in HTML documents with no body. The notes say other browsers behave differently and that this breaks the WebDriver Get Active Element command.

It's like a roguelike balance patch where the headline is a new item and the actual changes are fifteen fixes to the build you were already running. A solid 7 for features and a 9 for the cleanup.

GitHub's package firewall puts a policy check between your runners and npm

Leo — Thu, 22 Oct 2026 10:24:10 +0000

I used to treat npm ci as the boring part of a job log, the stretch where you refill your coffee. Lately I read it differently, because that stretch is when a runner pulls code nobody on the team has looked at and runs its install scripts while the job's tokens are still loaded. GitHub's new package firewall is aimed at exactly that stretch.

GitHub put the firewall into public preview on October 20 for all GitHub Enterprise Cloud customers, including Enterprise Cloud with data residency. GitHub's reasoning will sound familiar to anyone who owns a pipeline: agents and CI runners install dependencies to finish a task or a build with no human in the loop, which makes them the easy target for malware that fires at install time.

A gate in the network path

The firewall sits between your endpoints (or your internal registries) and the upstream package repositories. Both metadata requests for package lists and the package downloads themselves flow through it, and it checks each one against policy before the install proceeds.

Administrators set that policy at the enterprise level. The controls available today are:

a configurable cooldown period
checks against the GitHub Advisory Database for malware or vulnerability advisories
supply-chain checks such as attestation downgrades

If the firewall blocks a package by mistake, the user can request an exception through a workflow similar to other GitHub Advanced Security features. The service is free during the preview. At general availability GitHub plans to charge for it on metered usage, similar to Actions billing.

Right now it only supports npm.

Why the cooldown is the control I'd turn on first

I find the cooldown the most interesting control, because of how these attacks usually play out. A malicious version gets published, someone spots it, and the registry pulls it. A cooldown keeps brand-new versions away from your builds for a period you choose, so your runner doesn't have to be among the first machines to install them. You stop being an early adopter by default.

Pointing a runner at it

GitHub sends you to its docs page, Protecting endpoints with package firewall, for setup. The changelog doesn't give the endpoint format or the auth method, so take both from the docs. For npm, the change on the runner side comes down to a registry setting, roughly:

# values come from the setup docs; these are placeholders
npm config set registry "$PACKAGE_FIREWALL_URL"
npm ci

Before you trust it, check that installs really go through the firewall. Scoped registry settings in a committed .npmrc and the resolved URLs in a lockfile can both point npm somewhere you didn't expect. And if the runner can still reach the public registry directly, you have a gate with a gap beside it, so restrict egress where you can.

Where it gets awkward

A few things gave me pause:

npm only. A polyglot repo with pip or Maven jobs is still installing those packages unchecked.
A cooldown cuts both ways. If a dependency ships an urgent fix today, a long cooldown keeps that fix away from your builds too. Decide ahead of time how you'll handle that exception.
A false positive now means a red build that waits on someone approving an exception. Find out who that is before the first Friday afternoon block.
It's a preview, and GitHub says it is still scaling up the infrastructure behind it. Every install depends on it once you route through it, so watch your install times.
Metered billing at GA means install volume becomes a cost line. Busy monorepos with lots of matrix jobs should get an estimate early.

Same idea, different layers

GitLab put its Dependency Firewall into early access for Premium and Ultimate. It works with GitLab's own registry and with external Nexus and Artifactory registries, and it covers npm, pip, Poetry, Maven, Gradle and Bundler. So it supports more ecosystems today, if you're on GitLab.

Teams already running a repository manager can apply similar policy at the proxy itself. Sonatype and JFrog both sell this kind of control for Nexus and Artifactory.

Closer to the client, pnpm (minimumReleaseAge) and Yarn (npmMinimalAgeGate) can hold back fresh versions on their own, with no proxy involved. Dependabot and Renovate have cooldown settings for update PRs as well. Those work one step earlier: they slow down the PRs that bump a version, but they don't stop a job from installing whatever a loose version range resolves to.

GitHub's version stands out mainly for where it sits: one enterprise-wide policy in front of every runner and coding agent you route through it. If you're already on Enterprise Cloud and mostly install npm packages, it costs you a registry setting to try during the free preview.

Next I'm watching for a second ecosystem. pip is the one I'd want, because a lot of my CI time goes to Python test jobs and none of them get this protection yet. If you've routed a busy pipeline through the preview, I'd like to hear what it did to your install times.

The Interop 2027 CSS shortlist reads like a list of hacks you get to delete

Leo — Wed, 21 Oct 2026 16:08:17 +0000

You want hairlines between the cells of a 3×3 grid. Two cells have content. Seven are empty. And an empty grid cell has no element, so there is nothing to put border: 1px solid on.

So you fake it. Paint the grid container red, set gap: 1px, give every child a white background, and pad the markup with seven empty divs so the background only shows through the gaps. It works. It's also seven DOM nodes that exist purely to hide paint.

Josh W. Comeau shows that exact workaround in his new post on Interop 2027, and then shows the property that makes it unnecessary. That's the useful way to read his whole list. Most of the ten features he voted for replace something we currently fake.

How the list gets made

Interop is the yearly project where the browser vendors (Comeau names Google, Apple, Microsoft and Mozilla, along with Igalia and Bocoup) agree on a set of focus areas and work on them together. He writes that a focus area added to Interop often reaches near-100% support across the major browsers within a year.

His example is subgrid. Firefox implemented it in 2019, other browsers barely moved for years, then it went into Interop 2023 and was widely available across modern browsers by the end of that year.

For 2027, the team at Mozilla built a ranking system where developers upvote the features they want, and Comeau writes that they plan to use that ranking data to decide what goes into next year's Interop.

Lines that belong to the grid

Gap decorations add a border-like syntax to the grid itself:

.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: repeat(3, 1fr);
  gap: 1px;
  border: 1px solid red;
  rule: 1px solid red;
}

rule is a shorthand, like border. Width, style, color. Use row-rule or column-rule when you only want lines in one direction.

Comeau lists three problems with the background trick: the empty nodes, the fact that it only works on a solid page background, and the lost flexibility. For example, you can't leave space between the grid's outer border and its inner lines. The mechanism explains all three. The lines come from paint showing through a gap, so the gap is all you get to style. rule makes the line its own thing.

Corners the border box follows

border-radius puts a quarter-circle on each corner. corner-shape swaps that curve for something else: squircle, bevel, notch, scoop.

.box {
  border-radius: 16px;
  corner-shape: bevel;
}

You could already cut shapes like these with clip-path or masks. The difference is where the change happens. According to Comeau, corner-shape changes the shape of the border box itself, so borders, outlines and box-shadows follow the new corner. A clip only hides pixels, so the border and shadow get cut off with everything else instead of tracing the new edge.

border-shape goes a level lower. You draw the border yourself out of straight lines, arcs and Bézier curves, and the same thing holds: the real border box changes, so outlines and shadows trace it. Comeau calls corner-shape a perfect progressive enhancement. Unsupported browsers fall back to the plain rounded corner, which is fine.

auto gets a transition

You can't animate to height: auto. You've hit this. interpolate-size fixes it, alongside the related calc-size() function. Comeau's accordion demo opts in at the root and animates the ::details-content pseudo-element:

html {
  interpolate-size: allow-keywords;
}

@supports (interpolate-size: allow-keywords) {
  details {
    overflow: hidden;

    &::details-content {
      height: 0;
      transition:
        height 300ms,
        content-visibility 300ms;
      transition-behavior: allow-discrete;
    }
    &:open::details-content {
      height: auto;
    }
  }
}

Keep that @supports gate. Comeau warns that without it, unsupported browsers get a brief delay added. He also notes this has been in Chrome since 2024, which is a long time to wait for an accordion.

State you used to read from JavaScript

Several picks are queries for state that CSS couldn't see before.

Scroll-state container queries. Put container-type: scroll-state on a sticky header and @container scroll-state(stuck: top) matches once it sticks. The same API answers scrollable: top and scrollable: bottom, which is all you need to fade those scroll-hint gradients in and out.
Anchored container queries, from Level 2 of Anchor Positioning. They let you check whether a positioned element is using a fallback position, so a tooltip's pointer can flip when the tooltip does.
Scroll-triggered animations. These are a separate proposal from scroll-driven ones: the animation starts when the user scrolls to a point and then runs over a specified duration. Today that means IntersectionObserver.
reading-flow and reading-order. Tab order follows the DOM, not the layout, so a grid that rearranges on mobile focuses things in the wrong order. reading-flow: grid-rows on the grid makes focus follow the visual rows.

Functions, and one that exists nowhere

@function lets you define a custom function, such as --gradient-to-transparent(--color, --direction: bottom), and return its value with result. Call it like any other value: background: --gradient-to-transparent(red). Comeau writes that it is already implemented in Chromium browsers.

Then there's inherit(). Comeau says he couldn't find it implemented in any browser. It takes the inherited value and lets you do math on it, which is exactly what nested radii need:

p {
  border-radius: calc(inherit() - 4px);
}

He'd be a bit surprised if it makes the 2027 cut. I'd vote for it anyway.

Where support stands

The support tables in Comeau's post, marked current as of October 2026, list Chrome 155 and Edge 154 as supporting each feature that has a table, and Firefox 157 and Safari 27 as not supporting it. inherit() has no table because it isn't listed on caniuse. That's one engine family carrying every tabled feature today, which is the gap Interop exists to close.

For your next layout, sort by fallback. corner-shape and the gated interpolate-size accordion degrade to something perfectly usable, so ship them now. Gap decorations are harder. The fallback is no lines at all, so the background trick stays until rule ships in more than one engine. Whether that happens in 2027 depends partly on how the Mozilla ranking comes out.

CSS random() puts a little deliberate mess back into your layout

Leo — Tue, 20 Oct 2026 16:08:13 +0000

If your "hand-made" look is a Sass loop spitting out forty :nth-child rules with hard-coded rotations, I've got bad news. That was never randomness. It was a lookup table in a fake mustache. (Everybody shipped one. Mine had a diff you could see from orbit.)

Brecht De Ruyte's new piece in Smashing Magazine is about what replaces it: the native random() function from the CSS Values and Units Level 5 spec. According to his article, Safari landed it first, Chrome 156 is rolling it out right now, and Mozilla has sent positive signals about Firefox. The syntax isn't actually the best part. De Ruyte builds design systems for a living and says so up front ("Consistency is usually our bread and butter as design engineers"), and then he goes looking for the few places where a bit of mess is the right call.

The arguments, one at a time

Here's the grammar he quotes from the spec:

random( <random-caching-key>?, <min>, <max> [, by <step>]? )

In practice he writes plain comma-separated arguments:

rotate: random(-3deg, 3deg);
inline-size: random(20px, 80px, 10px);
animation-duration: random(1.5s, 3s, 0.2s);

The min and max have to share the exact same unit type. random(-4deg, 4deg) is fine, and so is the unitless random(0.3, 1). random(2rem, 100px) is invalid. If you need to mix units, De Ruyte says to put calc() inside the arguments.

The third argument is the step. Without it the browser picks from a continuous range. With it, the value rounds to discrete increments, so top: random(0px, 60px, 15px) only ever lands on 0, 15, 30, 45 or 60px. That's jitter that still respects your grid.

Then there's the caching key, the one piece that needs a real explanation. By default, every random() on a property rolls its own independent value. Randomize inline-size and block-size separately and your "random square" comes out as a random rectangle. Give both declarations the same key and the engine shares the computed value between them:

.card-thumbnail {
  inline-size: random(--square-size, 60px, 120px);
  block-size: random(--square-size, 60px, 120px);
}

Quick tangent, because this tripped me up. --square-size looks exactly like a custom property, but nothing in that snippet ever declares it. It doesn't hold a value. It's a name the two declarations share. OK, back on track.

Wobbly type, bouncing letters, a fanned-out deck

De Ruyte's first demo splits a word into .char spans and gives each letter a tiny tilt, a nudge and a little ink variance:

.char {
  display: inline-block;
  rotate: random(-2.8deg, 2.8deg);
  translate: random(-1.5px, 1.5px) random(-2.8px, 2.8px);
  opacity: random(0.8, 1, 0.02);
}

Hover the word and a .word:hover .char rule resets every letter to straight. Honestly, the first time I watched letterforms wobble with zero JavaScript involved, I felt the way I did the first time :hover worked on something that wasn't a link. A small thing, and it made me grin.

The second demo feeds random() into custom properties (--jump, --dur and a negative --delay), so every letter is already mid-bounce on page load and no two move in sync. The splayed-card demo is the one I'd steal. sibling-index() and sibling-count() compute the fan structure, random() adds jitter on top, and animation-timeline: scroll(root) drives it as you scroll. Math sets the layout, and randomness only nudges it. Then he closes on a punk fanzine called "Never mind the defaults", which, as someone whose teens were scored by drop-D riffs, I respect.

Where it stays out

His no-go list is the part to print out. No randomness in core layouts and grids (column gutters, form field widths, container padding). None in body copy (font sizes, line heights, letter spacing on long paragraphs). And no tilted or shifted buttons and links unless they reset on hover and focus. In his words: "If a user has to chase a moving or crooked button, you've failed them."

There's also the accessibility homework. Split a word into spans and screen readers may read it out letter by letter, so his markup puts aria-label on the h1 and aria-hidden="true" on the wrapper span. Under prefers-reduced-motion: reduce he removes the animation and also flattens rotate and translate. His reasoning is that a lot of random angles can bother people while they scroll, not just the motion.

Using it before every engine has it

Because it's still rolling out, De Ruyte wraps the enhancement in @supports and keeps a straight default:

.badge {
  rotate: 0deg;
}

@supports (rotate: random(-2deg, 2deg)) {
  .badge {
    rotate: random(-2.5deg, 2.5deg);
  }
}

He also points to random-item(), which is in the same spec and picks from a list instead of a range (random design tokens, say). He notes that no browser supports it yet.

Verdict: your tokens set the structure, and the engine adds a few degrees of controlled chaos. That's an 8/10, and it only drops two points because one engine still hasn't shipped it.

GitLab Secrets Manager hits GA in 19.5 and scopes credentials to the job

Leo — Tue, 20 Oct 2026 10:24:22 +0000

Open the CI/CD settings of any GitLab project older than two years and count the masked variables. (Go on. I'll wait.) Each one is a raw value sitting in a settings page, readable by whatever jobs the old protection flags allow, and good luck proving which job actually read it last Tuesday. GitLab now wants those variables retired. Secrets Manager is generally available in GitLab 19.5 for Premium and Ultimate, on GitLab.com and GitLab Self-Managed. GitLab Dedicated support is listed as coming soon.

When we covered the public beta in August, it was a preview. Now it is a product, and it comes with a price tag.

What exactly shipped

The store runs on OpenBao, the open-source fork of HashiCorp Vault, and GitLab says values are encrypted at rest with AES-256-GCM. It is a paid add-on billed through GitLab Credits: one credit per secret stored per month, and one credit per 2,500 read operations.

The CI side works like this, per GitLab's announcement:

A job declares the secrets it needs with the secrets: keyword in .gitlab-ci.yml.
GitLab injects a value only into jobs that declare it and fall inside its scope. Scope conditions take wildcards on branch and environment, and they combine, so one rule can demand both a protected branch and a production/* environment.
The job gets a path to a temporary file instead of the value itself. Values are masked in logs and discarded when the job finishes.
Jobs fetch from OpenBao with short-lived tokens bound to that job's identity.

Where the trust boundary moved

Isn't this just Vault with a tanuki on it? Partly, and GitLab doesn't hide the OpenBao underneath. The difference is who decides access. Secrets Manager reuses GitLab's namespace isolation: projects inherit secrets from their parent groups, and owners grant read, write and delete through the membership model you already maintain. There is no second permission model to drift out of sync with the first one (the usual way a "temporary" Vault policy turns permanent).

Then the audit trail. GitLab streams every create, read, update and delete event to your audit event destinations, and every CI/CD read carries the pipeline and job ID, tied back to the commit, the user and the merge request. When a token shows up somewhere it shouldn't, you can work backwards from the read event to the MR that triggered it. A plain CI/CD variable never gave you that.

Moving a pipeline over

The path today is manual. Create the secret at the group or project level, give it the narrowest branch and environment scope you can live with, then add a secrets: block to the jobs that need it. Since the job receives a file path, check every script and tool that expected the raw value in an environment variable. That's where the first migration bug usually turns up.

Read this before you migrate

No migration tooling yet. GitLab says a migration workflow for CI/CD variables is in development. Until it lands, every variable you move is a manual change and a chance to fat-finger a scope rule.
The runtime side is not GA. The consumers beyond CI (External Secrets Operator for Kubernetes, Terraform and OpenTofu data sources, the OpenBao and Vault CLIs over a Vault-compatible API, and the Secrets Manager API) are still listed as beta or in development.
Reads are metered. Billing per 2,500 reads is cheap until a wide matrix build fetches the same credential in every cell. Scope tightly and the bill shrinks along with the blast radius.
Masking does not stop exfiltration. A job that is allowed to read the file can still send it anywhere it has network access. The scope rule is the real control. The log mask is cosmetic.

How other CI platforms divide up secrets

Every CI platform has some answer to "which job gets which credential". They draw the boundary in different places:

GitHub Actions has repository, organization and environment secrets. Environment protection rules (required reviewers, deployment branch rules) decide which runs can see an environment's secrets, and OIDC federation to cloud providers lets you skip storing long-lived cloud keys at all.
Jenkins uses the Credentials plugin with folder-scoped credentials and withCredentials bindings. It is very flexible. Tracing which build used which credential is left to whatever plugins and logging you add yourself.
CircleCI groups secrets into contexts that can be restricted to security groups, and it issues OIDC tokens to jobs for cloud federation.
A standalone Vault or OpenBao cluster with JWT auth against your CI's identity tokens is the better fit when several CI systems, or non-CI workloads, share the same credentials. You get one store with many consumers, and it doesn't care which CI vendor you leave next year.
Buddy lets you define variables at the workspace, project, pipeline or single-action level and mark them as encrypted so they are masked in logs. That suits teams that use Buddy as the delivery layer across more than one Git host and want a deploy credential visible to one action instead of the whole pipeline.

To be fair to GitLab, if your repositories, runners and permissions already live there, its native manager is the better fit. Reusing the permission model you already have is the entire selling point, and none of the alternatives above can offer that.

My verdict: worth adopting for any job that touches production, once you have budgeted the reads and accepted a manual migration. Just remember what the feature promises. It decides which jobs get the secret. Whatever that job does with it afterwards is still your problem.

GitHub Actions lockfiles pin the commit and leave your tags alone

Leo — Sat, 17 Oct 2026 10:24:15 +0000

You reviewed the action. You approved the pull request. Then someone moved the tag, and your next run executed code nobody on your team has ever read. (Tags are sticky notes. Nobody ever promised they were signatures.) GitHub's answer is workflow dependency lockfiles, now in public preview. You keep @v1 in your YAML, and the run uses the commit you actually reviewed.

What shipped

The preview covers GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free. GitHub Enterprise Server is not on that list.

The work happens in a GitHub CLI extension, gh actions-lock. It generates .github/workflows/actions.lock, which records reviewable commits for each action, for that action's transitive dependencies, and for reusable workflow dependencies. You onboard workflows one at a time. Once a workflow is onboarded, every one of its dependencies must have a lockfile entry, and Actions runs the recorded commit even if the tag or branch has since moved. The extension can also check whether the lockfile is stale without modifying anything, and GitHub says that check can run in CI.

Two pieces sit around it. A Require lockfile policy, also in preview, lets enterprise, organization and repository administrators make lockfiles mandatory within their scope. Dependabot, when it opens a version update for an action in an onboarded workflow, regenerates the matching lockfile entry in the same pull request.

Couldn't I just SHA-pin everything?

You could. Plenty of us do. But anyone who has maintained it knows what it costs: 40 characters of hex on every uses: line, a # v1 comment that quietly drifts out of sync with the SHA, and diffs nobody reads. Worse, your pin covers one edge of the graph. A composite action you pinned by SHA can still call another action by a floating tag, and you never see that line because it lives in someone else's repository.

The lockfile closes both gaps. The readable reference stays in the workflow, the commit moves into a file you can diff, and the transitive dependencies get locked too. Same trick package-lock.json and go.sum pulled years ago, finally applied to the layer of the stack that holds your deploy credentials.

Rolling it out

Install the extension from the public github/gh-actions-lock repository:

gh extension install github/gh-actions-lock

Then generate the lockfile, review it, and commit it together with the workflow changes the tool produces. Start with the workflows that hold secrets or deploy permissions. Add the stale-lockfile check to CI so a drifted lockfile fails a pull request. Turn on Require lockfile only after the important workflows are onboarded, unless you enjoy a red Monday. The exact subcommands are in GitHub's workflow dependency lockfiles documentation, and I am not going to guess them for you.

What a lockfile will not do

GitHub says this plainly in the changelog: locking "does not determine whether the dependency itself is safe, so review dependencies before locking them." Lock a backdoored commit and you get a backdoored workflow that runs exactly the same way every time. Reproducible. Still compromised.

The Dependabot integration deserves the same suspicion. When a bot PR updates both the reference and the locked commit, that PR becomes your trust boundary. Rubber-stamp it and you have automated the tag move with extra steps.

Then there is scope. The changelog describes locking commits for actions, their transitive dependencies and reusable workflows. It says nothing about container images or binaries an action downloads at runtime, so assume those are still yours to pin by digest ($REGISTRY/image@sha256:<digest>). And until the policy is on, any workflow you have not onboarded still floats.

How other CI systems handle the same problem

Every CI system has this problem. Here is how pinning looks in three of them.

GitLab CI/CD lets you pin include: references and CI/CD components to a commit SHA. That is pinning per reference: you write each SHA yourself, one line at a time.
CircleCI orbs are referenced by version. A full semantic version points at a published release, while a major-only reference such as @1 picks up newer releases automatically.
Jenkins shared libraries load via @Library('name@ref'), where the ref can be a branch, a tag or a commit. Same model: safe if you choose a commit, floating if you choose a branch.

What GitHub adds is transitive coverage and an admin policy to enforce it, at least on paper. It is still a preview, built with community contributors that GitHub credits by name, including Andrew Nesbitt and William Woodruff, so expect rough edges.

Verdict

Adopt it, starting with your most privileged workflows, and wire up the stale check on day one. This is the pinning model Actions should have shipped with: readable references, locked commits, transitive coverage. Just don't confuse a lockfile with a review. It records what you decided to trust. It has no opinion on whether you were right.

A DevTools pane now draws the ranges behind scroll-triggered animations

Leo — Fri, 16 Oct 2026 16:07:56 +0000

Scroll-triggered animations are hard to debug because the part that matters is invisible. You set a range, you scroll, and the animation either fires or it doesn't. Then you guess which edge you got wrong. Bramus van Damme's new DevTools extension, announced on Bram.us on October 14, puts that part on screen.

The extension adds a pane called "Scroll-Triggered Animations" to the Elements panel in Chrome DevTools. Select an element and the pane shows an interactive minimap of the scroller, the element and the subject. It handles both timeline types, ScrollTimeline (scroll()) and ViewTimeline (view()), and the post says it works with position: sticky.

Blue, green and a status light

The ranges are why you'd open it. timeline-trigger-activation-range is drawn in blue and timeline-trigger-active-range in green, and you can edit both values live in the pane. Next to them is a status light that goes from red (Inactive) to green (Active) when the trigger activates. That light is what I'd watch first. Say you've scrolled past where the trigger should fire and the light is still red: the problem is your range, and the minimap shows you how far off it is.

This is also a sequel. Bramus built a Scroll-Driven Animations Debugger extension in 2023, and the new one reuses code from it.

The rough edges

The post names two limits up front. Ranges written in relative units such as 90vh are shown as resolved pixel values, because that is how the Animation instance and getComputedStyle() report them. Elements inside an iframe don't work at all. The pane either shows an error or wrongly reports that there are no animations, and the post traces this to a Chrome DevTools bug, crbug/1480418.

It is a Chrome DevTools extension distributed through the Chrome Web Store, so it only inspects what Chrome renders. The post doesn't mention tooling for other engines.

What I'm watching next is that iframe bug, since embedded demos are exactly where it gets in the way. I'm also watching for a similar range view in the devtools of other engines.

calc-size() and round() stop your background pattern getting chopped at the bottom

Leo — Thu, 15 Oct 2026 16:08:07 +0000

Some ugliness only ever shows up on the last row of a tiled background. The pattern repeats perfectly, the content stops wherever the content stops, and the bottom row of tiles gets sliced in half like a sprite with a broken hitbox. Everyone has shipped it. Most of us shipped it and then just stopped looking at the bottom of that section.

Ahmad Shadeed ran into exactly this on a section whose pattern repeats on both axes. His write-up on ishadeed.com, published October 15, goes from the quick fix to a better one. The better one combines calc-size() with round(), and it's the kind of small, smart CSS move I want to see more of. The big catch goes up front: Shadeed says the solution "works only in Chrome at the time of writing this article."

The setup

The tile size lives in two custom properties, so everything else can refer to it:

.section {
  --tile-width: 52px;
  --tile-height: 44px;
  background-image: url("pattern.png");
  background-size: var(--tile-width) var(--tile-height);
}

The content sets the height, and the tile is 44px tall. Those two numbers almost never line up, so you get the cut-off.

Why background-repeat: round loses

The first reflex (Shadeed's too) is background-repeat: round. It does kill the cut-off. It does that by resizing the tiles until a whole number of them fits the box, so your 52 by 44 pattern stops being 52 by 44. Shadeed's objection is that the round keyword forces the pattern to shrink or grow, and the "Make it dance" button in his demo makes the wobble impossible to unsee. If the pattern is part of the brand, or lines up with anything else on the page, a tile that changes size with the length of the copy is a bug dressed up as a fix.

So flip it around. Leave the tile alone and fix the box.

Round the box, not the art

.section {
  height: calc-size(auto, round(up, size, var(--tile-height)));
}

Read it from the inside out. calc-size() takes auto as its basis and lets you do math on it, with size standing in for that auto height. Then round(up, size, var(--tile-height)) snaps the result up to the next multiple of the tile height. If the content needs 170px and the tile is 44px, you get 176px. That's four whole rows and no slice.

It looks like a fixed height, and it isn't one. Shadeed points out that it behaves like min-height: the browser works out the auto height first and only then rounds it, so the section still grows with its content. The only input is the tile height, which is why the same line works across different patterns without any retuning.

Quick detour. Doing math on auto in plain CSS still gets me. For years the options were measuring in JavaScript or hard-coding a magic number and hoping the copy never changed. OK, back.

Up, down, and the padding problem

round() also takes down. According to Shadeed, rounding up makes the section taller in most cases. Rounding down never adds height you didn't need, and he says he actually prefers down for the height, while calling the choice "not a big deal."

Padding is where the choice starts to matter. He rounds the vertical padding to the tile as well:

.section {
  height: calc-size(auto, round(up, size, var(--tile-height)));
  padding-block: round(up, 1rem, var(--tile-height));
}

With up, the 1rem snaps to a full step, so the top and bottom padding each come out equal to the tile height. Round that padding down and the content ends up too close to the edge. Shadeed says that's where it starts to feel odd, so he switches to rounding up. I agree with him: up is the right default for the padding, and whether the height goes up or down is a matter of taste.

The full rule

Here's Shadeed's complete version:

.section {
  /* This must match the size of the pattern image. */
  --tile-width: 52px;
  --tile-height: 44px;
  background-image: url("pattern.svg");
  background-size: var(--tile-width) var(--tile-height);
  padding-block: round(up, 1rem, var(--tile-height));
  height: calc-size(auto, round(up, size, var(--tile-height)));
}

That comment is the only maintenance burden here. Change the artwork and you update two custom properties. Nothing else changes.

Who actually sees it

The support widget in Shadeed's post marks calc-size() as Limited availability and not Baseline. It's supported in Chrome and Edge, and not in Firefox or Safari. So treat this as progressive enhancement. A browser that can't parse a value drops the whole declaration, which means it ignores that height line and the section falls back to plain auto height, cut-off and all. Nothing breaks. Those browsers just show what you were shipping yesterday.

Score: 8 out of 10. It fixes the box instead of bending the artwork, which is almost always the right instinct in CSS. It loses two points for running in only one engine family today.

GitLab's Dependency Firewall moves package policy in front of the build

Leo — Thu, 15 Oct 2026 10:23:37 +0000

GitLab introduced Dependency Firewall in early access at its Transcend event. It is a policy layer that blocks malicious, vulnerable and non-compliant packages before they reach a build. For CI owners, the useful part is where the check runs. Most dependency scanning reports on a package after a job has already installed it. This firewall is meant to stop the package before install, while the job still holds its credentials and nothing hostile has executed.

What shipped

Per the GitLab blog, the firewall is available to Premium and Ultimate customers on both GitLab.com and GitLab Self-Managed. It works with GitLab Artifact Central and with external registries from Sonatype Nexus Repository and JFrog Artifactory. Supported package managers at launch are npm, pip, Poetry, Maven, Gradle and Bundler, and GitLab says more are coming.

Policies can match on four things:

malicious status, drawn from GitLab's malware advisory database
vulnerability severity, at critical, high, medium or low
license type, with an allow or deny list
package age, a minimum age a package must reach before it can enter a build

Each policy runs in one of two modes. Warn mode records what the policy would have caught and lets the build continue. Block mode stops the pipeline on a match and reports the reason. A logged bypass lets a designated user or token proceed anyway, and the bypass is recorded.

Why the install step is the exposure

GitLab's own research is the case for the feature. In June 2026, its researchers found five malicious PyPI packages, four of them typosquats of Flask, Requests and NumPy. The packages ran at install time and stole CI/CD credentials.

That shapes the blast radius. A package that executes during pip install runs inside the job, with whatever tokens, cloud credentials and deploy keys that job can reach. A scanner that flags it in a report afterwards is useful for the incident timeline, but the secrets are already gone. Rotating them is the expensive part of the response, and it usually means paging someone.

GitLab also notes that AI coding agents now add open source dependencies on their own, often unreviewed. A typosquat that a human reviewer might catch in a diff can reach a merge request that nobody reads line by line.

Rolling it out without breaking main

The two modes suggest the order to work in. Start every policy in warn mode, let it run across a normal week of pipelines, and read what it would have blocked. License and severity policies are the likeliest to match dependencies you already ship, and you want to see those matches before they turn into red builds. Move the malicious-status policy to block first. That is the one with the fewest legitimate matches and the most damage if it misses.

Decide who holds the bypass before you turn on blocking. A bypass that only one person can grant will turn into a 3am bottleneck the first time a hotfix trips the age policy.

Where it will bite

The package-age policy works against urgent patches. When a critical fix lands, the version you need is by definition the newest one, and a minimum-age rule will block it. Plan for that case through the logged bypass, not by loosening the rule under pressure.

Bypass tokens are credentials. Treat them like any other secret that can push a blocked package into a build. Scope them, rotate them and review the bypass log.

Coverage is bounded twice. Malicious-status matching is only as current as GitLab's malware advisory database. Ecosystems outside the six listed package managers are not covered yet. During early access, also confirm that every job actually resolves packages through one of the supported registries. A job that installs straight from a public index is outside the gate.

How teams gate dependencies elsewhere

Pre-install gating is not new to the package-registry market. Sonatype and JFrog both sell curation products that sit in the repository manager, which is why GitLab's support for Nexus and Artifactory registries matters to teams that already run them.

Teams without a registry-level gate usually combine smaller controls. Renovate's minimumReleaseAge setting delays update pull requests until a release has aged, which is the same idea as GitLab's age policy applied at proposal time instead of at install time. Lockfiles with hashes make an install reproducible:

pip install --require-hashes -r requirements.txt
npm ci

Hash pinning stops an artifact from changing under you, but it does nothing about a malicious package that was pinned on purpose. That case still needs a reviewer, or a policy that runs before install.