csssemantic-uiwill-change

css property will-change undefined behaviour


I am using semantic-ui, and have managed to narrow down some undefined behaviour in the css property will-change (I found it in their modal's):

.outer{
  background-color: black;
  position: absolute;
  left: 0;
  top: 0;
  right: 0;
  bottom: 0;
}
.inner{
  position:absolute;
  background-color: white;
  left: 50%;
  top: 100px;
  width: 400px;
  margin-left: -200px;
  height: 100px;
  padding: 5px;
  /**
   * comment out the line below
   * to see the desired/different result
   **/
  will-change: transform;
}
.baby{
  color: yellow;
  position: fixed;
  left: 20px;
  top: 20px;
  right: 0;
  border: 1px solid red;
}
<div class="outer">
  <div class="inner">
    <div class="baby">here</div>
    <div class="content">some content</div>
  </div>
</div>

I have only tested this in chrome. Does anyone have more information on what is going on here? Why does will-change do anything to the actual layout?


Solution

  • will-change affects layout because it's often used with properties whose values can change between one that doesn't affect layout, and one that does. Setting will-change tells the browser to prepare for such a potential change, which results in the browser applying the layout changes in advance.

    This isn't undefined behavior:

    If any non-initial value of a property would create a stacking context on the element, specifying that property in will-change must create a stacking context on the element.

    If any non-initial value of a property would cause the element to generate a containing block for absolutely positioned elements, specifying that property in will-change must cause the element to generate a containing block for absolutely positioned elements.

    If any non-initial value of a property would cause the element to generate a containing block for fixed positioned elements, specifying that property in will-change must cause the element to generate a containing block for fixed positioned elements.

    If any non-initial value of a property would cause rendering differences on the element (such as using a different anti-aliasing strategy for text), the user agent should use that alternate rendering when the property is specified in will-change, to avoid sudden rendering differences when the property is eventually changed.

    For example, setting opacity to any value other than 1 creates a stacking context on the element. Thus, setting will-change: opacity also creates a stacking context, even if opacity is currently still equal to 1.

    In your case, since transforms result in the creation of both a stacking context and a containing block, setting will-change: transform will therefore also result in the creation of a stacking context and a containing block, because you're suggesting to the browser that the element might have a transform either now or later, and when it does, the layout will be affected.