Basically, this is for this case in [css/css-transitions/starting-style-size-container.html](https://searchfox.org/mozilla-central/rev/ee9fd5e2df79c6d69af5aa9bc36041166f483227/testing/web-platform/tests/css/css-transitions/starting-style-size-container.html). For more specific, if we do these two operation at the same moment: ``` container.style.width = "400px"; target.style.display = "block"; ``` We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style. This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value). Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of `display` property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.) Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.) Method 3: Try to make sure the container query can evaluate the current value immediately after we got the style attribute change event of `container.style.width = "400px";`. And maybe other better ways.
Bug 1893320 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Basically, this is for this case in [css/css-transitions/starting-style-size-container.html](https://searchfox.org/mozilla-central/rev/ee9fd5e2df79c6d69af5aa9bc36041166f483227/testing/web-platform/tests/css/css-transitions/starting-style-size-container.html). For more specific, if we do these two operation at the same moment: ``` <div id="container" style="width: 200px"> <div id="target" style="display: none"></div> </div> <style> #container { container-type: inline-size; } #target { transition: background-color ...; background-color: lime; } @container (width > 300px) { @starting-style { #target { background-color: white; } } } @container (width < 300px) { @starting-style { #target { background-color: red; } } } </style> <script> ... container.style.width = "400px"; target.style.display = "block"; assert_equals(getComputedStyle(target).backgroundColor, "rgb(128, 255, 128)", "@starting-style based on the size query evaluation from the same frame"); ... </script> ``` We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style. This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value). Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of `display` property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.) Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.) Method 3: Try to make sure the container query can evaluate the current value immediately after we got the style attribute change event of `container.style.width = "400px";`. And maybe other better ways.
Basically, this is for this case in [css/css-transitions/starting-style-size-container.html](https://searchfox.org/mozilla-central/rev/ee9fd5e2df79c6d69af5aa9bc36041166f483227/testing/web-platform/tests/css/css-transitions/starting-style-size-container.html). For more specific, if we do these two operation at the same moment: ``` <div id="container" style="width: 200px"> <div id="target" style="display: none"></div> </div> <style> #container { container-type: inline-size; } #target { transition: background-color ...; background-color: lime; } @container (width > 300px) { @starting-style { #target { background-color: white; } } } @container (width < 300px) { @starting-style { #target { background-color: red; } } } </style> <script> ... container.style.width = "400px"; target.style.display = "block"; assert_equals(getComputedStyle(target).backgroundColor, "rgb(128, 255, 128)", "@starting-style based on the size query evaluation from the same frame"); ... </script> ``` We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style. This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value). * Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of `display` property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.) * Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.) * Method 3: Try to make sure the container query can evaluate the current value immediately after we got the style attribute change event of `container.style.width = "400px";`. And maybe other better ways.
Basically, this is for this case in [css/css-transitions/starting-style-size-container.html](https://searchfox.org/mozilla-central/rev/ee9fd5e2df79c6d69af5aa9bc36041166f483227/testing/web-platform/tests/css/css-transitions/starting-style-size-container.html). For more specific, if we do these two operation at the same moment: ``` <div id="container" style="width: 200px"> <div id="target" style="display: none"></div> </div> <style> #container { container-type: inline-size; } #target { transition: background-color ...; background-color: lime; } @container (width > 300px) { @starting-style { #target { background-color: white; } } } @container (width < 300px) { @starting-style { #target { background-color: red; } } } </style> <script> ... container.style.width = "400px"; target.style.display = "block"; assert_equals(getComputedStyle(target).backgroundColor, "rgb(128, 255, 128)", "@starting-style based on the size query evaluation from the same frame"); ... </script> ``` We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style. This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value). * Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of `display` property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.) * Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.) * Method 3: Try to make sure the container query can evaluate the correct value immediately after we got the style attribute change event of `container.style.width = "400px";`. And maybe other better ways.
Basically, this is for this case in [css/css-transitions/starting-style-size-container.html](https://searchfox.org/mozilla-central/rev/ee9fd5e2df79c6d69af5aa9bc36041166f483227/testing/web-platform/tests/css/css-transitions/starting-style-size-container.html). For more specific, if we do these two operations at the same moment: ``` <div id="container" style="width: 200px"> <div id="target" style="display: none"></div> </div> <style> #container { container-type: inline-size; } #target { transition: background-color ...; background-color: lime; } @container (width > 300px) { @starting-style { #target { background-color: white; } } } @container (width < 300px) { @starting-style { #target { background-color: red; } } } </style> <script> ... container.style.width = "400px"; target.style.display = "block"; assert_equals(getComputedStyle(target).backgroundColor, "rgb(128, 255, 128)", "@starting-style based on the size query evaluation from the same frame"); ... </script> ``` We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style. This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value). * Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of `display` property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.) * Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.) * Method 3: Try to make sure the container query can evaluate the correct value immediately after we got the style attribute change event of `container.style.width = "400px";`. And maybe other better ways.