Ancestors

Toot

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

Descendants

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

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

Written by Manuel Matuzović on 2024-12-19 at 12:58

@nachtfunke If you ask me it should be like that in all browsers because the property and value apply layout containment which creates a fixed positioning containing block. Or am I wrong @mia?

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

Written by Mia (web luddite) on 2024-12-19 at 15:30

@matuzo @nachtfunke this was how the feature worked initially. We thought that was required for proper containment. But it's not! And browsers should hopefully all be removing that asap! (@jensimmons, @emilio)

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

Written by Emilio Cobos Álvarez on 2024-12-19 at 15:31

@mia @matuzo @nachtfunke @jensimmons Yeah, it's already fixed in Firefox and Chrome, right? (And Safari TP)

=> More informations about this toot | More toots from emilio@w3c.social

Written by Mia (web luddite) on 2024-12-19 at 15:35

@emilio @matuzo @nachtfunke @jensimmons oh, great news - thanks!

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

Written by Manuel Matuzović on 2024-12-19 at 15:39

@mia @nachtfunke @jensimmons @emilio that's what I thought! Good news! Thanks for clarifying.

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

Written by Kilian Valkhof on 2024-12-19 at 15:42

@mia @matuzo @nachtfunke @jensimmons @emilio nice!

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

Written by Thomas Michael Semmler on 2024-12-20 at 11:55

@mia @matuzo @jensimmons @emilio just so I understand, Safari's behaviour here is the intended, correct way?

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

Written by Manuel Matuzović on 2024-12-20 at 12:22

@nachtfunke @mia @jensimmons @emilio use to be the intended behaviour but will change soon. Afaik it's already different in TP.

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

Written by Thomas Michael Semmler on 2024-12-20 at 12:26

@matuzo @mia @emilio @jensimmons alright, thank you! Makes sense.

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