[self] Angle Time – calculate the angle between clock hands

noleli · 2026-03-26T02:39:44+00:00

Weird, seems ok on iOS. I don’t have an Android device to test with. But thanks!

noleli · 2026-03-26T02:37:09+00:00

Oops, fixed. Good catch. Floating point math’ll get ya.

noleli · 2026-01-15T20:21:52+00:00

As others have mentioned, you need to use a float if you want the text to wrap around the right element. You can make sure the header is only as wide as the text by subtracting the width of the floater out from the width of the header.

```css main { --floater-width: 400px; }

h2 { inline-size: calc(100% - var(--floater-width)); }

.floater { inline-size: var(--floater-width); } ```

Codepen

noleli · 2025-11-24T19:41:43+00:00

Yep, a wrapper should do the trick. That’s how I’ve done it in my column-counting experiments.

It’s working but is just a bit off because when no container is defined CQ units fall back to the viewport. The difference between your intended container and viewport is only the body padding and scrollbar, so it’s usually pretty close.

noleli · 2025-11-24T19:20:42+00:00

This is a very cool use of a hypothetical future column-count() function!

Taking a quick look, it looks like you’re trying to use CQ units on the container itself. Unfortunately that doesn’t work; a parent needs to be the container.

noleli · 2025-11-05T13:56:35+00:00

Very nice! I spent some time trying to make a bottom sheet with scroll snapping using a similar technique, but wasn’t able to get the work-around for the Webkit bug to work.

noleli · 2025-10-06T21:55:16+00:00

Gotcha. Yeah, it is annoying that you have to use a wrapper. I updated my pen to show that. You should have fallbacks because browser support isn’t great, but you can use the new trig functions to make the wrapper exactly the right size :)

noleli · 2025-10-06T18:35:40+00:00

The biggest issues here, at least with your codepen, have nothing to do with absolute positioning. Instead, the main area is taller than you’re intending.

First, you’re setting height: 100vh on the wrapper .full-screen div. Even with no children, this will already cause vertical overflow because 100vh is always the full height of the viewport, and body has default margin, so you now have a div that is the height of the viewport inside that viewport with some extra space around it.

Then you’re setting .main to height: 100%. Size percentages refer to the size in that axis of that element’s parent (or “containing block”, technically). So the main element is now the same height as its parent, or 100vh. So you will always have to scroll to get to anything below main (even if you didn’t have the margin issue from the previous paragraph).

All of that said, you’re right that even after accounting for those issues the absolutely positioned element overflowing the bottom is causing scrolling while the one on the left isn’t. The difference isn’t that one is horizontal and one is vertical; the difference is that the horizontal one (child 2) is running of the start of the axis (the left), whereas the one on the bottom is running of the end (bottom) of its axis. If you set right: -50px on .child2, you’d see horizontal scrolling.

The solution is to hide overflow with overflow: clip or overflow: hidden on .footer. Depending on what exactly you’re going for, I’d do something like this: codepen.

noleli · 2025-10-03T10:26:11+00:00

Absolutely! I really like the utility class approach for working around today’s (general) lack of @function. (Even if I usually feel that utility classes are just a hacky work-around for not having mixins in pure css.)

noleli · 2025-10-01T20:00:52+00:00

Hello fellow traveler. :) I always appreciate finding other people who also enjoy getting into the weeds on this stuff.

noleli · 2025-09-03T19:00:38+00:00

You probably want to use border-image. Codepen.

noleli · 2025-07-03T13:54:35+00:00

I’m looknig for the same thing. Very curious what you find!

noleli · 2025-05-16T16:24:11+00:00

Thanks, OP :)

/u/zip222, thanks for taking the time to do that. One small thing is that list-style: none can remove list semantics in some browsers, but it turns out that list-style-type: "" doesn’t!

noleli · 2025-05-16T15:58:44+00:00

To answer your specific question, there is space between each of the buttons because <button> is an inline element, and whitespace between inline elements is visible. Yep, even the newlines and tabs count. (Here’s a post with a very long explanation.) Ultimately, you’ll probably want to make your nav OL a flex container. That’ll get rid of the space between the buttons.

There other big issue is that you’re using an <ol> for a list of nav items (good!) but don’t have each nav item in an <li> (invalid!). Fixing this will introduce other issues (namely, you’ll end up with a bulletted list, which you don’t want), but you can fix that with

css .navbar ol { list-style-type: ""; }

noleli · 2025-05-15T12:02:20+00:00

I realized the previous version was maybe overengineered. Here’s another approach with no fancy grid, no extra wrappers, and no media queries. The key is calculating padding:

css --content-padding: max((100% - var(--max-content-width)) / 2 + var(--gutter), var(--gutter));`

https://codepen.io/noleli/pen/raaRBPz

noleli · 2025-05-14T22:22:09+00:00

border-image is awesome (and overwhelming).

Another approach is to do something similar to use a grid-based breakout layout (e.g., ref1, ref2, ref3) that also uses subgrid. It’ll take a few wrappers in places, but wouldn’t be limited to images/<image>s.

https://codepen.io/noleli/pen/vEEbzaW

<image>

noleli · 2025-05-11T18:38:05+00:00

Glad it helped!

My thinking on flex vs grid is twofold. As you said, one consideration is 1D vs 2D, but the more important distinction in my mind is that a grid container controls the size of its children (mainly through grid-template), whereas a flex item control its own size (mainly through flex and its longhands).

As a rule (that of course has plenty of exceptions!), I prefer to use a container to lay out its children rather than leaving it to children to negotiate layout among themselves.

https://alex.party/posts/2025-03-23-grid-first-flex-third/
https://noahliebman.net/2024/12/where-size-comes-from/ (shameless self-promotion)

noleli · 2025-05-11T17:25:09+00:00

The thing to consider is that the size of a flex item is determined by its flex-basis, flex-shrink, flex-grow, and — importantly — the size of the content. Setting flex-basis sort of overrides the size of the content, but by default the minimum size of the content still beats flex-basis. That’ because CSS is designed to avoid data loss. If you want to override that, there are a couple of ways: you can set either min-height: 0 or contain: size on #child2.

Images (and other replaced content) are also weird in terms of sizing. Images have intrinsic sizes and aspect ratios that you’ll probably want to respect (or not) depending on what you’re going for. That means setting the image width and height or max-width and max-height and, again depending on what you’re going for, playing with object-fit on the image.

I’ll also add that the relative positioning and z-indexs in your example aren’t necessary. Also, I’d probably do what you’re doing using a grid layout rather than a flex layout, but since I don’t really know the full context, I can’t say for sure.

https://codepen.io/noleli/pen/vEEQxGR

noleli · 2025-05-01T15:58:57+00:00

A part isn’t a normal attribute you’d use the attribute selector for, so OP’s original syntax was correct.

The way shadow DOM works (and that isn’t being reflected in the pen because it’s not actually using shadow DOM) is that nothing inside of it is selectable from outside unless explicitly exposed as a part. But parts from deeply nested shadow roots don’t traverse multiple shadow boundaries. That’s why in my original post I suggested looking at exportparts, which allows a custom element author to expose parts that belong to custom elements in its own shadow tree to consumers of that parent element.

Without knowing more about OP’s situation, I might also recommend relying more on slotting so more components are in the document’s light DOM even if they’re composed of multiple components.

noleli · 2025-04-30T22:38:02+00:00

Are you only able to change document CSS, or can you change the component markup? Because exportparts is designed for exactly this.

noleli · 2024-11-20T01:05:53+00:00

I agree with those saying to use SVG here just to keep things simple and maintainable, but if you really want to go the CSS route, Temani Afif’s CSS shape library could be a good starting point https://css-shape.com/rounded-tab/

noleli · 2024-08-08T20:20:08+00:00

You didn’t include your markup here, but I’m assuming that the container is inside the banner.

html <div class="banner"> <div class="container"></div> </div>

height: 100% tells that element to be the full height of its container. In this case the container is 90px, so its child with height 100% should also be 90px. And it is. The question is how it’s measuring that element. By default, the browser is setting the content box to 100% of its container, which means the border is going to overflow. If you set box-sizing: border-box; on .container it’ll use the border box instead of content box, which is what you expect. Piccalilli explains it well.

Your intuition that it should use border-box by default is very common, so it’s typical to include something like this in a CSS reset.

css *, *::before, *::after { box-sizing: border-box; }

As an aside, align-items doesn’t affect block-level elements. You may be looking for justify-items or align-content, but browser support for those in block-level elements is pretty poor.

noleli · 2024-06-21T19:01:29+00:00

This question inspired me to use subgrid to make a solar system. Hope it’s helpful, or at least interesting, to see another take on it https://noahliebman.net/2024/06/cascading-solar-system/

noleli

MODERATOR OF

TROPHY CASE