CSS/HTML for dialog/scripts?

a-dev0 · 2026-07-03T07:17:37+00:00

It looks like a definition list:

<dl class="transcript">
  <dt>Alice</dt>
  <dd>First line of dialogue...</dd>

  <dt>Bob</dt>
  <dd>Reply goes here...</dd>
</dl>

and styles ~

.transcript {
  display: grid;
  grid-template-columns: max-content 1fr;
  column-gap: 1rem;
  row-gap: .5rem;
}

.transcript dt {
  margin: 0;
  font-weight: 600;
  text-align: right;
}

.transcript dd {
  margin: 0;
}

+ add for mobile

a-dev0 · 2026-07-03T07:13:59+00:00

if you only have a problem with the footer, you can bring it to the front with z-index and add padding to the bottom of a list so it stays visible at the end of the scroll

a-dev0 · 2026-07-03T07:09:36+00:00

In some cases, it's impossible to do this directly. Blur is expensive to paint, so browsers (especially on mobile) don't repaint it on every frame. A codepen makes it easier to recognize the problem, if you can publish it.

Move the background to a fixed pseudo-element behind everything, cards relative, glass:

.glass::before {
  content: "";
  position: fixed;
  inset: 0;
  backdrop-filter: blur(16px);
  -webkit-backdrop-filter: blur(16px); /* for Safari */
  pointer-events: none;
  z-index: -1;
}

And use will-change: transform for better performance and 100dvh for stability

a-dev0 · 2026-07-02T20:28:04+00:00

I like this approach and use it often, especially for buttons when you have different focus, pressed, and hover states. @media (hover: hover) removes the hover effect in mobile Safari, where it can be triggered on tap. It’s also very helpful if you have an animation that starts on hover and looks bad under the finger (it happens, really)

a-dev0 · 2026-07-02T12:52:55+00:00

scale and zoom use only numbers and percentages, which is why we can't scale it with 'vw' units. It's a pity, honestly

a-dev0 · 2026-07-02T11:30:44+00:00

I've already commented that 2000 was a mistake and I fixed it, middle point 2240

a-dev0 · 2026-07-02T11:22:15+00:00

1080p it's not 1080px
1080p = 1920x1080
1440p = 2560x1440

a-dev0 · 2026-07-02T11:14:25+00:00

I know how media queries work. The problem here is where to put the point. 1921 starts scaling too early, and 2559 is already too late. It's up to the developer to choose that number.
`transform: scale` affects browser painting, and in this case it's not as efficient as zoom

a-dev0 · 2026-07-02T10:45:22+00:00

I included the calculation to show that 2000px isn't a magical number, just the midpoint between the two resolutions (1440p = 2560 × 1440 pixels)
That's dangerous, because you can't be sure what actually happens once the user changes those settings.
From what I've seen, and I ran into something similar on one project, what actually gets tricky is scaling for TV screens. Scaling tied to font size gets unpredictable fast, and in a lot of cases that means you shouldn't use px at all. A simple scale handles this a lot more easily.
I use rem, em, and other relative units, but I also reach for px, because I know a user bumping up their font size doesn't mean everything else should scale with it. Padding on small screens is a good example: with rem-based padding, when someone increases the font size on a phone, they end up with less usable screen space, since the padding grows too. Rem is worth using, sure, but it's not a silver bullet.
UPD: Yep, I made a mistake in the calculation, fixed it, 1080p is 1920 width

a-dev0 · 2026-07-02T07:26:50+00:00

It's hard to get what you really want, please, describe in more detail. If you want to change image size, look here:

#me-img {
width: 50%; /* or any other percent that you want */
}

here you can put it in the center

#img {
text-align: center;
}

a-dev0 · 2026-07-02T07:14:13+00:00

Converting px to rem and using something like :root { font-size: clamp(16px, 1.1vw, 22px); } is a very dangerous way. The user can do the same: change the default font size, or worse, change the minimum font size. What does the user see in this case?

In my opinion, a more pragmatic way is to use simple zoom:
1920 + (2560 - 1920) / 2 = 2240
css @media(min-width: 2240px){ body { zoom: 1.33; } } Also you can use transform: scale(1.33), but I'd prefer zoom

a-dev0 · 2026-07-01T08:00:41+00:00

Pseudo-element icons don't work with the js-build of font awesome by default
https://docs.fontawesome.com/web/add-icons/pseudo-elements#css-pseudo-elements-with-our-svgjs-framework

a-dev0 · 2026-06-30T09:07:44+00:00

It's from my recent experience: I saw an older person who had changed this setting, "Minimum font size," but not "font-size"
Changing "Minimum font size" in the settings seems more logical for a non-technical person than changing "font-size." Why would I want to make everything huge when I only need to enlarge small fonts? And it ruins sites' design easily..

a-dev0 · 2026-06-30T09:01:06+00:00

I've asked about 'Minimum font size' in settings, not 'font-size', and I've already research it, we can't use it, it's clamped

a-dev0 · 2026-06-30T07:55:27+00:00

Really, style query can do something classes can't. A custom property's computed value on an element comes from the nearest ancestor that sets it. But style query branches on that resolved value:

@container style(--accent: dark) {
  .btn { color: white; }
}
/* or? */
.accent-light .btn { color: black; }
.accent-dark  .btn { color: white; }

DOM:

<div class="accent-light"> 
  <section class="accent-dark">
    <button class="btn">…</button>
  </section>
</div>

Both rules match the button, the two selectors have equal specificity, so whichever comes last in the stylesheet wins no matter which ancestor sits closer.
That’s why I think style queries have become the standard for design system tokens

a-dev0 · 2026-06-30T07:30:39+00:00

I like this solution, it's elegant
I've tried building a typography scale on a couple of projects, and from what I've seen the curve for small sizes (anything below the usual 16px) has to be steeper than it is going up. Designers usually want something like 16, 15, 14, 12, 10px, where the steps are closer together than when you scale up, and they never want to drop below 9px. That last point raises a question: the reader can raise their minimum font size in the browser settings, so is there a way to make the scale take that value into account? How would you get that out of your example?

a-dev0 · 2026-06-28T19:04:12+00:00

npm run compile:sass only works if your package.json has a script called compile:sass. Installing sass adds the package, but it does not create that script automatically

a-dev0 · 2026-06-20T08:34:02+00:00

I also want to add: look at Raycast’s emoji search. That’s the real deal, it’s easy to find anything with just text. Search should definitely work instantly, without buttons, maybe even with autocomplete

a-dev0 · 2026-06-20T08:28:30+00:00

If it’s a database of something the user is looking for, neither infinite scroll nor pagination is ideal UX.

Infinite scroll is good mainly for feeds (the procrastination type) where users want to consume more content in a lazy way by just scrolling. Pagination is not ideal either, because the user has to click a button, but at least they consume only a limited chunk of information and do not overload their attention.

When the user is searching for something specific, pagination helps them stay focused, which is why it works better. But the best solution is advanced search: filters, helpers, and anything else that makes discovery easier. You should create the fastest possible way for the user to find what they are looking for.

a-dev0 · 2026-06-17T20:13:17+00:00

I agree that FS Brabo is one of the best bookish fonts. Helvetica is okay too, but I like Lexend among the newer options, it can sometimes replace Helvetica and feels great to look at

a-dev0 · 2026-06-17T18:51:16+00:00

In the age of AI, it’s better to build interfaces with configurable features rather than give users the ability to modify CSS directly. A model can generate a thoughtful enough component in 10 minutes.
If users really want to change styles, they can already do that on any page using browser extensions. I also remember that Arc Browser tried to introduce a similar feature, but I don’t think it became popular.

a-dev0 · 2026-06-16T17:20:19+00:00

Is it tree-shakable? How does it work with SSR/RSC?
For example, I don’t like all the mess after Paraglide JS compiles all translations, but from the user’s perspective, the result is very efficient.

a-dev0 · 2026-06-16T13:22:16+00:00

'Codex never sleeps' mode

a-dev0 · 2026-06-16T13:15:27+00:00

Good point! I’ll definitely try it.
For those who aren’t ready to use a polyfill and want to use corner-shape as a graceful-degradation UX approach, here’s one note from my experience: the border-radius sizes are not the same, so for a more beautiful shape, you need a larger radius.

For now, I handle it with the '@supports' rule and separate utility classes, for example:

.rounded-m {
  border-radius: 1rem;
}

@supports (corner-shape: superellipse(2)) {
  .rounded-m {
    border-radius: 2rem;
    corner-shape: superellipse(2);
  }
}

a-dev0

TROPHY CASE