Ancestors

Written by Thomas Michael Semmler on 2024-12-19 at 12:42

Omg. I attempted to debug an issue in safari, where a position: fixed; element didn't correctly align to the viewports edge and I couldn't find out why, until I noticed that it is now relatively positioned to the next element with container: inline-size; on it.

Is this how it is supposed to be? This is only the case in safari

[#]safari #css #containerqueries #html #webdev

=> More informations about this toot | More toots from nachtfunke@indieweb.social

Toot

Written by Nathan Knowler on 2024-12-19 at 12:56

@nachtfunke Is the element a descendant of the container? Some containments create a stacking context.

=> More informations about this toot | More toots from knowler@sunny.garden

Descendants

Written by Kilian Valkhof on 2024-12-19 at 13:00

@knowler @nachtfunke stacking contexts shouldn't influence fixed positioning.

=> More informations about this toot | More toots from Kilian@mastodon.social

Written by Nathan Knowler on 2024-12-19 at 13:03

@Kilian @nachtfunke Good point. I wonder if it’s WebKit being a bit to stringent with how they’ve applied containment? My minds been on containment so I’m curious to understand if there’s a bug.

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Kilian Valkhof on 2024-12-19 at 13:05

@knowler @nachtfunke definitely following along with this yeah.

Is it fixed to the containing element (and scrolls along with it) or is it a weird mixture where it's clipped but still sticky to the viewport?

=> More informations about this toot | More toots from Kilian@mastodon.social

Written by Nathan Knowler on 2024-12-19 at 13:08

@Kilian @nachtfunke Fixed to the containing element.

I’ve got a reduced test here: https://knowler.dev/demos/ybomgkl?codepen

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Nathan Knowler on 2024-12-19 at 13:14

@Kilian @nachtfunke Looks like layout containment (i.e. contain: layout) can trigger it in Chrome. The spec says using container-type: inline-size should set both layout and style containment (along with the more obvious inline-size). So I’m thinking that Chrome is in the wrong here.

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Nathan Knowler on 2024-12-19 at 13:16

@Kilian @nachtfunke Yep, layout containment is supposed to cause a “fixed positioning containing block.” So, looks like maybe Chrome and Firefox are not applying layout containment.

Ref (see point 4 in the list — and there’s no difference between the draft and the published spec): https://drafts.csswg.org/css-contain/#containment-layout

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Nathan Knowler on 2024-12-19 at 13:26

@Kilian @nachtfunke Looks like the WPT for it is passing, but they use floats. Seems like there could be more robust tests. https://wpt.fyi/results/css/css-conditional/container-queries/container-type-containment.html

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Nathan Knowler on 2024-12-19 at 13:45

@Kilian @nachtfunke I’ve created an issue for the WPT here: https://github.com/web-platform-tests/wpt/issues/49776

I think finding a better test might be more productive than filing/managing individual bug reports.

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Nathan Knowler on 2024-12-19 at 13:57

@Kilian @nachtfunke 😩 To make matters worse, it looks like Safari Tech Preview (210) does the wrong thing like Chrome and Firefox.

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Mia (web luddite) on 2024-12-19 at 16:28

@knowler @Kilian @nachtfunke It's because we thought we need layout containment, and we were wrong. All browsers started with the layout containment behavior- and have been removing it. Because it's not needed, and container queries shouldn't apply side-effects we don't need.

=> More informations about this toot | More toots from mia@front-end.social

Written by Nathan Knowler on 2024-12-19 at 16:30

@mia @Kilian @nachtfunke So, if I’m understanding correctly, layout containment should not be applied when container-type is inline-size or size? The change wasn’t a change to how layout containment itself works?

=> More informations about this toot | More toots from knowler@sunny.garden

Written by Mia (web luddite) on 2024-12-19 at 16:55

@knowler @Kilian @nachtfunke right, a new formatting context is required, but otherwise layout containment will not be applied when creating size-query containers.

=> More informations about this toot | More toots from mia@front-end.social