[enhancement] Wrap polyfill in `@supports not`

[kerberjg]

This polyfill unnecessarily removes and replaces aspect-ratio even in browsers where it is supported.

I suggest that the original aspect-ratio property is left intact, and the polyfill-generated code is wrapped in a @supports not instruction.

https://developer.mozilla.org/en-US/docs/Web/CSS/@supports

Input:

.aspect-ratio-box {
  aspect-ratio: 16 / 9;
}

Expected output:

.card-wide {
    aspect-ratio: 16 / 9;
}

@supports not (aspect-ratio: 1/1) {
  .aspect-ratio-box::before {
    float: left;
    padding-top: 56.25%;
    content: '';
  }
  .aspect-ratio-box::after {
    display: block;
    content: '';
    clear: both;
  }
}

Note: 1/1 is used only as a test value to check whether aspect-ratio is supported at all, it does not affect the resulting layout.

[alike03]

But the problem with this are the browsers that don't support "@supports". https://caniuse.com/css-featurequeries

[scherii]

@alike03 So browsers from 7+ years ago? A small price to pay, considering that all modern browsers then get to keep the native version.

[dawaltconley]

While I agree that's a pretty fringe use case (just IE?), it wouldn't be so hard to support those browsers as well. That means

.aspect-ratio-box {
  aspect-ratio: 16 / 9;
}

becomes

.aspect-ratio-box::before {
  float: left;
  padding-top: 56.25%;
  content: '';
}
.aspect-ratio-box::after {
  display: block;
  content: '';
  clear: both;
}

@supports (aspect-ratio: 1/1) {
  .aspect-ratio-box {
      aspect-ratio: 16 / 9;
  }
  .aspect-ratio-box::before, .aspect-ratio-box::after {
    content: none;
  }
}

Are there any downsides to doing it this way? All I can think of is that it's three more lines of code. Wondering if it's worth updating #8...