Demo: jsbin.com/linisaketu/e...

"The computed value of a registered custom property is determined by the syntax of its registration. [...] If the specified value is a dimension literal (such as 50em), the computed value is the same value, but with the unit converted to the corresponding canonical unit for the type of value."

Screenshot of two nested divs with container-type: inline-size. The inner container has 60% width and contains two boxes: One with width 50cqw relative to the inner container and one wider one with width 50cqw relative to the outer container.

:root { --size: 50cqw; } .outer-container { container-type: inline-size; } @property --px-size { syntax: '<length>'; inherits: true; initial-value: 0px; } .inner-container { /* Turn cqw into computed pixel value */ --px-size: var(--size); container-type: inline-size; width: 60%; } .box.with-size { width: var(--size); } .box.with-px-size { width: var(--px-size); }

TIL you can use registered custom properties in CSS to force computing a property value at a certain level in your DOM instead of just applying text based substitution. This can useful when working with nested containers and wanting to reference an outer container in via container query units.

Otherwise `jj split -r X` keeps the selected changes in X and creates a new change id for the remaining changes on top of it, forcing you to first look up the new change id before you can run the next split command.

TIL if you want to split out multiple smaller changes from a larger one, you can use `jj split -r X -B X` to make sure the id of the remaining big change stays stable. #jj-vcs

I especially like that pinning keeps watching the continuously rebased bookmark even if I temporarily move to another change somewhere in my current stack of changes.

With git I often used to do `git diff my-feature@{1}` after an interactive rebase instead. jj's more fine grain history rewrite commands are way more versatile, but no longer give me this well defined before/after by default.

jj pin – guard the tree at a bookmark during history cleanup jj pin – guard the tree at a bookmark during history cleanup - jj-pin.bash

jj-pin lets me display an indicator in my prompt that tells me when the diff between trunk and the pinned bookmark diverged from its initial state.

Also TIL about Git's ^{tree}.

gist.github.com/tf/fd8e93a83...

~/my-repo[my-feature q]$ jj-pin 📌 pinned my-feature (7a738bec1452) ~/my-repo[my-feature q 📌]$ # Rearrange/clean up changes ~/my-repo[my-feature q 📌]$ echo "Accidental change" > foo ~/my-repo[my-feature q 📌✗]$ jj-pin-diff Modified regular file foo: 1: Accidental change ~/my-repo[my-feature q 📌✗]$ jj-unpin # when done

Experimenting with a custom jj-pin script to make history cleanup in #jj-vcs feel safer. I often find myself tweaking a stack of changes moving things around without wanting to change the overall diff. Especially when there are conflicts to resolve, I want to be sure not to mess up.

Crises precipitate change...

Besides accountability, I wonder about intentionality. Even with a perfect pipeline that turns every bug report and feature request into a working patch, isn't the act of building something as much about deciding what not to build?

I really wish there was something with the performance characteristics of transactional fixtures but the locality/ colocation of factories.

Found the GitHub issue: github.com/rspec/rspec-...

Doesn't plain vanilla Rails testing has some parallelization features that Rspec is missing?

Here's the helpdesk article using the screenshot: pageflow.freshdesk.com/en/support/s...

Screenshot of a JavaScript module exporting a set of labels used in the UI in German and English (like "Benutzer hinzufügen"/"Add user"), and a perform function that uses playwright functions (like getByRole, click, and waitForLoadState) referencing those labels , custom annotate functions to draw arrows and boxes, and a custom screenshot function to screenshot the viewport, passing a clipBelowAnnotations option.

Here's an example of a screenshot script.

Since the repository also acts as the source of truth for the HTML of the knowledge base articles (via a separate set of script to sync with the helpdesk), agents can automatically incorporate the correct CDN image urls based on screenshot script paths when updating articles.

I especially like that the resulting process to update screenshots is totally deterministic and does not involve agents directly.

I created a skill to interactively navigate my app to specify new screenshots. The skill then automatically figures out relevant labels in different locales and creates the screenshot scripts.

I've used Claude Code, to create scripts that navigate my app using playwright, draw annotations with SVG, take screenshots, create visual diffs with Percy and upload to S3.

Always finding it hard to balance fun gamification like that with making sure I'm actually working on the most important thing.

/cc @indirect.io @steveklabnik.com

I really like the squash workflow in #jj-vcs. But what are people using to inspect the resulting change? Do you always type out `jj diff -r @-`?

There's an interesting dynamic, where coding agents not only reduce the activation energy required to follow certain best practices (automated tests, small commits, limited scope etc.), but sort of turn them into prerequisites to have a chance of making the process work at all.

So inbound in the sense of having them request a demo etc. and then having them talk about their use case?

How do you approach customers/how do you frame the request? What's your process for picking customers to interview?

Nice. Could also apply some perspective to the parent section to give it additional depth.

What do you think about starting with de-risking unknowns?

Been wondering: What does the codecamp hashtag relate to?

Tried it a bit, but found it a bit unclear when which skill is active - especially across context compactions. Would be nice if /context included that info. Felt a bit more in control with custom slash commands.